đ Tips to Write a Product Requirements Document (PRD)
A step-by-step guide to communicating product requirements to your team
Hi there, Product People. Carlos here with another installation of All Things Product Management. Product Requirements Documents (PRDs) arenât exciting for most, but they provide the foundation of a great product. Communication is what makes the Product world go âround, after all!
With so many moving parts, they can be surprisingly complicated to create. This PRD guide PRD guide aims to take you from idea to action. Iâll tell you what a PRD should include, a step-by-step guide for writing your own, and provide you with a template to provide some structure.
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.
But what does it take to write the perfect PRD? Letâs jump right in.
Ready to get started now? Access a free PRD Template here!
What is a Product Requirements Document?Â
A Product Requirements Document (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, it's 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.
Main Takeaways
PRDs are living 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.
Here's a free PRD Template to get you started!
Check out some of the previous issues: