Product requirements document template
A good PRD answers three questions before anyone writes code: what problem are we solving, how will we know it worked, and what exactly are we building. This template covers all three, plus the risks and decisions that usually get lost.
Updated
The short answer
A product requirements document (PRD) describes the problem, goals, users, requirements and success measures for a feature or product. Use this template to write one in under an hour: fill each section in order, keep requirements testable, and record every decision that changes scope.
Pastes with formatting into Google Docs, Word, Notion and Confluence.
[Feature name] PRD
Owner: [name] | Status: Draft | Last updated: [date]
1. Problem
What problem are we solving, for whom, and how do we know it's real? Link evidence.
2. Why now
What changed that makes this the right time?
3. Goals and success metrics
| Goal | Metric | Current | Target | By |
|---|
4. Non-goals
What we are deliberately not doing.
5. Users and scenarios
Who uses this and what are they trying to get done?
6. Requirements
| ID | Requirement | Priority (Must/Should/Could) | Acceptance criteria |
|---|
7. Design
Links to designs and prototypes.
8. Dependencies
Teams, systems or work this depends on, with owners and dates.
9. Risks
| Risk | Likelihood | Impact | Owner | Mitigation |
|---|
10. Decisions
| Date | Decision | Why | Decided by |
|---|
11. Milestones and release plan
12. Open questions
Example: fictional Meridian Labs data
Self-serve dashboards PRD
Owner: Avery Nolan | Status: In review | Last updated: 26 Sep 2026
1. Problem
Team leads across Meridian Labs wait on the data team for every new chart, so product questions go unanswered for days. Evidence: support tickets asking for new reports, and customer interviews.
2. Why now
The Live event pipeline is 70% done, so fresh data is finally available to dashboards. Customers keep asking to build their own reports.
3. Goals and success metrics
| Goal | Metric | Current | Target | By |
|---|---|---|---|---|
| Every team can answer their own product questions | Self-serve report adoption | Not measured yet | 40% | 17 Dec 2026 |
4. Non-goals
- Scheduled PDF exports (decided: ship templates before exports)
- Custom SQL editing
5. Users and scenarios
Team leads who check product usage every morning and want to build a view without asking the data team.
6. Requirements
| ID | Requirement | Priority (Must/Should/Could) | Acceptance criteria |
|---|---|---|---|
| R1 | Build a dashboard from templates | Must | A team lead can create a dashboard from a template without help from the data team |
| R2 | Save and share views | Should | A saved view opens with the same filters for a teammate |
7. Design
Dashboard builder designs by Kai Lindqvist (Figma link).
8. Dependencies
Dashboard builder -> Event schema contract (data platform team). Owner: Tom Reyes. Due 22 Sep, now 4 days overdue.
9. Risks
| Risk | Likelihood | Impact | Owner | Mitigation |
|---|---|---|---|---|
| Metric ownership unclear | High | High | Avery Nolan | Agree owners for the top 20 metrics in the Governed metric catalogue |
10. Decisions
| Date | Decision | Why | Decided by |
|---|---|---|---|
| 14 Sep 2026 | Ship templates before exports | Templates drive adoption; exports can follow | Avery Nolan |
11. Milestones and release plan
- Live event pipeline: 20 Sep (70%)
- Dashboard Sharing release: 25 Oct
- Self-serve dashboards: 15 Nov (At Risk)
- Governed metric catalogue: 20 Dec, shipped in the Q4 Platform Release (17 Dec)
12. Open questions
- Which 5 templates ship first?
New to PRDs? Start here
What it is
A product requirements document explains what you're building and why, before anyone builds it. It gets product, design and engineering agreeing on the problem, the goal and what "done" means.
Use it when
- A feature will take more than one sprint
- Several teams are involved
- Stakeholders need to agree on scope before work starts
Who writes it
The product manager, with input from engineering and design
Who reads it
Engineers, designers, QA and stakeholders
How to fill it in
Work through the sections in order.
- 1Problem: What problem, for whom, and the evidence it's real. Link data, research or support tickets.
- 2Why now: What changed that makes this the right time: a customer shift, a strategy change, a competitor move.
- 3Goals and success metrics: one to three metrics, each with a current value and a target. If you can't measure it, rewrite the goal.
- 4Non-goals: list what you're not doing. It prevents scope creep more than any other section.
- 5Users and scenarios: Name the specific users and the moments they'd use this. Two or three concrete scenarios beat a persona document.
- 6Requirements: make each one testable, with acceptance criteria an engineer and a tester would agree on.
- 7Design: Link designs and prototypes. If there are none yet, say when they'll be ready.
- 8Dependencies: Teams, systems or work you need, each with an owner and a date.
- 9Risks: What could stop this working or shipping, with likelihood, impact and an owner.
- 10Decisions: add a row every time scope changes, with the reason. Six months later, this is the most useful section.
- 11Milestones and release plan: The key dates and how it reaches users: beta, phased rollout or everyone at once.
- 12Open questions: What you don't know yet and who will answer it by when. Clear these before development starts.
Why PRDs go stale, and how to stop it
A PRD written in a wiki is accurate for about a week. Then the milestone moves and the doc doesn't. In Ondule, a PRD is a doc linked to its product, milestone and decisions, so their live status shows inside the doc as work moves.
Questions
- What should a PRD include?
- The problem, why now, goals and success metrics, non-goals, users, requirements with acceptance criteria, dependencies, risks, decisions and a release plan.
- How long should a PRD be?
- As short as it can be while still answering what, why and how you'll measure it. Two to four pages is typical for a feature.
- Who writes the PRD?
- Usually the product manager, with engineering and design contributing to requirements, dependencies and risks.