Agile Product Management, Marketing, and More
Posts tagged Product Management
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?
Start with the Problem Statement
Oct 25th
For all the talk about bad products and poorly designed features, many companies don’t spend enough time listening to the market. Some think they do, but they listen passively and only hear feature requests. What really helps drive a great product is to listen actively and hear problems.
Working within the problem-solution paradigm inherently demands that we accurately understand what the problems are. If we start from the incorrect starting point, following the correct path to a solution will cause us to solve the wrong problem.
This interesting article goes into linguistics and considers not just the language of problem statements in terms of the words we choose to write them in, but from the broader perspective of the framework in which we think about them. Abstracting the problem to the correct level is essential in solving the problem, which is what we are all trying to do.
Agile Modeling
Oct 25th
One of the challenges I encounter with producing customer requirements for consumption by a development team is overcoming the barrier of understanding. My company does not have dedicated business analysts, so the role of translating customer needs to development needs and architecture is typically handled by our developers. What if they don’t see the big picture of what the user wants, but instead only see a large collection of unrelated detail?
Organizing requirments in categories can help to provide a mental framework, but navigation becomes difficult past 2-3 levels. It’s becoming apparent to me that in order to bridge the gap, some diagramming and coalescing of requirements into pictoral form must be provided. The question is, of the tens of possible types of models, which types are most effective and therefore worth the time?
I’ve found a site that details numerous types of models and diagrams, and provides handwritten examples of each. The silver-bullet takeway from this site is the following:
“know a wide variety of modeling techniques … apply the right artifact(s) for the situation at hand.”
My current problem is that I’ve been away from my brief studies in UML during my Master’s program for six years, and I don’t have command of that wide variety of modeling techniques. I have, therefore, just shared with you the newest item on my personal to-do list…