What is a market requirements document (MRD)?
A market requirements document (MRD) is a document that communicates the customer’s wants and needs for a product or service. It is often confused with a product requirements document (PRD), but they are not the same. The PRD describes how a product should be built and helps broader cross-functional teams understand what a product should do.
The MRD describes the market opportunity and should be created prior to the PRD. This approach allows the PRD to be informed by the findings of the MRD. It ensures that the team will clearly understand the customer’s unmet needs before defining requirements.
How is an MRD used?
Traditionally, MRDs and PRDs are used in waterfall and phase-gate development methodologies to capture a deep understanding of the market needs that customers have. The waterfall approach puts an emphasis on documentation because requirements have to be thoroughly gathered and defined upfront before the work begins. However, in agile product development, a short MRD is strongly preferred as an effective way to quickly understand market needs before writing detailed user stories and investing a meaningful amount of effort and resources.
Who creates the MRD and why is it important?
There are so many ideas for new products and services and it can be challenging to know what to build next. But it is your responsibility as a product manager to define and prioritize which problems to solve. For this reason, product managers typically own writing an MRD. However, since this document is rooted in market research, product managers often collaborate with product marketing.
Writing up an MRD before investing time, money, and resources can help reduce waste. For opportunities that are worth pursuing, the MRD helps you define what will be required to succeed. This means you can focus on moving forward with the work that is aligned with your product strategy and that will be the most impactful for your customers.
How should an MRD be structured?
There are key questions that your market requirements document should answer. The MRD should leave no questions about the customer’s wants and needs for your product and the opportunity that is available. To accomplish this, organize your MRD with the following structure and ensure it answers the included questions:
What problem are you trying to solve?
Provide a concise report of your findings, assumptions, and suggestions. The executive summary can be thought of as a miniature version of the entire document.
What makes your product or service unique?
Your vision should represent the core essence of your product. It should set the direction for where your product is headed or the end state for what your product will deliver in the future.
How big is the opportunity or market size?
Detail the specific market size and document the assumptions and facts that validate and justify the market opportunity.
Who are you solving the problem for?
Create a persona for each possible person related to the market opportunity and planned solution.
What alternatives currently exist?
Your competitor analysis should focus on detailing how customers are solving the problem today. Understanding all the different options available to your prospective customers helps you differentiate your offering and establish a competitive advantage.
What functionality must be included to solve the customer’s needs?
Write out the operational characteristics and the working capabilities required of the solution. Avoid detailed design and development specifications. Instead, outline the solution from the customer’s perspective by describing what they wish to accomplish.
How will you measure success?
The information in this section should be connected to your business model. Consider how the company will generate income from your new product or how this new feature will affect pricing. With the details you include here, everyone can understand the key metrics that you are measuring.
Challenges with the MRD
The traditional method of long-form MRDs can be a lengthy process. In a waterfall approach, the MRD must be finalized before any work can begin. And often, by the time it is finished, the information contained in it is outdated.
Today, many teams want to work faster, iterate, and collaborate in parallel with cross-functional teams. To do this, they use purpose-built product management software to write user stories and link that work to strategic goals and initiatives. This creates a more agile approach to building products and saves you the time spent writing a new MRD for each release.
Whether you choose to write a detailed MRD or find a more lightweight approach, the output will illuminate why customers want your product or feature, who the solution is for, and what will be required for a successful solution. You can now turn your attention to the next step — defining how your new product or feature should be built. To do that, you can use a PRD template to make sure you capture the right details.