Market Requirements Document – What is a MRD?

It’s a question we hear all the time… What is a MRD? So we created this guide to help individuals, teams and companies answer that question.

To kick off the conversation with development, Product Managers start by identifying what they have heard from customers. The document that they use is called the Market Requirements Document or MRD. 280 Group uses a variation on this terminology. Of the 9 core documents that guide the development process, the 280 Group version is called Market Needs Document. Why change from market requirements to market needs? It has to do with the confusion surrounding the term requirement.

Documenting market needs is the first step in communication and negotiations with product development. If you skip this step, you’re at a significant disadvantage when working with product development. You might not even realize that you’ve gone off course until it’s too late to course correct.

Comparing Market Requirements Documents and Product Requirements Documents

The Market Requirements Document has historically been used in waterfall and phase-gate development processes rather than Agile. It is designed to capture a deep description of the market needs that customers have. In Agile product development, a short Market Requirements Document is an effective way to capture and understand the market needs before diving into writing user stories and cranking out features in the product backlog as fast as possible.

The Market Requirements Document is accompanied by the Product Requirements Document (PRD). Oftentimes, the company is so excited and pressured to create the product rapidly that many organizations do away with the Market Requirements Document and jump right to the Product Requirements Document (or, in the case of Agile, simply put together a list of product features as a backlog, write user stories and start developing the product without discussions or a deep understanding of customer needs).

The Product Requirements Document often includes a section to explain why the customer needs the product. If you aren’t going to produce an Market Requirements Document or a Product Requirements Document, make sure that you at least have an in-depth discussion and get agreement with your team about the context of the product – why will your customer want this product. Also discuss what the true market and customer needs are – and how the product features will solve that need.

Gathering the Necessary Information for MRD

Developing a market requirements document involves collecting information that gives the context of the problem, who experiences it and when the experience occurs. The Market Requirements Document has three key components as input and one final one which documents what the customer needs to accomplish – their “market need.”

• Personas
• Problem scenarios or problem statements
• Customer journey/workflow
• Market needs statements

Creating Personas

The idea is to begin with the customer in mind, and the most common method is to define the personas that your product interacts with. Personas are archetypes of people that share similar characteristics. To define a persona, you’ll need to define the following attributes of each persona.

Persona attribute – Attribute explanation:

• Name – Name each persona.
• Role – What is the persona’s role in the product purchase decision? (user, buyer, influencer…)
• Goal – What problem is the persona trying to solve that your product provides some or all resolution to?
• Background – What is the persona’s background that informs how it reacts to your product?
• Attitude – What is the persona’s attitude toward the product or actions that you’re asking it to take?
• Behavior – What is the persona’s observable behavior with respect to your product offering?
• Insight – Do you have any other insights into the persona’s reaction to your product that hasn’t been covered elsewhere?

Problem Scenarios or Problem Statement

When you’ve defined all the personas, your next step is to create the problem scenarios that cause them to need your product. The product should be the “Aha, you fixed my problem!” solution to the problem.

Problem scenarios contain the following information:

• Primary goal: What is the primary goal of the customer in this particular situation?
• Persona(s): Who has this problem and is trying to reach this particular goal?
• Background: What is the background situation regarding why the customer want to achieve the goal? Think of the difference between a person trying to park on a wide-open street with few cars on a sunny day versus someone parking at night in a crowded muddy lot during a rainstorm. The background is important.
• Frequency: How often does this problem happen? Every day? Once a year?
• Trigger: What causes this problem to arise?
• Description: What are any other details you have that describe the problem in its entirety?

Customer Journeys and Workflows for Your Market Requirements Document

Customer problems aren’t always a single point situation. In many instances, particularly in a sequence of software interactions, an overall goal is achieved by resolving a series of problems along the way. The sequence is either defined from the customer’s perspective using a customer journey or the sequence of tasks that the software needs to help different users navigate from start to finish. This last one is called a workflow. The more technical the sequence and the more people involved at each step, the more likely that a workflow point of view works better.

Start by defining a customer journey using two pieces. Define the overall goal of the customer and then the specific problem points along the path to problem resolution. At each stage of the journey, identify the following from the customers’ viewpoint:

• What action do they need to take to get to the next step?
• What is their motivation (or lack thereof) in moving to the next step?
• What questions do they have at this point in their journey?
• What barriers are in the way of them completing this particular step?

Market Needs Statements for Your Market Requirements Document

When you’ve sorted out your personas, worked out what problem you’re trying to solve for each persona, and determined where they are in their journey toward solving their problem, your market need becomes much easier to write.

The traditional format is written as follows for market needs that must be met:

• Option 1: User [persona] MUST be able [achieve result]
• Option 2: User [persona] MUST be able [solve problem]

For those market needs which you would like to have, but may not have time to develop, you can indicate how desirable it is to address this customer need. The format is written as follows:

Remember that the market needs (from the Market Requirement Document) and product feature descriptions (from the Product Requirements Document) are intricately linked. As you work to resolve the differences between the two points of view — that of the Product Manager and that of the product development organization — remain flexible.