What Is a Market Requirements Document (MRD)?

A market requirements document, or an MRD, is a strategic document written by a product manager or product marketing manager to help define the market’s requirements or demand for a specific product. An MRD typically contains information on the product’s vision, the competitive landscape, business analysis, and revenue opportunity, as well as a list of features or at least high-level feature categories.

What Goes into a Market Requirements Document (MRD)?

A market requirements document should answer several strategic questions that help the company identify a potential market need. The key questions to ask are:

• What is the market we’re targeting, and why do we believe it’s worth pursuing?
• What is the potential revenue available from this market?
• Who are the buyer and user personas in this market?
• What are the problems we can solve for these personas?
• How will we solve those problems?

Example: The details an MRD would include

Let’s say you are the product manager for a software company that makes data analysis tools. You’re thinking about building a new tool for data preparation. It would be an app that helps non-technical analysts and researchers pull data together from several different sources to create useful reports.

The non-technical qualifier is the key because most data prep software requires some coding skill or knowledge of how the technical backend of databases works. You have identified a market—business analysts who have no technical background—that would benefit from a user-friendly app that lets analysts pull data together by simply dragging and dropping fields or entire databases from various sources.

5 Questions to Ask When Shaping Your MRD

1. What is the market we’re targeting, and why do we believe it’s worth pursuing?

You might determine the market for this product will be several industries that have not historically purchased data preparation tools and therefore need a very simple, user-friendly solution for business analysts.

2. What is the potential revenue available from this market?

The revenue number you arrive at might take several forms. For example, you can estimate the total addressable market (TAM) and then estimate what percentage of market share your product could earn from that TAM. You can also estimate the number of users or licenses your company will be able to sell over time, and then multiply that number by the monthly fee you plan to charge. It will give you an estimate of monthly recurring revenue (MRR).

3. Who are the buyer and user personas in this market?

The users will be non-technical business analysts at large organizations. The buyer personas will be large-enterprise business managers who require data reports from their teams and the IT executives who typically purchase software solutions for their companies.

4. What are the problems facing these personas that we can solve?

Let’s say you determine that these user personas have difficulty pulling together data from various databases and apps. Their companies have not bought apps specifically for this function before, so these analysts have found ways to compile and study data manually. It makes it difficult and time-consuming for their companies to access the business intelligence they need to make informed decisions.

5. How will we solve these problems?

To answer this question, you will come up with a short description of the features or summaries of the types of functionality your product will need. For a new data prep tool, that list might include:

• Data connection: Connect to databases from different sources
• Data blending: Standardize different sources’ data to make it easy to analyze
• Report generation: Produce user-friendly, visual reports with a few clicks

Note: An MRD is an early-stage strategy document. It should remain high level and the “How we solve the problem” section should include only brief strategic descriptions of the features you are proposing. Creating the detailed discussions of each feature, and the user stories that go along with them should come later—only after your team has decided to move forward with the product.

Do Agile Product Teams Use MRDs?

The short answer is yes: Many agile teams write MRDs.

Market requirements documents were used for decades in companies that built products using what we now call the waterfall methodology. Using this sequential approach, an organization sets a comprehensive plan to build the product before working. Once they start, the team does not turn back, and they do not adjust their plans regardless of early feedback from users.

In this waterfall environment, MRDs are valuable documents because they help set the long-term plan for the product’s development. In waterfall organizations, teams often write highly detailed MRDs that can run dozens of pages.

On the other hand, in an agile company, an MRD is also a useful tool. It helps the product team identify a market opportunity and articulate it to the rest of the organization. The key difference is that in an agile organization, the MRD is very short and high level. That is because the team uses the MRD only as an initial strategic guide. An agile company leaves itself the ability to alter course often based on how the market responds to the product.

Where Does an MRD Fit in the Product Management Process?

For agile organizations that write MRDs, here is a standard sequence of the main documents the team will develop. Each one helps to inform the drafting of the next.

1. Market Requirements Document (MRD)

This document identifies a potential market opportunity: the who, what, and why of the market, and a high-level explanation of how the proposed solution will help that market.

2. Product Requirements Document (PRD)

This document communicates the capabilities the product will need.

3. Product Roadmap

This is a high-level strategic blueprint that communicates the strategic plan and objectives for the product.

4. Product Backlog

It is the prioritized list of task-level details needed to execute the strategic plan outlined in the product roadmap.

5. Sprint Backlog

Drawn from the product backlog, this is the list of cross-functional team plans to work on in the next sprint.