Editor’s Note: the following content has been validated by the Head of Product at YouTube.
If you are a Product Manager or aspiring to be one, chances are that you have come across or you’re currently writing your Product Requirement Documents (PRDs). Or perhaps you’ve already written dozens of PRDs and you’re just looking to fine-tune your skills.
Our PRD guide aims to take you from idea to action. We’ll tell you what a PRD should include, a step-by-step guide for writing your own, and provide you with a template to get you started.
So what does it take to write the perfect PRD? Let’s jump right in.
What is a Product Requirements Document?
A PRD is a guide that defines a particular product’s requirements, including its purpose, features, functionality, and behavior.
This document is generally written by the Product Manager to communicate what they are building, who it is for, and how it benefits the end-user. It also serves as a guide for business and technical teams to help develop, launch, and market the product.
According to Minal Mehta, Head of Product at YouTube, a PRD is a living document that should be continuously updated according to the product’s lifecycle.
Now that you know what a Product Requirements Document is, its time to understand what exactly goes in it.
The Contents of a PRD
Title: Give this project a distinct name.
Change History: Describe each important change to the PRD, including who changed it, when they changed it, and what they changed.
Overview: Briefly, what is this project about? Why are you doing it?
Success Metrics: What are the success metrics that indicate you’re achieving your internal goals for the project?
Messaging: What’s the product messaging marketing will use to describe this product to customers, both new and existing?
Timeline/Release Planning: What’s the overall schedule you’re working towards?
Personas: Who are the target personas for this product, and which is the key persona?
User Scenarios: These are full stories about how various personas will use the product in context.
User Stories/Features/Requirements: These are the distinct, prioritized features along with a short explanation as to why this feature is important.
Features Out: What have you explicitly decided not to do and why
Designs: Include any needed early sketches, and throughout the project, link to the actual designs once they’re available.
Open Issues: What factors do you still need to figure out?
Q&A: What are common questions about the product along with the answers you’ve decided? This is a good place to note key decisions.
Other Considerations: This is a catch-all for anything else, such as if you make a key decision to remove or add to the project’s scope.
As you write your first drafts, it’s ok to leave TBD and placeholder comments for unknowns. For example, you might not initially know how you want to message the product.
Building a PRD: Step-by-Step
Now, its time to show you how its done.
Step 1- First Draft
To start, write the first version of the PRD in your collaborative platform of choice.
It’s a good idea to start your PRD draft somewhere private.
People talk and sometimes get the wrong ideas, and you don’t want them to find a draft with language/features you realized were wrong.
It’s fine to put TBD in spots (maybe success metrics).
In general, you want the background, objectives, maybe metrics, and maybe key user scenarios/epics focused on the high-level features.
Step 2 – Get Approval
Get any needed approvals from your boss with the first version. Your teammates and your boss are an asset, and use them as such.
Get their thoughts/feedback.
People who have been there longer might have insights you don’t know about or can suggest ways to approach potential sticky points.
Plus you don’t want to blind-side your manager!
Step 3- Share with Design
Share the PRD with the design project leader and incorporate feedback.
Design is close to the user too, therefore it would be smart to engage them before approaching engineering, because their feedback might affect the project’s technical scope.
Discuss the spec with them and incorporate their ideas/feedback. You’re not telling them what to do.
Step 4-Share with Engineering
Share the PRD with the engineering project leader (don’t forget the design lead!) and incorporate feedback.
With the design lead (ideally), engage the engineering lead and get feedback.
This will help you figure out what’s technically feasible, get some very rough time/difficulty estimates, and they might know something about the tech part of the system that enables a new solution.
Step 5- Share with Project Team
Share with the project team!
Move the PRD to a wiki, or someplace more public so that others can see what you’re thinking in one place.
Make sure to get your team’s questions, input, etc. and document it on the PRD
At this point, note any good ideas, and if they’re not right for this initial version, still record them in the icebox
Step 6-Share with Company
Possibly share it with the company.
You’ll likely be presenting rather than sharing the PRD.
This doesn’t necessarily mean read your PRD on a podium but instead, assemble a well-structured presentation and share it with your stakeholders.
What are you waiting for? We’ve laid it all out in three different platforms: Google Sheets, Coda, and Mural –all validated by our instructors at Product School.
We’ve also created a sample PRD of a project-level PRD for V2 of a mobile app at a camera company. This sample is an iterative PRD, so it doesn’t list the app’s basic features under the Features In/Out section, therefore we suggest some features have their own PRDs to be implemented. View the sample here.
Collaborative online whiteboard products have been taking the tech world by storm! Level up on your PRD by checking out how our partner from MURAL does it on their PRD template.
Coda is a cloud-based document editor like no other that will help teams organize, delegate, measure, and document everything in one place.
With this template, you’ll be able to get your entire team on the same page and scale up your product.
Shoutout to our Product School instructors from Amazon, Facebook, Google, and Slack who helped develop and validate these templates.
PRDs are live Documents: As you build the product, you need to constantly update the PRD.
They must be flexible: As you write your first drafts, it’s ok to leave TBD and placeholder comments for unknowns.
A good PRD is concise: Note key decisions, add relevant links, and don’t leave anything up for interpretation.
PRDs are a product of teamwork: Even though the PM is ultimately responsible for owning the product/defining what to do. It’s much better to have a collaboration/soft power approach when it comes to creating the PRD.
They are excellent communication tools: Use the PRD to communicate what you’re building and why.
Check out our other templates:
Still, looking for some great templates? Check out our collection: