As a Product Manager, you’re going to get very familiar with writing MRD and PRD very quickly. New to the idea? We’re going to break down the basics of the market requirements document and product requirements document in this post. To master PRD and MRDs, you’ll need to know what they are, what their purpose is, how they differ, and key factors to consider when writing them. Ready? Let’s dive in.
PRD and MRD: What Is an MRD?
A marketing requirements document (MRD) is a document that encapsulates details about your proposed product or service from a business perspective. It is helpful to collaborate deeply with your marketing/research department if you have those resources available. If you are working at a startup, congratulations, you are probably going to have to do most of this yourself, but don’t worry, we have some insight that will make this process painless and steer you in the right direction.
Writing this document correctly should provide a thorough understanding of “why” we should build a product as opposed to the traditional product requirements document which primarily defines “what” it is that we are building. There can be some overlap between the two versions and depending on the organization, the development team, and the development methodology, the form and level of detail included in these documents can vary greatly.
How to write an MRD
To answer why we should build something, we need to understand what the market looks like for such a product. Usually, this starts with some kind of thesis and the more evidence you gather, the greater the support (or ambiguity) for your initial position. Does the world need another app to download and install across all their devices? Probably not, unless it solves a real problem, consumers will use it frequently, and your company can extract a price that people are willing to pay and that provides a profit for your organization. Getting these answers right will make or break your product before you write a single line of code.
- To begin, think about your target market and look at it from as many perspectives as possible.
- What industry or segment does your product serve?
- How big is the market? Is this a $50M market or a $1B market?
- What are the segments of the market that are underserved by current solutions?
- What pain points continue to exist even with current solutions and how does your product uniquely (and profitably) solve those problems?
- Who are your competitors and how will your product offer something better, faster, cheaper, than the choices that consumers already have?
If you begin to answer these questions, you will quickly realize what types of pressures your team or company will face in getting this product launched into the marketplace and how to position your solution within the sea of possible answers available to consumers.
MRD Best Practices
As you go about answering these questions, it is important that you are not blinded by signals that run contrary to your existing thesis. You should support every answer you create with as much evidence as you can obtain by primary and secondary research, surveys, industry analysis, and whatever else you can find to either support or refute your original position. If you feel confident that the market needs another solution, that there is room for your solution to capture a piece of the money being spent, and that you can build a product that will be profitable — at a level that is meaningful to your company, you are should be more confident when you design your product and which features to prioritize that will add the most value for your potential customers.
Even if your organization does not demand that you complete this work, it is a good practice to engage deeply in this process. Nothing is worse than spending precious time and resources on a product that doesn’t perform as expected. Spending time on a thoughtful and well-researched MRD is a great way to make sure what you build will have the greatest impact in the market and for your company.
PRD and MRD: How to progress to a PRD
Okay, now that we have an idea of why you should build something, it’s time to focus on what we should build. This is where the product requirement document (PRD) comes into play. These documents should build off each other. If you are satisfied with the MRD, your first pass at a PRD will be guided by research and less prone to errors of untested assumptions.
There are no shortages of ideas on features that your product should contain, but rarely do you have enough time or resources to satisfy all of the requests. Additionally, your product is very unlikely to solve all problems for all people. It is generally a good idea to focus on the features that will provide the greatest value for your identified segment.
How to Write a PRD
If you have never written a PRD before, there are many templates that you can use and an almost infinite number of opinions on what to include in the document. Modern agile teams eschew lengthy documents so in my experience, it is crucial to be concise and focus on the aspects that are crucial to the success of your product in the marketplace. Some of the PRD examples you can find will go into details that might not be as relevant to your team or product so don’t be afraid to modify your outline to match your audience and the communication style of your product team.
Some key aspects of your product to include are the following:
- What are the key objectives of your product or service and how will you measure success?
- What components of your product are necessary to deliver the value you are contemplating?
- What is the flow of your product, how does a user walk through the setup and successful execution of your application and which features are required to accomplish the mission?
- Are there any crucial details about each component or feature that are unclear or ambiguous? Provide as much detail as necessary, without being overly prescriptive about “how” to solve the problem.
- Invariably, you will have to make some adjustments and not all of your features will launch at the same time. Prioritize those features that are vital to the first release of your product and list out the features that you will build later.
- No product is ever released as initially specified. You should fight for those aspects that your research has shown to be critical and as many nice-to-have features as possible.
PRD: What To Keep in Mind
No matter how well you write this document, it is of no value if you do not communicate it properly. The PRD is a good artifact to produce for future reference, but a really great document is one that summarizes easily for different audiences. If it takes you multiple paragraphs or pages to explain your feature, you may need to rethink or refactor certain aspects to make them easier to understand for multiple audiences.
Also realize, not everyone will read these documents. Don’t assume that just because you took the time to create it, that the team will spend as much time reading it thoroughly or in its entirety. You shouldn’t take it personally if you have to repeat aspects of your product your MRD or PRD outlined. The more you summarize and communicate the components of your product, the more clear you become about what the project needs to include and why. This is a healthy level of tension that usually leads to better outcomes.
How to Master MRD vs PRD
Hopefully, you are now ready to create and progress through this process of discovering what the market needs, what they will pay for, who will benefit your product, and what it absolutely must include in order for your customers to adopt it.
This process may seem pedantic by modern agile standards, but this level of analysis and documentation is crucial to refining your ideas and matching your vision with what consumers want. Start with your MRD and progress your ideas into your PRD. You need both MRD and PRD, and if you create successful documents, they will guide the difficult trade-offs that must be made by you and your team throughout the product life-cycle.
Need more insider knowledge on product management skills and how to master on-the-job requirements? Join our product management community group to chat with like-minded professionals and job hunters, and get the support you need to thrive. Or, if you’re looking to break into product management, why not connect with us directly? We’re offering free, 20-minute career coaching sessions with our in-house team of PM Recruiter experts: we’d love to hear from you.