How to write a PRD (Product Requirements Document)

With the rise of Agile development practices, many argued that PRDs were a relic of the past and that people shouldn’t waste their time with them. In practice, however, I’ve seen clear benefits from well-written and maintained PRDs in every team I’ve worked with, all of which use Agile development to different extents. You may be wondering how to write a PRD; read on for some tips I’ve learned over the past five years.

What’s in a PRD?

At its most basic, a PRD includes:

1. Summary of the problem that a feature or product aims to solve
2. Users that would benefit from the solution and why it’s essential to focus on them.
3. A prioritized list of critical user journeys – things a user would be able to accomplish.
4. A functional feature description focusing on what a user would be able to accomplish with the solution – details around how can be deferred to the UX and eng design documents.

Other than those primary sections, PRDs often diverge significantly, and that’s OK. What matters is for the PRD to stick to its goal.

The goal of the PRD

A PRD is a tool to help the team achieve clarity. The process of writing, discussing, and iterating on the PRD is more important than the actual document produced in the end. As such, I want to focus on what a good process looks like when writing a PRD. These learnings are based on my experience and fine-tuned over time after learning from failed attempts at rushing through the process or not starting early enough.

How to write a PRD – the process

Write down the user problem & business prioritization rationale.

Open an empty document and write a summary of the problem to be solved. Focus on the user problem and why the business needs to prioritize.

• Share this with the team working on this initiative, if prioritized, and any decision-makers. At a minimum, I’d share with an Engineering Tech Lead, a UX designer, my manager, or some other business leader, and someone close to the user under consideration (a UX researcher, a customer success manager, a support team member, etc.)
• Ask for their feedback and use it to polish your justification for the initiative. You should get feedback before you start to propose solutions. Don’t waste anyone’s time on problems that are not worth solving.
• Your value-add as a Product Manager comes from bringing clarity to what is essential and why. Get crisp around who the user is and their needs. Write a set of user journeys, listing key things that a user would be able to accomplish once this initiative is complete and how it compares to the current experience.

Add details about the solution as it is defined.

I won’t dive into the design process here, but point out that you must revisit the user problem and goals of the initiative. As you and the rest of the team come up with a proposed solution, write in the PRD key details that helped inform the solution. This may include:

• Links to user research findings
• Discussions of various options evaluated, evaluation criteria, and resulting decision.
• Limitations uncovered during the design process, including technical limitations, UX considerations, resource, and budget constraints, timeline requirements, etc.
• Dependencies on other teams and relevant links to see their progress.

A brand new team member should be able to read through the PRD and understand the options considered, business context, decision-making criteria, constraints, and challenges faced.

Link to UX and engineering design documents.

The PRD helps force clarity around what to build and why. The UX and engineering design documents force the discussion of “how” to build it. At this stage, I link to those documents from the PRD and work with engineering and design teams to ensure that they have clear documents, thoroughly reviewed, about how a feature will be built. This time is to provide feedback on the options considered, and ensure they are in alignment with the priorities defined in the PRD. You should be a thought partner to them as they finalize the designs.

The PM needs to bring clarity to priorities. Feature bloat causes real delays in shipping value to users. By having a clear set of priorities in the PRD, a PM can help evaluate proposed designs and balance complexity with user value.

Update the PRD to call out feature scope decisions.

The PRD shouldn’t duplicate details evident in the UX and Engineering design documents. However, call out critical decisions and tradeoffs made during the solution design—technical considerations impacting feature scope, dependencies on other teams, user privacy or legal concerns, etc. Write them down. Also, write down if you decided to build a specific version of the feature to enable some vital future capabilities.

Share the PRD, and essential changes, often with others for input.

I like to identify perspectives that I will need, and find a counterpart that can chime in and answer my questions as we make progress. Sometimes that is a customer success manager for a critical account that is vocal about the feature (enterprise use case) or a UX researcher that is intimately familiar with this type of user. As we make updates to the feature scope, it helps to quickly mention them in a comment and ask for feedback on the tradeoffs made. If you’ve iterated on your document well enough, they can just read that section of the PRD with the decision made and rationale and quickly chime in, often helping you consider things you may otherwise have missed until it’s too late.

Continue to update the PRD during development.

During development, you will often need to make tradeoffs between feature scope and timeline. Usually, you’ll need to be reducing scope during the development cycle to keep making progress and launch to customers the critical parts of the feature. Keep updating your PRD and share critical updates to the timeline and scope with other teams. It’s never pleasant to communicate feature scope reductions or timeline delays. Still, the quicker you disseminate the knowledge, the more proactive teams can be at planning and addressing any downstream impact. It always helps if you include a clear rationale for the impact that anyone can read and understand.

Avoid overly bloated PRDs

A PRD is all about bringing clarity. Clear purpose. Clear value. Clear priorities. Clear scope. Clear decisions. Clear rationale.

To maximize clarity, follow good writing practices. Editing is as important as writing. Be clear, be concise, and cut out unnecessary words. Structure the document so that different readers can quickly skim it and zero in on what is of interest to them.

PRDs can be valuable tools.

You can achieve clarity and alignment within a team without a PRD. You can also write a PRD and not help bring any clarity to the team. But a PRD can be an invaluable tool to force a process that helps bring clarity to everyone.

Every team I’ve worked with has benefitted from having a clear, written description of initiatives in the form of a PRD. PRDs have helped us surface the right questions, force key discussions, bring clarity to those early, and disseminate the knowledge effectively and efficiently. It has helped streamline communications across teams, effectively involving and gathering their feedback before it is too late. The discussions that stem from a well-written PRD have helped build a better product and avoid many headaches during product launches.

A successful PRD is not one that you finished, no matter how beautifully written. A PRD’s success is measured by the number of decision points it surfaces, the discussions it fosters, and the proactive resolution of problems that surfaced earlier, which helps avoid headaches and negative surprises as you build and launch a product.

Update August 2020: I wrote an article for the Exponent Blog about this same topic, primarily influenced and informed by this one. Check it out.

Last Updated on February 5, 2023 by Omar Eduardo