|
Quick Tips - Tips from the practice masters...
Whether you use a traditional waterfall approach for product development or the newest agile method, requirements are still the critical link between the market opportunity and product development. In a recent PSN Member Roundtable, two practitioners - Barry Christenson, Director of Product Management with ANSYS and Scott Keefer, Product Manager with Thermo Fisher Scientific, shared useful tips that apply no matter what method or document you are using.
-
Write a ‘press release' first - it's a ‘Destination Statement' - that provides a high-level view and says you're going to do this, and it will cost this much, and it will look like this. It says how you are going to excite your customers and investors. Although it's not a requirements document, it provides a statement of what benefits those functions will bring and focuses the team on what matters most.
-
Be concise. A thoughtful requirements document can easily reach 75 pages. Problem is, nobody reads them from beginning to end, and they are often not accurately written. Instead, use a handful of large-type PowerPoint slides to capture the essence of the key themes of the solution your want to deliver to customers at the end of the development process.
-
Plan iterations. Once you've captured these key themes, use an iteration sheet to outline the minimum set of development projects and the logical process needed to solve that problem.
-
Use internal proxy customers - experienced product managers or the like on your own staff who have access to real customers and understand how those customers are going to use the product - to spec out the minimum set of functions required and to make judgments regarding the requirements.
-
Go beyond functionality. Requirements documents should include more than features and functions. They could also include conditions that apply to installation, upgrade, migration, human interface, operations, branding, environmental, documentation, training, implementation and end-of-life. It's about the whole product, the total solution.
-
Global products, local needs. For global products with region-specific requirements - such as regulatory, safety and interoperability conditions - should be handled as variations to a specific requirement.
-
Validate. Make sure that any requirement can be validated externally. Name the source and their contact information so Product Management can determine where it came from and get clarification as to what they actually meant and want - and why. In the case of some regulated industries, such as healthcare, traceability of requirements is also a part of compliance.
-
Cultivate buy-in. Securing buy-in from development engineers by having them go out and talk to key customers with you, so the engineers can hear the same thing from people other than Product Management, can be very powerful.
-
What's the difference? Consider having a customer come in to talk about why your technology makes a difference in the lives of real people who have serious needs. Then the developers can associate the things they build with how it affects people. It's about why you're in that business - it's about more than just getting products out the door.
-
What, and Why, not How. Writing a requirements document that Marketing can understand and which Product Management can defend in front of Development is critical. Concentrate on the ‘what' and ‘why'; leave the ‘how' to Engineering, who may have a better way of doing it.
-
Embrace change. No matter how much time you spend planning upfront, something will always happen which requires you to adjust during the development process. Particularly if you use a single-document approach, your requirements document will evolve over the course of development; it's not set in stone, it's a living document.
To read our latest articles in Inside Product Strategy™ click here.
Comments on this Quick Tips article can be submitted to
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
.
To read our latest articles in Inside Product Strategy™ click here.
|
