Requirements - the big picture

Over the last 10 years, there has been a revolution in the way requirements are handled. Spurred on by the success of Agile, best practice has evolved, and three things are now clear.

Involving customers all through the development process, to understand their problems, review prototypes and test releases, is essential to building a product they want.

You can read all the articles in our Product Management Journal – Requirements by signing up for free here.

Requirements work best when there is a 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.

Fundamentals

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, prioritize, and communicate the requirements to the people who will design and build the product.

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 rigor 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 understand, communicate, and check customer requirements properly. The less discussion and more hand-offs there are, the more these problems are amplified.

Summary

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 is a great way of making sure this happens.