PRD template
The product requirements document says what the product must do, in requirements you can test. It's built from the approved brief, and the UX spec, architecture and stories all trace back to it.
Templates · PRD template
Template 2 of 10
- Signed off by:
- The product owner
- Comes after:
- Product brief
- Leads to:
- UX spec
prd.md
# PRD · <product or feature> ## Problem ## Users and their jobs ## Goals and success metrics Measurable: metric, baseline, target, by when. ## Scope ### In ### Out (and why) ## Functional requirements FR-1, FR-2… each testable, one behaviour per line. ## Non-functional requirements NFR-1… performance, security, privacy, accessibility, availability, with numbers. ## Assumptions ## Open questions Who should answer each. ## Release plan What ships when, if known.
When to write it
Once the brief is approved. The PRD turns "what and why" into requirements a designer, an architect and a tester can each work from without asking you what you meant.
How to fill it in
- Goals and success metrics. Each metric gets a baseline, a target and a date. Copy the outcomes from the brief and make them precise.
- Scope, Out (and why). Every exclusion gets a reason. "Not in v1: scheduled orders, because only 3 accounts asked" stops the same debate coming back.
- Functional requirements. One behaviour per line, each with a stable ID (FR-1, FR-2). Write what the product does, not how: "The cart accepts .xlsx and .csv files up to 5 MB", not "use a drag-and-drop component".
- Non-functional requirements. Numbers, always: "95% of 1,000-line files processed in under 10 seconds". "Fast" can't be tested.
- Open questions. Each one names who should answer it. An unanswered question is better than an invented requirement.
Keep IDs stable
Stories, test cases and the architecture all cite FR and NFR IDs. When you revise, add new requirements at the end and strike removed ones (~~FR-7~~ removed in v3: reason) rather than renumbering.
Every requirement traces back
Each requirement should come from the brief, a conversation, an interview or a ticket. If you can't say where one came from, it's an assumption: move it to Assumptions or Open questions.
Common mistakes
- Requirements that bundle three behaviours, so a story can only half-cover one.
- Design decisions disguised as requirements.
- Metrics without a baseline, so nobody can say whether it worked.
Example
PRD · Bulk orders
Goals and success metrics
| Metric | Baseline | Target | By |
|---|---|---|---|
| Orders over 50 lines placed by upload | 0% | 60% | June 30 |
| Time to place a 200-line order | 45 min | under 5 min | June 30 |
| Quantity corrections on uploaded orders | 12% | under 2% | June 30 |
Scope
In
Upload from the cart, SKU matching, a review step.
Out (and why)
Scheduled orders: 3 of 40 accounts asked. Email uploads: support can't verify the sender.
Functional requirements
- FR-1 The cart accepts .xlsx and .csv files up to 5 MB.
- FR-2 Each row is matched to a product by SKU; unmatched rows are listed with up to 3 suggestions.
- FR-3 The buyer can fix, replace or drop any row before adding the order to the cart.
- FR-4 Rows with a quantity above the product's order limit are flagged, not rejected.
Non-functional requirements
- NFR-1 95% of 1,000-row files are matched in under 10 seconds.
- NFR-2 Uploaded files are deleted 24 hours after the order is placed.
Open questions
- Do any accounts send their own SKUs? (Dana, sales)
Have Releavo write the prd
In Releavo this lives at docs/prd.md. Releavo drafts it from the docs before it and your team's conversations; every edit is a draft until the product owner approves it, and approved versions are never overwritten.