 |
|
Home > Product Management > Writing Requirements
An important job of the Product Manager is to translate the vision of the product or service to a series of concrete requirements. Before you sit down at your computer to write a requirements document, ensure you have a firm understanding of the desired product functionality (that you have validated with your Product Advisory Board). Although there are entire books devoted to the subject of writing requirements, I use the VCR guideline:
Then, in a completely silent process during which nobody is allowed to speak, everyone arranges and re-arranges the requirements according to "themes." The benefit of not speaking is that the group isn't overly influenced by a couple of loud voices. The "theme" should also be obvious enough to understand what it is just by looking at it, and without having to use words to explain it. Finally, the "themes" are boiled down to top-level, over-arching concepts that are fed into the development process. Not every "theme" makes it may the product, but the output is a database of validated ideas that continually fuels the product development process, which you can add back into your Feature Sandbox.
Writing Requirements
An important job of the Product Manager is to translate the vision of the product or service to a series of concrete requirements. Before you sit down at your computer to write a requirements document, ensure you have a firm understanding of the desired product functionality (that you have validated with your Product Advisory Board). Although there are entire books devoted to the subject of writing requirements, I use the VCR guideline:
- Verifiable: A verifiable requirement is something that you (or someone else) could measure or touch. "The product must be easy to navigate" is not a verifiable requirement; it is subjective, since someone else may not agree with you about what this means. Almost any qualitative adjective like "fast," "flexible," "quick," "small," or "large" indicates an un-measurable requirement. For an "easy to navigate" product, you may wish to brainstorm with your UI team and use the requirements document to specify the desired navigation, for example, by means of mockups. In addition, avoid using the word "not" in the requirement; re-write the requirement as a positive statement.
- Customer-Driven: Requirements are never written in a vacuum; they must be written with the benefit of the customer in mind. If you can quantify the effect of this requirement on the customer in terms of increased revenue, decreased costs, or any other metric, all the better.
- Realistic: This is where the rubber meets the road. Although the Product Manager should always challenge the organization to stretch far beyond what it can do, the Product Manager should also have a good sense of what is feasible within the intended release timeframe and the product roadmap. This is where you negotiate with your developers. Can this requirement realistically be implemented in the desired timeframe? If yes, include it. If not, go back to the negotiating table.
Generating Concepts that Address Customer Requirements
One way of filtering through requirements you've written is to summarize each one on a sticky note and arrange the sticky notes on a big board. Gather together everyone who has a say in your new product development process, including other PMs, sales and customer care managers, and executives. Each person can either add a new requirement on a sticky note, or put a star on someone else's. By doing this, you are essentially "voting" for requirements on behalf of your customers.Then, in a completely silent process during which nobody is allowed to speak, everyone arranges and re-arranges the requirements according to "themes." The benefit of not speaking is that the group isn't overly influenced by a couple of loud voices. The "theme" should also be obvious enough to understand what it is just by looking at it, and without having to use words to explain it. Finally, the "themes" are boiled down to top-level, over-arching concepts that are fed into the development process. Not every "theme" makes it may the product, but the output is a database of validated ideas that continually fuels the product development process, which you can add back into your Feature Sandbox.
