The How-tos of PRDs

What are PRDs?

The Product Requirements Document (PRD) is essential for any Product Organization. PRDs enable Product Managers to document the problem, requirements, and use cases associated with the question “Why should I build this product or feature?” This document ends up being the source of truth for a specific feature or product and enables engineers, marketing, customer success, and security to all have the same understanding.

These PRDs can become long, and I’ve seen them become 15-20 pages! It’s great to capture everything around the feature, however, “Will people read all of it?”. Most likely, no, and for an engineer, definitely not. Based on my experience, I have seen Product teams gravitate towards a PRD Template approach. The template approach keeps the PRD short and concise. It forces the Product Manager to gather the necessary pieces of information they need to convey the problem and enable their engineering leads to design the technical solution. The other benefit of a PRD template is that it allows for uniformity in presentation, meaning that all problems faced by PM teams get conveyed in the same and structured format.

This blog post will share everything you need to know about creating and working with Product Requirements Documents!

A Product Requirement Documents Template 

The structure of PRDs differ depending on the industry, and what specific pieces of information you wish to convey to the team. Below is a structured template of a PRD.

Title: PRD: [What are we calling this Feature?]
Heading - Problem Overview
     Subheading - Problem & Use Cases
     Subheading - Objectives & Success Metrics
         Table - Metrics | Value
Heading - Solution Overview
    Subheading - Features In & Features Out
    Subheading - User Scenarios & Stories
    Subheading - Mocks
     Subheading - Q&A
         Table - Questions | Answers | Owners
Heading - Launch Overview
    Subheading - Release Plan
    Subheading - Marketing Plan
    Subheading - Upgrade Plan
     Subheading - Risk
Heading - Future Considerations

This is a standard template I use in my current role. Your organization's PRD template may differ.

How to complete a PRD Template

There are many Product Requirement Document templates out there to leverage as a starting point! Let’s discuss how to use the template structure just shared.

As you receive feedback from your fellow Product Managers, Engineering Leads, Designers, and Marketing leads, this PRD will become more refined and tailored to your business needs.

Problem Overview

The Problem overview section details the specific problem you are trying to solve with the proposed product or feature. You present the use cases, the business objectives, and success metrics associated with the problem. ‍

Problem & Use Cases:‍

Consider the following prompts:

- Identify the problem
- Document customer pains
- How would a customer use this product or feature?
- Why do they need this product or feature? ‍‍

‍Objectives & Success Metrics‍

Consider the following prompts:

- What is the Business Criteria around this problem? 
- Why do we need to do this? 
- Why does the problem matter to the business?
- What objective does it tie to? 
- How do we measure the success of this product or feature? 
- What does success look like?

Solution Overview

The Solution Overview section looks at what the proposed solution might be. This proposal may not be the implementation solution, and that’s okay. The idea is to provide a solution to the problem. Your engineering lead and design lead focus on how the solution should be implemented. The Product Manager articulates the business problem and provides a solution to the business problem. 

In this section, you will define the features that make up the solution and tackle the main problem. These features address the first iteration of this product. What is the minimum number of features to make this a viable product for the market? Features out are nice to have, and should only be revisited second to the necessary features. The User Stories and Scenarios are what a user would go through to solve their problem. What are the situations where they would face the problem with your product? What do they need to do in your product to solve the problem? 

Features In & Features Out‍

Consider the following prompts:

- What are the features required for MVP 1? (Tie these features to the objective)
- Why are these features required? (What use cases are you trying to solve?)
- What features are nice to have? Why are they nice to have?

User Scenarios & Stories‍‍

Consider the following prompts:

- How would the users use the product or feature?
- What would the flow look like?
- What are the steps to accomplish the objective? 
- What criteria need to be met to consider the user story completed? 
A Sample User Story Flow that I use, references Atlassian’s Agile Coach Tool: “As a [persona], I [want to], [so that].”

Mocks‍

Sometimes it's easier to show and illustrate the feature or the idea. These mocks need to focus on the functionality of the feature or the product. Don’t worry about the UX, that’s why you have a design team! ‍

Q&A‍

Consider the following prompts:

- Are there any unanswered questions that need to be addressed?
- Are there questions that came up during the PRD presentation that need to be answered? 
- Any technical questions that you want to ask the engineering lead?
- Any design/experience related questions you need to ask your designer? 
- Any customer concerns or questions that you as the PM need help answering? 

Launch Overview

The Launch section addresses how the product requirement solution gets delivered to users. How are we going to Launch the product? Do you plan on testing the feature internally and then release it externally? 

As a Product Manager, we need to specify how we are going to release the product and market the product. If your organization doesn’t have a Product Marketing Manager, the ownership falls on the Product Manager as well.

If we need to upgrade our users, how are we going to upgrade them? The release plan should also capture how to migrate and upgrade the existing customer base if the feature isn’t backward compatible or will make a significant change to the current experience. ‍

Release Plan

- Are we A/B Testing? When & Who will be involved?
- When do we release it to production? 
- What percent of users will experience the feature first? 
- When do we roll the feature out to everyone? 

Upgrade Plan

- How do we migrate existing users over to the new version?
- Will we need to engage our Customer Success team? Is it a manual process?
- How much documentation will need to be provided to the user for the upgrade?
- Will there be documentation for self service migration?
- Are we planning on notifying our users beforehand?

Marketing Plan

- How do we plan on notifying our customers and market about the new feature or product?
- Do we have a flushed out Go To Market Plan?
- Have we reviewed it with the Marketing Team? Has it been approved?
- What channels are we going to leverage to market the product?
- Are we going to educate our partners? 

Risk

We also document the risks associated with the feature, such as exposing specific pieces of data, using user data, any security vulnerabilities, legal reproductions, etc. It’s important to capture risks so the Legal and Security can mitigate or remediate them post-launch. 

- What are the security concerns involved with this product?
- What are the data concerns associated with this feature? 
- Does the new feature pose a risk to the business later on (legally)

Future Considerations

The Future Considerations section is to address unknowns and the question, "what are we leaving out in this product or feature?" To do this, capture the features out and elaborate on why you may want to iterate upon this feature in the future. This is especially useful when designing software products or features. It's a great way to scope the initial requirements and address the core problem. Remember, these features are nice to have and can backlog work in any second phase of work surrounding a specific feature or product. 

Next Steps

Once the initial PRD is written, it is always good to get it reviewed by a fellow Product Manager to make sure they can understand what you wrote. This ensures quality and enables learning amongst the Product Team. Since this is a sample template, overtime, it will evolve and match your organization's needs. 

The PRD captures the problems and the use cases that validate the need for the product or feature. It will also serve as the launchpad for a solution and an implementation for the product. It will tie in other parts of the organization like Marketing, Security, and Legal to make sure that there is alignment between the orgs! 

The PRD allows for many organizations to be engaged, but remember, you as the Product Manager are responsible for composing it, and own it end to end! You are the subject matter expert in the business or product problem. The PRD is the tool to frame it and enable the organization to tackle it head-on.

Conclusion

The Product Requirement Document is a crucial document used to deliver better software. It allows the team to focus on addressing problems and market needs in a scoped and organized fashion. It enables organizations to focus on building what is necessary for Minimal Viable Product (MVP) while interacting quickly through the development process. Use PRDs to build better software today. Thanks for reading, and please check out more content on deliver-better.com!