In short
A useful PRD explains the problem and evidence, target users, desired outcome, scope and non-objectives, workflows, business rules, data, permissions, states, dependencies, analytics, risks, and testable acceptance criteria. It should make consequential decisions visible while leaving implementation choices to the people responsible for engineering them.
The PRD is a decision record
Its job is to align product behaviour and expose missing decisions. It should evolve with evidence while preserving why scope and rules changed.
Recommended structure
1. Summary
One paragraph: audience, problem, intervention, intended outcome, and why now.
2. Evidence
Link research, analytics, support themes, operational data, and technical findings. Separate observed fact from inference.
3. Objectives and non-objectives
Name what should improve and adjacent work that remains outside scope.
4. Users and context
Describe roles, permissions, goals, constraints, and the situation in which the workflow occurs.
5. Scope
List must-have workflows, planned-later work, and explicitly excluded ideas.
6. Flow and states
Cover beginning, success, loading, empty, validation, errors, permission denial, cancellation, recovery, and return use where relevant.
7. Business rules
State rules as testable conditions:
> A reviewer can approve only records assigned to their region; reassignment records actor, time, old owner, and new owner.
8. Data and relationships
Define entities, required fields, sources of truth, retention, history, import/export, and migration.
9. Integrations and dependencies
Name direction, authentication, limits, failures, owner, and test environment.
10. Analytics and evidence
Track only the events required to assess outcome, failure, and operational health.
11. Acceptance criteria
Describe observable completion for the important behaviour, including permissions and failure states.
12. Risks, assumptions, and open questions
Assign owner and resolution date. Do not hide uncertainty inside confident prose.
Use examples and decision tables
Rules are easier to review as examples:
| Account state | Payment state | Access |
|---|---|---|
| Active | Paid | Full |
| Active | Failed within grace period | Limited with notice |
| Suspended | Any | No access; support path shown |
Examples reveal conflicts faster than paragraphs.
What not to put in the PRD
- every implementation detail;
- fixed UI before flow and rules are agreed;
- invented certainty;
- meeting transcripts;
- an unprioritised wish list;
- acceptance criteria such as “works well”.
Link design, architecture, and research artefacts rather than copying stale versions into one giant document.
Review the PRD together
Product, design, engineering, data, operations, and specialist reviewers should walk through the core path and failures. Async comments alone tend to optimise local wording rather than reveal incompatible assumptions.
Common questions
How long should a PRD be?
As short as possible while making consequential behaviour testable. A feature may need a few pages; a complex workflow may need linked data, permission, and integration specifications.
Who writes the PRD?
One accountable product owner usually maintains it, with design, engineering, operations, data, and domain experts contributing decisions.
Should engineers write technical requirements in the PRD?
They should shape feasibility, constraints, data, failure, and acceptance. Detailed implementation can live in architecture records linked from the PRD.
Is a PRD fixed after development starts?
No. Update it when evidence or constraints change, record the reason, and make the effect on scope, date, and acceptance visible.
Does every feature need a PRD?
No. Small, low-risk changes may need a clear issue and acceptance criteria. Use more documentation when consequence, uncertainty, or coordination increases.
