How to Write a Market Requirements Document

Table of Contents

• Introduction
• The Anatomy of a Capital Equipment MRD
• How to Ensure You Get the Intended Product
• 7 Attributes of Great Product Requirements
• When to Start and Finish Your MRD

Introduction

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.

The Anatomy of a Capital Equipment MRD

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.

The Business Case

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:

1. Is the opportunity real?
2. Can we win?
3. Is it worth it?

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.

Real-Win-Worth Element	MRD Business Case Section
Worth	Objective
Real	Opportunity
Win	Vision for unique value
Worth	Potential returns

For the key questions you must answer in each business case section, see Table 18.

Business Case	Key Questions to Answer
Objective	What are your market share targets? What are your revenue targets? What are your gross margin targets? When will you achieve them?
Opportunity	What market are you targeting? What are the growth drivers? Who are the most important customers? What is the total available market forecast? What is the target market’s unmet need? What are the application requirements? What are the customers’ buying decision drivers?
Competitive landscape	Who are your competitors? What are their product offerings and strategy? How do their current product offerings and strategy compare to your current offerings? How do your current product offerings compare to competitors’ offerings in the future?
Vision for unique value	What is the new product’s value proposition? What positions will you take? What is the product’s target price? How will your new product compare to your competitors’ offerings at the time of introduction? What is the customer value model?
Potential returns	What financial gain is possible if you pursue the new product?

Product Requirements

The second section of your MRD describes the product requirements that will satisfy the business case. You arrive at these product requirements by merging application requirements and your vision for

unique value. Application requirements are those things that your product must do to address the customers’ use case. Your vision for unique value identifies those things you intend to do better than the competition to win your target customers’ business. See Figure 52.

For the key questions you must answer in each product requirements section, see Table 19.

Product Requirements	Key Questions to Answer
Timing	When is the product required in the market to hit the business case objectives? What interim milestones must the new product hit to support pre-launch marketing activity?
Platforms	What platforms, components, or interfaces will you require from an external perspective to be common with other products?
Installed-base upgrades	What elements of the new product will you make available to the previous generation installed base? What are their performance and cost targets?
Performance verification	How will you test the new product to reflect usage in the customers’ environment? What data will you collect?
Performance	What are targets for those specifications that must exceed competitive benchmarks to achieve your vision for value and competitive advantage? What are the specifications for everything else?
Cost	How much does the product need to cost to achieve the profitability targets described in the business case? What are the configuration assumptions for the cost requirements?

How to Ensure You Get the Intended Product

Imagine this. You followed your company’ process. You detailed every product specification. Your voice-of-the-customer validation confirmed that this is the product that the market needs. Management unanimously approved your MRD.

You were on the path to a winning product. Or so you thought.

A year later, the development team produces a far different product than the one you intended. It is way off the mark.

How could this have happened?

Most MRD processes ensure that the requirements for a product are complete. This is necessary but insufficient to ensure a winning product. MRDs must also communicate intent.

Immediately after management approves your MRD, the development team will begin figuring out how to implement the product requirements. This team will make many trade-off decisions to produce a product that addresses as many of the requirements in the MRD as possible. The final product will almost certainly differ from the one described in the MRD. That is the reality of technology, time, and budget constraints. But if equipped with just a list of product requirements, the development team has no guidance for making these trade-off decisions. If you are not getting the product that your MRD intended, your MRD might be missing these three things.

1. Objective
2. Vision for unique value
3. Performance verification requirements

It is these three things that communicate your MRD’s intent.

Objective

Every task, project, and mission should start with an objective. Your MRD is no different. In an MRD, state the objective as a business outcome. Most often, it is some combination of market share, revenue, and gross margin. For example, an MRD objective might be:

“Introduce a new ingot casting furnace for the photovoltaic multicrystalline silicon wafer market that will achieve more than $160M in revenue representing 35% market share with 56% gross margin by 2025.”

