Outcome
The user or business change, plus the metric that will show whether it happened.
Product requirements
Write the decision document before the build prompt
A useful PRD aligns people and agents on the outcome, boundaries, workflows, constraints, and evidence of success. It should reduce ambiguity without prescribing every implementation detail.
The minimum useful structure
Scope
What is included, excluded, assumed, and explicitly deferred for this release.
Behavior
Primary workflows, edge cases, failure states, permissions, and recovery paths.
Acceptance
Observable conditions that product, design, engineering, and QA can evaluate.
Start with a compact template
Delete sections that do not affect a decision. Add diagrams, data contracts, prototypes, and research links where prose would be less precise.
# Product name
## Outcome
What measurable change should this work create?
## User and problem
Who has the problem, and what evidence shows it matters?
## Scope
- In:
- Out:
- Assumptions:
## Core workflows
1. Starting state
2. User or agent action
3. System response
4. Success and recovery states
## Requirements
- Functional:
- Data and privacy:
- Performance and reliability:
- Accessibility:
## Acceptance criteria
- Given ...
- When ...
- Then ...
## Measurement
Primary metric, guardrail metrics, and instrumentation.
## Risks and open decisions
Owner and decision date for each unresolved item.
Make it ready for an agent handoff
Agents still need repository-specific context and should not infer business decisions that the PRD leaves unresolved.
Link source material
Reference designs, schemas, APIs, analytics events, existing patterns, and decision records.
Name approval gates
Call out actions that need product, security, legal, finance, or human confirmation.
Separate facts from options
Label confirmed requirements, assumptions, proposed approaches, and open questions.
Include verification
Provide commands, test cases, target environments, and user-visible completion checks.