Product Requirements Document (PRD)
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. PRDs take you from idea to action.
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.
- Serve as a guide for business and technical teams to help develop, launch, and market the product.
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.