Requirements: The big picture
Involving customers all the way through the development process, to understand their problems, review prototypes and test releases, is essential to building a product they want.
Requirements work best when there is close collaboration between the key disciplines involved – Product Management and Development with design / user experience experts when required. This involves an ongoing conversation about what’s needed, possible and desirable.
Finally, the old formal way of documenting requirements with ‘The product shall do…’ has been largely replaced by a user-centered approach. Requirements are based around the different users of a product and described in everyday language. Success criteria are defined up-front and context provided so everyone can understand what’s needed. This has proven to be more effective at focusing the requirements process on exploring customer problems … and then helping design the right solution.
Whether your company uses a Waterfall methodology such as Stage-Gate, an Agile approach like Scrum or some combination, the basic steps remain the same. These are to gather the requirements, design a solution and build a product.
However as a product manager, your first job is to understand the market problems and decide which ones make strategic and financial sense for your business to solve. If the business buys into your vision, then budget and resources are made available. Once you have the commitment you can gather, prioritise and communicate the requirements to the people who will design and build the product.
“In several projects I have run there seemed to be more focus on hitting the target release date – rather than the product manager checking we were actually delivering a viable product.”
Jeroen Visser, Consultant
An ongoing process
Managing requirements is not a one-off task. The reality is that you get an ongoing stream of requirements, changes and updates that have to be managed throughout the development project and beyond. As you uncover and adjust requirements you’ll be continually balancing what can be included in each release given the resources available and your target delivery date. For example what goes on the roadmap for the future? What just isn’t important enough for your target market? What really does have to make it into the next release?
There is no single best way
There is no right or wrong way to manage requirements. The more formal and detailed the process the less room there is for ambiguity but the longer things take. Too little rigour and there is a danger that what’s built doesn’t meet market or business needs. What’s appropriate will depend on your product, company culture, what’s been successful in the past, development processes, proximity to the development team, time-to-market pressures as well as your appetite for risk. You need to decide where on the scale you want to be. For example, you would be well to the left for a life-support system and well to the right if looking after a small web site for your local club.
So what could possibly go wrong?
As we write requirements we get things wrong and miss things out. Things get miscommunicated or misunderstood. Our understanding of customers and their problems changes and improves. And the inevitable pressure to release on time means that things are dropped or changed. So what gets built is rarely exactly what we expect or want.
The famous tree swing cartoon below shows the dangers of failing to properly understand, communicate and check customer requirements. The less discussion and more hand-offs there are the more these problems are amplified.
As a product manager you need to ensure the requirements process builds a product that people will buy. Involving customers from the start, cross-departmental collaboration and user-centered requirements are a great way of making sure this happens.