Your product roadmap describes the products that you intend to develop and bring to the market over time. Each product on the roadmap needs a market requirements document (MRD) to detail for whom the product exists, what it must do, and how well it must perform to capture customers and make a profit. The MRD defines what the organization must do to produce a winning product.
Unfortunately, some organizations dismiss the MRD as some irrelevant puffery produced by the marketing department. Clues that yours may be one of these organizations would include hearing sentiments like:
“I don’t know why we need an MRD. What really matters is the engineering development plan.”
“Just give me the product specs. I don’t care about all that marketing fluff.”
“Why do I have to sign this?”
“We should just combine the MRD and the engineering development plan to save time.”
These sentiments signal a failure to recognize that the MRD guides the organization to make robust decisions about which products to develop. However, for the MRD to do its job, authors must structure it to support decision making, and the organization must understand its role in the product strategy and product development processes.
At the highest level, you need two things to define a winning product. You need a business case to define the win, and you need a set of requirements to define the product that satisfies the business case. An MRD is the marriage of the two. See Figure 51.
You cannot consider an MRD’s business case and product requirements separately. The business case is based on assumptions about the proposed product’s revenue timing, competitiveness, and profitability. The product requirements must be consistent with those assumptions. To be sure that they are, document, review, and approve both sections of the MRD together.
An MRD’s business case helps management decide whether to pursue your new product recommendation. To make that decision, they need to know the answers to the following three questions:
This real-win-worth screen is a simple but powerful means to test the viability of ideas for new products. An MRD’s business case helps management apply this test. See Table 17.
For the key questions you must answer in each product requirements section, see Table 19.
Suppose that you were specifying the requirements for a vehicle’s cell-phone compatibility. A design-free way to express this might be:
A vehicle’s driver must be able to dial and answer a phone call from a Bluetooth® V3.2 enabled cell phone without diverting eyes or hands from the task of driving.
Controls to dial and answer a call on a Bluetooth-enabled cell phone shall be mounted on the steering wheel.
… is not design-free.
One exception to the design-free rule is when you must specify implementation requirements for your equipment’s interfaces to the external environment. Examples may include interface design requirements dictated by:
Each product requirement must also be defendable. The source and rationale for each requirement should be clear. You must be able to answer the following two questions to the organization’s satisfaction for each product requirement:
All your answers should relate to the business case and reference data from your markets, customers, and competitors.
There should be only one interpretation of each requirement in the MRD. This is necessary to ensure that the product engineering builds reflects the intended product.
This is a clear requirement:
A vehicle’s driver must be able to dial and answer a phone call from a Bluetooth V3.2 enabled cell phone without diverting eyes or hands from the task of driving.
The vehicle must have a cell phone call dialing and answering system.
Alarm bells should go off if a product manager presents an MRD to you with all the product requirements set to be better than the competition. It is an indicator that the author does not understand the customers’ buying behavior. Not to mention that engineering probably cannot build this best-at-everything product.
Lean product requirements set buying decision drivers to be better than the competition and all others to be simply good enough. These lean requirements will produce a new product that delivers the most customer value for the least amount of engineering.
Product requirements in an MRD are complete when they fully describe the intended product and, when met, the new product will:
Concise requirements ensure you effectively communicate your intention. Concise product requirements in an MRD are:
Again, using the cell-phone compatibility example, the following is not concise:
Bluetooth wireless communication has become a common mechanism for connecting cellular devices to vehicle entertainment systems. While Bluetooth has gone through many revisions, the vehicle shall be Bluetooth enabled and compatible with all Bluetooth versions since the release of V3.2. The vehicle shall connect to a Bluetooth-enabled device anytime that the accessory power is on, and the device has been previously paired with the vehicle’s Bluetooth connection system. This connection must happen automatically with no operator intervention. When making phone calls or answering them, the driver, whether a man or a woman, must be able to dial and answer a phone call from a Bluetooth-enabled cell phone without diverting his or her eyes or hands from the task of driving.
Whereas the requirements in Table 20 are concise.
MRD vs. the Product Development Plan
An MRD is not a product development plan (PDP). The MRD makes a business case for developing a new product. An MRD seeks to answer the question, “Should we do it?” A PDP is a response to an MRD that seeks to answer the question, “Can we do it?”
You must keep MRDs and PDPs separate. If you do not, you could end up making product investment decisions based on internal capability, without the context of what customers will buy. You could end up building the product right, but not necessarily the right product.
See the key differences between an MRD and a PDP in Table 21.
| MRD | PDP | |
| Decision | Should we do it? | Can we do it? |
| Contents | Assessment of: Market needs Competition Potential for advantage Profit opportunity |
MRD approval should be a major and formal decision in any product lifecycle management process. That approval should be based on the MRD’s ability to produce a “yes” to each of the questions below.
Regarding the business case:
Regarding the product requirements:
The measure of success for an MRD is not necessarily whether it gets approved. It is how well your MRD equips your organization to make an informed, high-quality decision about the opportunity and the product.
If management approves the MRD, you are ready to move on to the next step; creating and approving a PDP that addresses the product requirements in the MRD. It is important to emphasize that approving an MRD does not commit to developing a new product. It simply approves the organization to spend the time and resources necessary to develop a PDP. Management has not given the go ahead for product development until management approves the PDP.
Typically, the MRD and PDP approval processes secure signatures from product management, the product development team, and the business owner. See the meaning of stakeholder signatures on MRDs and PDPs in Table 22.
| Signature | MRD Meaning | PDP Meaning |
| Product management | This is our recommendation. | PDP satisfies an acceptable business case. |
| Product development team | We have received and understand the product requirements. | We commit to execute per the PDP. |
| Business owner | OK to proceed with developing the PDP. | OK to proceed with product development. |
The back and forth goes something like this. Marketing completes the MRD and reviews it with engineering. Engineering responds with a PDP. The PDP inevitably will show product capability, cost, and release timing targets that do not line up perfectly with those in the MRD. But it is a reasonable plan and substantially satisfies the business case. So, management approves the PDP.
Then comes the order to update the MRD to match the PDP. This is folly. The “M” in MRD stands for “market.” The market does not change to match the capability of the supplier. If you change the MRD to match the product plan, you no longer have an MRD. You have another copy of the PDP.
It is fine to approve a PDP that deviates from the MRD if everyone agrees it describes a worthy commercial endeavor. When the stakeholders approve a PDP, it becomes the plan of record. It would be foul play to hold up the MRD if the program later runs into trouble and say, “But that’s what I really wanted.”
New capital equipment development projects often take more than a year to complete. During development, markets and competitors will move in ways that you did not expect when you wrote the original MRD. You must account for these changes in your product development program, or you risk bringing the wrong product to the market. Revalidate your MRD at key product development milestones and change it if needed. That way, if the environment has changed, you can adjust before it is too late. The PDP can change when either the MRD or the execution outlook changes. As explained earlier, the MRD and PDP do not have to match. Therefore, changes to the PDP do not precipitate changes to the MRD.
