Product Requirements Document: [Product or area name]

Author: [Your name] Status: [Draft / In review / Approved] Date: [Date] Target release: [Version or date] Stakeholders: [Product, design, engineering, and business owners]

---

1. Overview and problem

[In a short paragraph, describe the product or area and the user or business problem it addresses. A reader should understand what is being built and why it matters before reading any further.]

2. Goals and success metrics

Goals

• [The primary outcome this release must achieve.]
• [A secondary goal, if there is one.]

Success metrics

Metric	Baseline today	Target	How it's measured
[e.g., adoption]	[current]	[target]	[source / method]
[e.g., time saved]	[current]	[target]	[source / method]

3. Target users and personas

• [Persona name] — [their role, context, and the job they are trying to do]
• [Persona name] — [their role, context, and the job they are trying to do]

[For each persona, note the frustration this product relieves and the value they get.]

4. User stories and requirements

User stories

• As a [role], I want [capability] so that [benefit].
• As a [role], I want [capability] so that [benefit].

Functional requirements

[Number each requirement so it can be referenced and traced. Label priority (Must / Should / Could). Describe behaviour and outcome, not implementation.]

1. (Must) [The product must ...]
2. (Must) [The product must ...]
3. (Should) [The product should ...]
4. (Could) [The product could ...]

5. Scope and non-goals

In scope for this release

• [What is included.]
• [What is included.]

Non-goals

• [Something a reader might expect that this release deliberately does NOT do.]
• [Another explicit exclusion that keeps scope honest.]

6. UX considerations

[The key flows, states, and principles the experience must respect — without dictating the final design. Note empty, error, and edge states the team should account for. Link to designs when they exist.]

7. Dependencies and risks

Item	Type	Impact	How we'll handle it
[Other team / system / data]	Dependency	[What it blocks]	[Plan]
[What could go wrong]	Risk	[Effect if it happens]	[Mitigation]

8. Release criteria

[The conditions that must be true before this ships — must-have requirements complete, quality bars met, metrics instrumented, and the required sign-offs.]

• [All Must requirements implemented and verified.]
• [Success metrics are instrumented and reporting.]
• [Quality bar met — e.g., no open critical defects.]
• [Sign-off from [owner].]

---

Open questions

• [Anything not yet decided that could change the PRD — assign an owner and resolve before build.]