Vision for Unique Value

Your vision for unique value describes what you need to be true about the product to capture enough customers at high enough prices to meet your objectives. It communicates the path you intend to take to reach the product’s objectives.

Include your draft positioning statement and value model in this section.

Performance Verification Requirements

To ensure that the new product meets your intent, you need to let the development team know how to verify your intentions. You capture this in an MRD as performance verification requirements.

Here you describe how the user will run the system in their environment, including materials, operating procedures, and success measures. In this section of your MRD, specify:

• Success criteria
• Test conditions that simulate the customers’ use case
• The test data that the development team must collect

This forms the framework for product release testing. The performance data it produces will verify whether you have achieved your vision for unique value and if you can realize your objectives.

7 Attributes of Great Product Requirements

That high-quality product requirements in your MRD are necessary to ensure that engineering produces the intended product is obvious. What is not so obvious is how to measure product requirement quality. Without a standard for evaluating goodness, you risk your new product development program getting off on the wrong foot. You can reduce that risk by using the seven attributes below to help you assess product requirement quality in your MRDs:

1. Design-free
2. Defendable
3. Clear
4. Lean
5. Complete
6. Concise
7. Testable

1. Design-Free

High-quality product requirements do not describe the implementation. Instead, they describe buyer requirements. Buyer requirements include:

• Compatibility with the customer’s environment
• Inputs to your equipment
• Outputs from your equipment
• Compliance with regulations and standards

See Figure 53.

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.

Whereas…

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:

• Regulatory requirements
• Standards compliance
• Compatibility with the customers’ environment
• Compatibility with the customers’ supply chain

2. Defendable

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:

1. Why is it needed?
2. How do you know?

All your answers should relate to the business case and reference data from your markets, customers, and competitors.

3. Clear

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.

This is not:

The vehicle must have a cell phone call dialing and answering system.

4. Lean

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.

5. Complete

Product requirements in an MRD are complete when they fully describe the intended product and, when met, the new product will:

• Completely address the target market need.
• Create the intended competitive advantage.
• Achieve the desired commercial success.

6. Concise

Concise requirements ensure you effectively communicate your intention. Concise product requirements in an MRD are:

• Easily scanned.
• Typically structured in tables.
• Never buried in prose.

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.

Item	Requirement
Compatibility	Bluetooth V3.2 or later
Connection	When vehicle accessory power is on, the vehicle shall detect and connect to any previously paired Bluetooth-enabled cell phone with no operator intervention.
Operation	Driver must be able to dial and answer a phone call from a Bluetooth-enabled cell phone without diverting eyes or hands from the task of driving.

7. Testable

You must be able to pass-fail test each product requirement. Let us again return to our vehicle’s cell-phone integration requirement to illustrate.

This is pass-fail testable:

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.

This is not:

Cell-phone call dialing and answering system must be easy to use.

When to Start and Finish Your MRD

You need to complete your MRD sufficiently before the product’s planned market introduction to allow for product development. Consider that your MRD development process will include at least one iteration of the following two steps before submitting it for approval:

1. Draft/Revise
2. Voice-of-the-customer market validation

The time to go through each cycle and the number of cycles needed varies widely. For simple product extensions for already served markets, MRD’s might take just a few months. Whereas MRDs for new markets, new application requirements, or a step-function capability improvement might take a year or more. See Figure 54 for an example of an MRD development timeline.

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   Presented as: Business case Product requirements	Details of: Design approach Product specifications Schedule Resource plan Financial plan Developed from: Requirements analysis Resource assessment Concept selection

MRD and PDP Approval

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:

• Is the opportunity real?
• Can we win?
• Is it worth it?

Regarding the product requirements:

• If you introduced the product as described, would it satisfy the business case?
• Are product requirements described with enough completeness and clarity to develop a PDP?

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.

An MRD and a PDP Do Not Have to Match

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.”

Both MRDs and PDPs Can Change

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.