8 minute read
Writing market requirements documents is not a mysterious black art, although it may sometimes seem that way. Requirements convey details of a customer’s problem to the reader, which is usually a designer or developer. At their core, these documents serve as a bridge between the customer’s needs and the development team’s innovative solutions.
Well-crafted market requirements documents capture the essence of a problem and outline it clearly. This gives designers and developers the information they need to tackle the challenges effectively, and sometimes in ways that surprise even the author or the end-user.
What is a Market Requirements Document?
It takes a deep understanding of the market and customer needs to create a great product. A Market Requirements Document (MRD) is the tool that consolidates this understanding and makes it usable. It is the MRD that allows you to transform insights into actionable guidance for the product team.
By identifying and prioritizing customer needs, an MRD ensures that innovation is driven by real-world problems. This sets the stage for meaningful solutions and successful products. Without it, products would be guided by guesswork, pet projects, and other non-objective factors.
Distinguishing MRDs from PRDs
While the terms Market Requirements Document (MRD) and Product Requirements Document (PRD) are sometimes used interchangeably, they serve distinct purposes and audiences:
Market Requirements Documents: Focuses on identifying and prioritizing market problems. These describe the “why” behind the product or feature and define the needs of the target personas. The audience for an MRD includes product managers, executives, and marketing teams.
- MRDs capture market insights and customer pain points.
Product Requirements Document (PRD): Translates the MRD into specific product features and technical specifications. It focuses on the “how” to address the market problems outlined in the MRD. The audience for a PRD includes designers, developers, and QA teams.
- PRDs define how pain points are addressed by the product.
How to Write Market Requirements Documents
Successful organizations use processes and repeatable steps to innovate products. This lets them repeat their successes and reliably deliver the types of products the market expects from them. You can see evidence of reliable innovation in some of the top brands on the market today, like Apple, Samsung, and Nike.
Having a process in place for writing market requirements documents is a good start to having a repeatable process in place for product innovation.
By following these steps, product managers can create MRDs that provide a clear roadmap for developing solutions that resonate with the market.
- Identify Market Problems: Start by gaining an in-depth understanding of the target market—its personas, challenges, and unmet needs. This takes research such as customer interviews, surveys, and market analysis.
- Prioritize Problems: Not all problems are equally important. For example, you don’t want to put time and money into solving a problem people aren’t willing to pay to solve. Use tools like impact/effort matrices or weighted scoring to rank market problems based on their significance and business value.
- Define Personas and Use Scenarios: Create detailed persona profiles for users and buyers. Articulate use scenarios that explain what the persona is trying to achieve, the problem they face, and how often this problem occurs.
- Document the Problems: Write clear, concise requirements that focus on the problems without prescribing solutions. Just consider yourself as the user and focus on what’s wrong, not how to fix it. Ensure the requirements are SMART (Specific, Measurable, Achievable, Realistic, and Time-bound).
- Validate and Iterate: Share the draft MRD with stakeholders, including customers, sales, and development teams, to ensure alignment and accuracy. Refine the document based on feedback.
Remember, the goal of market requirement documents is to align products with the needs of real, paying customers. It’s easy to get excited about features or technology and forget this. In Alan Cooper’s book “The Inmates are Running the Asylum”, he suggests that many technical products aren’t designed for the user, but for the developer or not truly designed at all. However, poorly designed products frustrate customers, so once you have a process in place, work to refine and improve it.
Traditional Requirements
The traditional definition of a requirement is a statement identifying a capability, physical characteristic, or quality factor that bounds a product or process problem for which a solution will be pursued.
Traditional requirements are categorized into the following five types:
Functional: Observable capabilities that must be present for the persona to complete their goals or perform the task specified by the use scenario
Performance: Characteristics of capacity, speed, concurrency
Constraints: Conditions that legitimately limit the design
Interface: Defined interaction with hardware and software components
Security: Compliance with government mandate and customer privacy
Software vendors may also need to consider these unofficial types of requirements, for example:
- Standardization
- Certification
- Installation
- Implementation
- Customization
- Localization
- Documentation
- Education
We often see this traditional approach implemented poorly, combining the requirement with a specification, or rather, the statement of the problem as well as a proposed solution to the problem.
However, these types of requirements remind us to look beyond problems that result in a feature (functional requirements) to include problems that impact performance, installation, customization, and so on (non-functional requirements). Whatever form you use, be sure to convey the parameters of the problem.
Product managers write market requirements in the words of the persona, in business or personal terms, rather than offering a technical definition. A requirement should be short, only one or two paragraphs, never more than a page or two.
The key takeaway: Product managers write requirements to document the problem without a recommended solution to the problem. The Market Requirements Document combines multiple requirements into a coherent whole. For a new product, a requirement states a business problem the potential customer is having that will be addressed. Market requirements documents for an existing product might document a usage problem for existing customers.
Market Requirements Document Best Practices
What makes market requirements documents good? MRDs are only as good as the requirements within them. In general, a good requirement conveys the context of the problem. How do you know you’ve done it right?
There are a few ways to evaluate your requirement before you get it in front of a team of designers. One method is SMART, which stands for:
Specific: Requirements should specify what they are to achieve.
Measurable: The requirements should provide a metric whereby all stakeholders can determine if the objectives are being met.
Achievable: Are the requirements’ objectives achievable and attainable?
Realistic: Are the requirements realistic with respect to the available resources?
Time-Bound: When will the team achieve the requirements’ objectives?
The trick of writing good requirements is to convey the critical information in a form that developers and designers can embrace. This means that it has enough detail to provide context but not so much that it overwhelms the reader.
A well-written requirement helps the designer make decisions without needing to turn to the product manager continually throughout the day. Here are some questions to ask yourself:
- Have I provided adequate context?
- Have I given enough details?
- Can the designer imagine the appropriate solution?
- Have I communicated clearly?
Using Stories and Personas for MRDs
The story approach to writing market requirements typically works to everyone’s advantage. Stories are powerful. They put designers and developers in the customer’s chair so that they see the problem from their point of view. They also quickly provide context as to how and why the problem occurs and why a solution is needed.
It also happens to be a simple and natural approach: “Tell me a story. What is happening? What is the person trying to achieve?”
Here are some questions to guide the creation of your user story:
- What is the persona doing to cause this problem?
- How does the persona do it now?
- How might the persona like to do it?
There are many formats and definitions for user stories. You may also hear these called use cases, use scenarios or use stories. Whatever you call them, our preferred format goes like this:
[Persona] has this [problem] with [frequency]
Here is an example:
“Sarah, the college student, needs to pay her tuition each semester using multiple credit cards.”
“Sarah” is the persona, “pay tuition” is the problem, and “each semester” reveals the frequency of the problem. You’ll notice that this problem is absent a proposed solution because that is for others to work through.
If you ever have difficulty starting a use scenario, it is helpful to remember that the tone is always “imagine if you will….” followed by a description of the situation and problem. You can read more about personas here.
You should provide contact information for two or three potential users of the product who can be reached by the designers to provide real insight and clarification. A product manager is usually not a necessary interface between the developer and the customer. Just provide phone numbers and email addresses so the team can contact them directly for feedback.
When questions arise about an implementation choice, the team should find the answer in the use scenario. Also, provide requirements and use scenarios to QA for their test plans. The ideal test plan ensures that the problem was resolved, not that the design was achieved.
Artifacts for Requirements
Once you have all the elements, what form should be used to communicate them to the organization? You need more than a “cocktail napkin“, but you don’t need it to be a hundred-page tome either.
Requirements are most effective when integrated into a broader context of product planning. Key artifacts include:
- Business plan
- Product roadmap
- Requirements
A business plan includes information about the business of the product. Typically, we update the business plan annually to compare last year’s goals to the actual results. Items that belong in the business plan are:
- Research regarding market problems
- Results from win/loss analysis
- Market definition and sizing
- Distribution strategy
- Distinctive competence
- Financial plan
A product roadmap has become the most popular artifact for representing product strategy. A roadmap shows phases of deliverables over the next 18-36 months or through the next three or four product releases. Most teams prefer to keep the roadmap as a separate document to share with both executives and the product team, but some firms include this document in the business plan.
The market requirements document (MRD) contains a prioritized list of problems for your target personas. The contents include:
- Persona definitions
- Phases of deliverables
- Requirements (problems with use scenarios and frequency)
There you have it. A business case reveals your plans for the product as a whole. The roadmap shows phases of deliverables over the next few cycles. The requirements document contains the details of the problems that will be addressed in the next release or product version.
Effective market requirements documents bridge the gap between customer problems and innovative solutions. By focusing on personas and their pain points and leveraging best practices for writing requirements, product teams can create products that delight users and drive business success. Remember, the ultimate goal of an MRD is not just to document problems but to inspire solutions that resonate with the market. That means MRDs are at the heart of building products that people want to buy.
