The usefulness of Product Requirements Document (PRD) is often debated. 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 it. In practice, however, I’ve seen clear benefits from well-written and maintained PRDs in every team I’ve worked, all of which practice Agile development to different extents.
What’s in a PRD?
At its most basic, a PRD summarizes the problem that a feature or product aims to solve, the user that would benefit, a prioritized list of user journeys, and feature descriptions with a focus on how the user would interface or experience the product. Other than that, PRDs often diverge heavily, and that’s OK. What matters is for the PRD to stick to its goal.
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. This is based on my experience and fine-tuned over time after learning from failed attempts at rushing through the process or not starting early enough.
The process of writing a PRD
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 it’s important to the business to prioritize.
- Share this with the team that would work on this initiative, if prioritized, and any decision-makers that would influence whether this is a priority. 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, support team member, etc.)
- Ask their feedback and use it to polish your justification for the initiative. This must happen before you start to propose solutions. Don’t waste anyone’s time on problems not worth solving.
- Your value add as a Product Manager comes from bringing clarity to what is important 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 existing 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, include 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 constrains, 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 is being built and why. The UX and engineering design documents force the discussion of “how” it will be built. 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 their 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.
It is particularly important for the PM 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 key decisions and tradeoffs made during the solution design. Technical considerations impacting feature scope, dependencies on other teams, user privacy or legal considerations, etc. Write them down. Also write down if you decided to build a specific version of the feature to enable some key future capabilities.
Share the PRD, and key 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 key 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 be able to easily 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. Often, you’ll need to be reducing scope during the development cycle in order to keep making progress and launch to customers the key parts of the feature. Keep updating your PRD and share key updates to timeline and scope with other teams. It’s never pleasant to communicate feature scope reductions or timeline delays, but 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, cut out unnecessary words. Structure the document so that different readers can easily skim it and zero in on what is of interest to them.
All this said, I think PRDs can be extremely valuable tools.
You can do 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.
In my experience, every team I’ve worked with has benefitted from having a clear, written description of initiatives in the form of a PRD. This has helped us surface the right questions, force key discussions, bring clarity to those early, and disseminate the knowledge in an effective and efficient manner. It has helped streamline communications across teams, effectively involving and gathering their feedback before it is too late. This has helped build a better produce 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 surfaced earlier, which helps avoid headaches and negative surprises as you build and launch a product.