Whether you think of Requirements Management as a skill, a discipline, a process, or a necessary evil, you must think of it. You are the messenger of the market and the protector of customer insights, and your company’s existence may very well depend upon it.
This article discusses some of the most important questions that product managers face every day. It illustrates how Requirements Management not only helps your company deliver more customer-driven products but how it helps you personally work more efficiently. Product managers who adopt good Requirements Management practices will discover that their decisions are proactive, their account managers are supportive, and their field engineers are responsive. As a result, development engineers will be happy to see an approaching product manager.
Is Requirements Management a universal remedy to all of a product manager’s headaches? Hardly! But this is certainly one of those cases where being effective in one area of your job does have a highly positive influence on many other areas.
Why does my PRD read like the minutes of a parliamentary committee meeting?
Well-meaning product managers rightfully attempt to capture and manage all of their valuable customer insights in a single place. Unfortunately, in the absence of a proper Requirements Management process, this centralized place tends to be the product requirements document (PRD) itself!
All the complexities of all the discussions concerning the product, therefore, tend to reside in that unwieldy document. It grows fatter and increasingly more unreadable every day. Paradoxically, this trend continues even when requirements are removed from the project.
Moreover, the very idea of a single PRD is fast becoming antiquated. The next-generation PRD should be a dynamically evolving document that changes form to suit the needs of its audience. It also has an important temporal dimension, spanning into the future to provide developers guidance on the overall direction of the product.
Getting the right level of detail is extremely difficult as different situations call for different levels of specificity. During a product overview meeting, for example, just the top-level requirements with the highest priorities are needed. However, when it is time for individual development groups to construct specific design documents, a much more detailed perspective of the market is required, and a different perspective of the PRD must be produced. If you then want to share with your customer your development plans, yet another version must be produced (preferably one which does not highlight the woeful performance of your existing product).
Any well-designed Requirements Management methodology should
- allow you to capture all the valuable customer insights in a single place and then link them to actual requirements
- separate core requirements from important peripheral information, such as customer interview notes
- distinguish short-term requirements from long-term requirements and allow you to present different perspectives to different audiences.
Where did I put that customer insight?
Customer insights are one of your company’s most valuable assets. Unfortunately, these customer insights typically disappear as fast as they are collected, leaving companies ill-informed about their target market.
Where did these insights go?
- They are committed to less-than-perfect memories.
- If customer meeting notes are recorded, they are stored outside of the mainstream information flow.
- In more extreme circumstances, a company’s customer insights vanish when any member of the product management team leaves the group—a serious problem in high-tech companies.
- And, most ironically, they are very literally buried in the previous PRD, forever resting in eternal peace.
A tool dedicated to Requirements Management can help, but to be most effective, the product manager using these tools should always think a product beyond the current release. They must be constantly developing and refining product requirements for the future by driving customer insights into the company and matching customer needs against the competencies of the organization.
This ongoing refinement of customer insights, problems, and requirements will pay dividends when it is time to launch a new development effort.
Why are my developers not happy?
Arguably the most important consumers of the PRD are the development engineers. However, when a developer first reviews the substance of a PRD, it is only natural that a number of issues arise. The developer may ask, “I don’t understand this requirement,” or “I need more information,” or “I need a customer use case,” or even “I need a test case in order to know when I’m done.”
For example, a developer pressed to create a technology that is both “high-performing” and “scalable” may observe that these requirements contradict one another or that they are technically impossible to deliver.
Once a developer raises an issue that concerns the scope of the product, the product manager needs to take charge and close the issue. For the sake of the product, and for the productmanager’s own credibility, it is important that every issue be tracked and closed.
Generating content for the PRD is only the first step. Correctly presenting the PRD to your audience helps ensure that the information is properly considered. Developers do not want to be inundated by every requirement related to the product; they want to see only those categorized requirements of most concern to them (not a trivial task as requirements often span multiple groups).
Similarly, when revising the PRD, product managers should highlight those requirements that have recently been modified so that developers are aware of the most pressing issues. It sounds easy, but presenting changes to developers in a meaningful way is actually quite challenging.
Why do sales escalations drive the product?
Unfortunately, just as developers often do not believe product managers are giving them the information they need, account managers often do not believe that product managers are listening to the needs of their customers. Inevitably, requirement escalations ensue.
The best way to handle this problem is good Requirements Management. This achieves several things:
First, account managers gain confidence by seeing that their customer requirements have not been lost but are instead flourishing in discussion and consideration. The more confident account managers can be in their product managers, the less likely they are to escalate their personal concerns.
Second, by asking account managers to rank the importance of their product requirement against those of their peers, a valuable perspective is often gained—improving the ability to prioritize requirements. The account manager will now understand where this requirement ranks against those other things you are trying to do.
With good Requirements Management, the conditions forescalation sanity prevail.
Why can’t I get my PRD to developers before they begin development?
This sad phenomenon is much more pervasive than any of us would care to admit. We just cannot seem to qualify a project’s scope before healthy development is already underway. This phenomenon stems from a short-sighted or unwieldy PRD thrown together under tremendous time pressure. When this happens, the company fails to capitalize upon its industry experience, or worse, gets caught in a web of uncertainty and poor communication among important stakeholders.
But what if we have been developing and prioritizing requirements for future products on an ongoing basis? This approach makes a lot of sense. Product requirements come from different sources all of the time, so it is wise to also refine those requirements on an ongoing basis.
Companies try and tackle this problem of delivering timely PRDs by leveraging template documents. I urge caution here. Templates are fine when the requirements are already well understood. For example, a template might be fine if you are rolling out a series of releases to support a matrix of different underlying hardware or software platforms. But otherwise templates add little value. Your developers have little interest in the template’s boilerplate text, and they are forced to wade through pages of verbosity to find the actual product requirements.
A stable, customer-driven, long-term approach to managing requirements overcomes many of these problems.
What do a product release and a birthday party have in common?
In a word, surprises! But while a birthday party is usually full of nice surprises, product releases tend to offer an abundance of an entirely different type of surprise.
The product manager going through the process for the first time is usually perplexed and dismayed by the gap between what the customers desired and what the developers achieved. So why don’t product managers and developers agree much earlier in the process about which requirements make it into the product and which must wait until the next release?
In fact, product managers and developers typically do make a sincere effort to track which requirements are in and which are out. The problem lies in the complexity of the process, which often stifles and frustrates their efforts. Perhaps only part of a requirement will make it into this coming release, and the other requirement is actually two unrelated requirements. Or one development group will do what they need to do for the requirement, but another group will not. It is the management of all this complexity that can suffocate even the sincerest attempt.
By now it should be clear that in any customer-driven organization, the tracking and delivery of critical information to the most important stakeholders of a project is vital to its success.
Do I need specialized tools to help me with Requirements Management?
Perhaps—but not necessarily. Having the right set of tools can help you circumvent some big questions, but it is important to match the tool to the process that works best for you.
Consider the Iron Triangle of Project Management. The Iron Triangle comprises three sides: scope, schedule, and resources. You might ask three simpler questions: What are we going to build? When do we need to be finished? And how are we going to get it done?
Now look at the tools used by each of the three branches. The developers, charged with the last question often are supplied with amyriad of tools to help them go about their task. Their tools may include software development tools, hardware emulators, computer-aided design tools, testing tools, etc.
The project managers need to answer the second question: “When do we need to be finished?” To keep the project on schedule, the project managers also have their specific tools—often bringing to bear the ubiquitous Microsoft Project®, but there are other tools equal to the task.
There remains the first and arguably the most important question that product managers must answer: “What are we going to build?” Scope is the foundation of the entire project, and yet the tools that product managers employ sometimes pale alongside the importance of their charge.
Which tool is best for your process? An individual responsible for a simple or one-time project may make do with Microsoft Word® or Microsoft Excel®. I’ve even seen Microsoft PowerPoint® used effectively. However, such tools struggle to help a team manage the fluidity and complexity of other types of products—especially technology products. Those tools are specifically designed for individual use. It is only with extreme awkwardness that a Word or Excel document can even be edited by more than one person.
Do companies need a tool that links all three sides of the Iron Triangle? Not necessarily. While it is extremely important to have a process that allows the three groups to work together effectively, it is usually not necessary to force them all to use a single tool. Each of these groups conduct their work very differently, have very different motivations (albeit compatible ones), and very different needs from such a tool.
In life-critical products where quality is extremely important, it may be very appropriate to manage the entire development process from a single tool. But on balance, I would recommend a pragmatic approach in which you match tools that are appropriate to your process to the individual members of your team.
A concluding thought…
Being effective at managing requirements does make you a better product manager. Your decisions become more objective and timely, your collaboration efforts become more fruitful, and the stakeholders you work with become more supportive.
