How to Write a Product Requirements Document? The Best PRD Template.
Hey, Paweł here. Welcome to a subscriber-only edition of The Product Compass.
Every week, I share actionable tips and advice for PMs.
Here are some posts you might have missed:
Subscribe now, if you haven’t already, for the full experience:
How to Write a Product Requirements Document? The Best PRD Template.
Product Managers often ask me about a Product Requirements Document (PRD) template.
It might be helpful if used correctly. And questions about it are common during PM interviews.
But what’s driving me crazy is that the most popular websites and videos advise a heavy, waterfall approach. They suggest documenting everything: “requirements,” user stories, acceptance criteria, a detailed roadmap, and even data flows, and argue the document is created solely by the product manager.
Enough is enough.
So, in today’s issue:
Why do we need a PRD?
What’s inside a PRD?
🔒 When to write a PRD? A PRD lifecycle.
🔒 PRD templates: Notion, Google Docs
🔒 Common mistakes
1. Why do we need a PRD?
1.1 It’s not about the requirements
First, the name ”Product Requirements Document” might be misleading. Because it’s not about documenting the “requirements.”
We must remember that empowered teams are led with the strategic context, given problems to solve, and are held accountable for the outcomes, not the output (features).
They start with a generic problem, perform product discovery together, explore the problem and solution space, and run experiments to validate their assumptions before the implementation. Continuously.
The idea of waterfalling requirements from stakeholders to the product team or from Product Managers to other team members by writing detailed specifications should sound absurd to product people.
1.2 Documenting your product discovery
So, why might you need documentation?
Not all problems you solve as a product team are equal. Sometimes, it's not just about incrementally improving your product but about realizing a larger initiative that might span over a few weeks.
An example might be the leaderboards feature that Substack released a few months ago:
Let's paint a hypothetical scenario.
Imagine that Substack was struggling to boost word-of-mouth recommendations.
After interviewing customers, performing market research, ideating, and testing their assumptions, a product team decided to document their product discovery. They shared the results with stakeholders in the form of a PRD.
They explained the goal of the initiative and how it aligns with the product strategy, presented success criteria, customer jobs, and estimated effort, and provided high-level assumptions, such as clickable prototypes, and user flows.
Their PRD served as an evolving workspace aggregating key information. It supported internal communication, facilitated getting stakeholder buy-in, and fostered alignment within the organization.
Eventually, having gained sufficient confidence, the product team, working with product leaders, decided to implement a basic version. They continued refining details during implementation. Additionally, they incorporated feedback from writers while gradually launching the recommendations.
1.3 Using a PRD for existing products
The hypothetical scenario I presented refers to an existing product. But isn’t the PRD thought to be primarily for new products?
Not really.
Despite what many sources claim, using a PRD format is more common for existing products. Let’s look at a survey I performed on X (Twitter):
I'm skeptical that PRDs are as commonly used in startups or internal startups as the results above suggest. Some respondents might work in a project, not a product environment, e.g., creating “dedicated products” ordered by individual customers.
In any case, other formats, like Lean Canvas or Business Model Canvas, might be more appropriate for the initial product discovery. At least consider incorporating their elements in your PRD. For more information, see How to Achieve Product-Market Fit.
2. What’s inside a PRD?
Everything in this section is a recommendation. Adjust the scope to your specific situation. Keep your PRD concise to not overload others with information.
If you are a product leader, please do not make it a requirement or, even worse, part of the process. As Reed Hastings wrote in his book No Rules Rules:
“If you give employees more freedom instead of developing processes to prevent them from exercising their own judgment, they will make better decisions and it’s easier to hold them accountable.”
That said, here are the key areas to consider:
2.1 Summary
What is this document about? Write 2-3 sentences for those who might not have time to read the entire content.
2.2 Contacts
List the key stakeholders, Product Manager, Design Lead, and Lead Engineer.
List any dedicated Slack/Teams channels for interested parties to join.
2.3 Background
In a few sentences, explain the context:
What is this initiative about?
Why are you building it now? Has something changed?
Is it something that just recently became possible (e.g., AI)?
2.4 Objective
Briefly explain:
What’s the objective?
Why does it matter?
How will it benefit the company and the customers?
How does it align with your vision and strategy?
How will you measure the success (key results)?
💡 Keep your objective SMART (specific, measurable, achievable, relevant, and time-bound) and inspiring. My favorite format is using OKRs (Objectives and Key Results).
2.5 Market segment(s)
Briefly explain for whom you are building it, such as “Substack writers who struggle with acquisition.”
Are there any constraints (e.g., geographic, language, regulatory)?
💡 Remember that markets are defined by people's problems/jobs, not their characteristics. You can learn more about outcome-based segmentation from Jobs-to-be-Done Masterclass Tony Ulwick and How to Achieve Product-Market Fit.
2.6 Value proposition(s)
What customer jobs/needs do you want to focus on? What will they gain, and which pains will they avoid by using your solution?
💡 Consider linking research results. These might include, among other things, the Opportunity Solution Tree, Jobs to be Done, interviews, surveys (e.g., Opportunity Score), or data insights.
Which of those problems will you solve way better than the competitors?
💡 Consider including a Value Curve and market research insights.
2.7 Solution
UX / Prototypes
Provide an overview of the user experience, including user flow diagrams (key screenshots) and links to prototypes (e.g., Figma).
💡 A picture is worth thousands of words.
Key features
List the key features, providing a brief description of each.
💡 Make sure it’s clear how those features contribute to the overall objective and the key results.
(Optional) Technology
A high-level overview of the technology used, only if non-standard and relevant. Avoid detailed technical specifications.
Assumptions
What are the value, usability, viability, and feasibility assumptions? Did you validate your business model, too, if applicable?
Which risks do you accept? How can you mitigate the others?
💡 You might link your hypotheses, experiments, and learnings library and just briefly summarize them here. Do not overload this document.
2.8 Release
How long could it take? What might be included in the first version, and what might be left for the future?
💡 Avoid exact, absolute dates. This is an estimate, not a contract. Focus on outcomes, objectives, and when they might be achieved, not on the details.
3. When to write a PRD? A PRD lifecycle.
As mentioned earlier in the hypothetical scenario, the PRD might be used to document your product discovery. It is an evolving workspace that aggregates key information and supports internal communication.
Keep reading with a 7-day free trial
Subscribe to The Product Compass to keep reading this post and get 7 days of free access to the full post archives.