How to Write a Product Requirements Document (PRD)

Want to know what a PRD is? Or how to write one? As Product Managers, we write a product requirements document (PRD) to answer a few key questions:

1. Why are we working on an initiative?
2. How are we approaching the problem?
3. What is the right solution?

We write a PRD not only to answer these questions but also to align our team to build the right product and successfully bring it to users. Used properly, it is an excellent product development tool, regardless of what development process you follow. If you’re new to writing PRDs, here are some tips to help you make the most out of the process.

What's in a PRD?

At its most basic, a PRD is a simple written document that includes the following sections:

1. Summary and Background: what is the problem and why does it matter? Can include business metrics information, past user research, or any other insights to highlight the importance of the initiative.
2. Target Users: who would be using or benefitting from the solution? Why are those users important and their pain points important to prioritize?
3. Critical User Journeys (CUJs): what can a user accomplish once you've solved the problem? Focus on the user needs, not on a specific solution.
4. Functional requirements: a description of the solution proposed to address the problem. As a PM, it is important to detail out the functional requirements, but avoid dictating specific solutions.
5. Supporting documents: you'll work with your design and engineering counterparts to define the interaction design and technical implementation of the solution. Keep the functional requirements in the PRD, but add a link to UX and engineering design documents for additional details.
6. Go-to-market: considerations around how the feature will be launched to users and expectations around marketing, sales, customer support, and other user-facing functions.

While those are the foundational sections of a PRD, you may write about many other considerations, including the length of your product's life cycle. In prior teams I've worked with, PRD templates have included sections to outline user permissions considerations, performance requirements, data import or export considerations, success metrics, cross-platform compatibility, new accessibility considerations, and much more. Start with the basic sections above and as you work with your team add new sections as needed to address important questions that surface.

Tips to make progress when writing a PRD

Get team feedback early

Often PMs spend too much time on the PRD before they share it for feedback. Instead, identify from the beginning one user experience (UX) and one engineering counterpart that will be actively involved in reviewing and providing feedback on the PRD. Write the first draft of the PRD outlining your answers to the three main questions above (the why, how, and what of this initiative) and share it with them.

Your first job as a PM is to articulate for your teammates why an initiative matters and what problems need to be prioritized, but the solution to the problem should be defined in collaboration with your engineering and UX counterparts. By getting early and frequent feedback from them you’ll be able to focus your time effectively.

A good rule of thumb to follow is if you've drafted the first three sections of the basic PRD discussed before (summary and background, target users, CUJs) you should get feedback before proceeding to section four (functional requirements). Trying to define functional requirements, which describe a specific solution, before aligning on the problem, users and CUJs can lead you and the team to waste significant time.

Make your PRD interesting, structured and easy to digest

A good PRD is one that properly conveys important information to your coworkers without requiring a lot of unnecessary effort on their end. For this, you need to edit your PRD, keeping in mind a few points.

1. Focus on problem points: eliminate any irrelevant or useless details from your PRD, including anything obvious, and focus on the problem areas. A key reason to get team feedback early (prior tip) is to identify where the conflict areas may be. Focus your time on digging into these conflicts and helping your team align on a path forward. If you are asked to write things down just for documentation purposes, or to CYA, but they strike you as irrelevant or obvious details, consider putting these in an appendix.
2. Structure your PRD so it is easy to scan: think about what your various coworkers will be interested in, and structure your PRD so that they can easily find it. Use headings and subheadings smartly so that key discussion points are easy to parse out. That way your coworkers from multiple teams can quickly focus on what matters to them and provide you with their insights.
3. Consider using wireframes, diagrams, and tables: Too many paragraphs and bullet points can make the brain go dormant. If you’re comparing options, describing a before and after change, outlining a data flow, or discussing timeline considerations, you may find it helpful for everyone to use a table, chart, or mock-up. It will take more work for you to put these together, but the clarity it can bring will pay dividends. It will help more of your colleagues to digest the information from the PRD, rather than glazing over the information leading to repetitive questions down the line.

Guide the discussion

If your PRD is focusing on interesting points, addressing conflict areas, and discussing important solutions it will spark conversation. Your readers should be encouraged to leave feedback and comments. It is then your job to be thoughtful in reviewing the feedback and reacting appropriately.

1. Acknowledge and respond to comments: if you agree with the comment, let the reader know! If you disagree, provide more context or ask clarifying questions to see if there’s something you may be missing or forgetting. This process is what will help you identify critical issues, surface disagreements, and improve the odds of the initiative succeeding.
2. Keep your ego in check: after working on an initiative for a while, it sucks when someone else helicopters into the PRD and just leaves a critical, rude, or ignorant comment. It happens. Rather than responding while your emotions are high, take a breather, distract your mind, and consider the feedback when you’ve cooled down. You’ll often find something useful in the comment once you objectively consider it. Respond then.
3. Shift important and complex disagreements to meetings: if there’s major misalignment or disagreement of how the initiative should proceed, schedule a meeting to discuss the issues. Keep it focused by having clear disagreement topics to discuss and inviting only the people who are essential to the discussion.
4. Know when and how to close the discussion: once you’re set on a direction, and all key players are on board, you must minimize distractions and scope/feature changes. It is important to make it clear in the PRD that a solution has been agreed to. I like to add to the top of the document “Status: Final” to signal I’m no longer actively seeking feedback. For all open comments or new suggestions, respond letting the person know that the feedback was considered, why it was or wasn’t incorporated, and resolve the comment. Do this thoughtfully, being kind but clear, to avoid confusion.

Keep iterating and learning!

I've written dozens of PRDs over the past six years and each time has been slightly different based on the initiative and the specific team members involved. This is evident when looking at the final result, no two PRDs look the same. However, getting to the final state follows a similar process of writing up a draft, incorporating lots of feedback from teammates, collaborating on final solutions with design and engineering counterparts, solving thorny issues in meetings, and ultimately finalizing the PRD. This finalized PRD not only reflects the final solution implemented but more interestingly it also reflects the journey the team went through to align on a solution.

Each journey is unique and reflecting on how you got to the end, with all its ups and downs, will be your best asset in learning and improving the next time around.