How to write a Market Requirements Document (MRD)
The MRD is the principle product strategy document. It is primarily accompanied by the Product Requirements Document (PRD). Sometimes, companies skip the MRD and PRD and go straight to listing out features, writing user stories, and prioritizing them. But done properly, the MRD and PRD can both provide guiding first principles that shape the product direction in an intelligent manner.
The MRD (or whatever you may call it) includes information for market and customer analysis, product requirements, and success metrics.
The primary audience for the MRD is the entire product/engineering and marketing organizations. But the MRD can also be used to guide other customer-facing roles, such as sales and customer success. At minimum, the information contained in the MRD makes generating common sales collateral (such as competitive battle cards and first meeting decks) much easier.
Customer analysis
We start by describing the background of the industry and market. From there, we dive into who the target customer is. And then we factor in the current solutions that solve the customer's problem, which represent our primary competitors.
- Product vision. What is the long-term goal of the product? What market segment does it aspire to fill? What does success look like? What makes the product unique?
- Market analysis. Describe the market segment in detail. How big is the market (the Total Addressable Market, or TAM)? Who are the key influencers in the market? Where do people go to get information about and within the market?
- Customer behavior map. Describe the various customer segments within the market. What are their motivations and characteristics? What are they missing and what do they need? How do they learn about new products? How much are they willing to pay? (see my posts on the Customer Behavior Map and Getting Great Customer Feedback)
- Competitive analysis. Who will you be competing with? Don't forget that for most developer products, the status quo (doing nothing different) is often the biggest competitor. Why do developers accept their current solution, even if it's inadequate?
- Keyword analysis. What do customers typically search for when they're looking for a solution in this space? One fun thing with developer-focused products is to account for error codes or error messages that would lead developers to search for solutions.
Product capabilities
Okay, so far you've described all the background information about the market and various types of customers within the market. Now we get to the fun stuff: how to solve their problems.
- Product requirements. What kind of products, features, or services will you need to build to activate each of the customers in your target market? For each listed product requirement, describe the customer archetype it most addresses. Describe how the product requirement should work in as much or as little detail as you'd like.
Fun fact: in a previous job as the Director of Product for Microsoft Visual Studio, I once created a 500-page slide deck that listed out each feature, mocked up the feature using PowerPoint animations, and described how customers would react to the feature in question.
Success metrics
Finally, we get to the analysis stage. What does success look like?
- Product metrics. What uptake do we expect to see in the product or feature? What kind of revenue do you expect to see?
- Growth metrics. Work backwards from product metrics into realistic assumptions for how many developers become aware of your product/feature, how many are willing to try it, and how many are willing to convert and begin paying for it.
- Pricing analysis. Combining the product and growth metrics will give you a start on pricing for the product. Pricing itself should account for not only what you need the price to be in order to meet your targets, but also what your target customer is willing to pay. See my (future) post on developer SaaS pricing for more information.