Agile Product Management, Marketing, and More
Archive for December, 2008
Metrics
Dec 29th
I just ran across an interesting presentation on the use of metrics in product management by Dan Olsen, which shines some light on the art of convincing the business side of the organization of the value of a proposed solution. Though the metrics in the presentation are primarily website-related, including click-through rate and rate of registration for a site, the concepts are still applicable to all types of business cases.
Particularly insightful is the idea of graphing the ROI of various benefits in an attempt to illustrate the value proposition (slide 26). Those customer benefits which have the highest importance to the user, but which have the lowest current satisfaction rate, may be the ideal benefits to bring to the table first, or as labeled within the slide deck, “upside potential.”
Have a look!
Documenting Requirements
Dec 28th
The language of requirements is a challenge to explain: there is an art involved in writing declarative statements that specify what needs to happen without inadvertently limiting the implementation. Certainly, the choice of words is important: words like “select” and “supply” are more vague than “click the radio button for” and “type into the text box,” but there’s more to it. I’ll elaborate on that in a future post.
I continue to be more convinced that multiple methods of delivering requirements are needed to draw a complete picture. So even though one might have the language challenge under control, various types of models (both graphical and verbose) can help to provide views into the system’s requirements from all sides. But how do they relate to each other, and how do the models relate to the declarative statements that provide the granular detail of what is needed?
The methodology I’ve seen implemented most frequently, when boiled down to brass tacks, is just interviewing and observing users and identifying requirements, and then backing them up with more intricate system models. The more I reflect, however, I think there may be a smarter way. One approach I’ve seen from a few sources is to depict the system’s primary uses in the form of use cases, which can be further broken down into any number of scenarios that depict the use case with specific input values and paths through the use case; and then, writing requirements that support each use case. One point made in a highly recommended article at TechTarget.com is: requirements that don’t tie back to a use case may be a warning sign of missing use cases. Working through a deliberate methodology like this might be a step towards preventing any significant gaps in requirements capture.
The above article from TechTarget also considers data elements, and recommends entity-relationship diagrams to zero in on the data elements. As a product manager, I see that fitting in a little deeper into the cycle at the business analysis/design stage, not at the customer requirements/analysis stage. What do you think?