A PRD (product requirements document) explains what will be built, for whom and why. It brings together context, the problem with its evidence, goals with success metrics, the audience, prioritised requirements, what is out of scope, risks and open questions. It aligns product, engineering, design and business before delivery and records the decisions made along the way.
How to use
- Give the initiative a title and describe the context and the problem, with the evidence you have.
- Write the goals with the metric and target for each one, and say who the audience is.
- List the requirements with must, should or could priority, and declare what is out of scope.
- Record risks, dependencies and open questions, and read the warnings on the document.
- Export as Markdown to paste into Notion or Confluence, or as PDF and DOCX, and turn the requirements into user stories.
What each field asks for
| Field | What to enter |
|---|---|
| Initiative title | A short name for what will be built. |
| Context | Why this matters now and how it links to the strategy. |
| Problem | The customer problem, without describing the solution yet. |
| Evidence | Data, interviews or tickets that show the problem. |
| Goal | E.g. reduce overdue invoices |
| Metric | How you will know the goal was reached. |
| Target | E.g. from 62% to 75% this quarter |
| Personas or audiences | Who uses it and who is affected. One per line. |
| Context of use | Where, when and how people use the solution. |
| Requirement | E.g. send a reminder 3 days before the due date |
| Priority | Must is essential to launch; could can wait. |
| Detail | Rule, limit or note (optional). |
| Out of scope | What this delivery deliberately does not do. |
| Risks | What could go wrong or block the outcome. |
| Dependencies | Teams, services or approvals the delivery needs. |
| Open questions | Decisions still to be made. |
Example
The team behind a fictional money app for freelancers writes the PRD for an automatic payment reminder. The problem: freelancers forget to chase late clients, and 38% of invoices fall due unpaid. The main goal is to raise invoices paid within 7 days of the due date from 62% to 75% this quarter. There are 5 requirements: 2 must (send the reminder and pause it per client), 2 should and 1 could. Late fees and in-app payment are out of scope, and two questions remain open.
When to use
- Before starting a feature that involves more than one team or more than one iteration.
- When the debate about what goes into the delivery keeps going in circles and there is no reference text.
- To take a proposal to review with engineering, design and leadership, with explicit goals and scope.
- To record what was decided and why, so you can pick the topic up again months later.
Frequently asked questions
What is a PRD?
It is the product requirements document: it describes the problem, the goal, the audience and what the solution must do. It is not a technical specification; the "how" stays with the team that builds it.
What is the difference between a PRD and an epic?
An epic is a large backlog item, usually split into user stories. The PRD is the document that explains why that epic exists, how to measure success and what is left out. One PRD can lead to one or several epics.
How long should a PRD be?
Long enough for an outsider to understand the problem and the decision without a meeting. For one feature, one to three pages is usually enough. If it runs longer, the initiative may need splitting.
Who writes the PRD?
Usually the product manager, together with engineering and design. A good PRD is reviewed by the people who will build it before delivery starts.
Does a PRD make sense in agile teams?
Yes, if it is short and kept alive. It does not replace conversation or backlog refinement; it gives the context and limits so that user stories are written and prioritised with the same goal in mind.
How do I keep a PRD up to date?
Treat the open questions as a to-do list and record each decision when it happens. Review the document whenever the scope changes and show the status and the date of the last review at the top.