Requirements
PRD template with a filled-in example
A reusable PRD structure, with each section shown twice — what goes there, and a worked example for a real feature you can adapt.
Here's a lean PRD structure with each section explained and then shown with a worked example — a password-reset feature for a SaaS app. Copy it, delete the example text, and adapt.
1. Problem statement
What it's for: the pain and who has it.
Example: "Users who forget their password have no self-serve way to regain access; they email support, which handles ~400 such tickets a month at an average 6-hour resolution. This frustrates users and burns support capacity."
2. Target users
Example: "Primary: existing account holders locked out. Secondary: support agents who currently resolve these manually."
3. Goals & success metrics
Example: "Cut password-related support tickets by 80% within one quarter of launch. 95% of reset attempts complete without contacting support."
4. Requirements (user stories + acceptance criteria)
Example: "As a locked-out user, I want to reset my password via email, so that I can regain access without contacting support. Acceptance criteria: reset link is single-use; expires in 60 minutes; new password must meet policy; user is notified by email after a successful change."
5. Scope
Example: "In: email-based reset. Out (this release): SMS reset, security-question recovery, admin-initiated resets."
6. Dependencies & timeline
Example: "Depends on the transactional email service; sequence after the email-template refactor. Target: end of Q2."
7. Risks
Example: "Reset emails landing in spam; token-reuse attacks if expiry/single-use isn't enforced."
8. Open questions
Example: "Do we force logout of other sessions on reset? Awaiting security review."
- For a small agile feature, the first five sections may be enough.
- For regulated domains (health, finance), expand requirements, add traceability, and keep a fuller risk section — compliance teams may rely on the PRD directly.
- A good template has eight parts: problem, users, goals/metrics, requirements, scope, dependencies, risks, open questions.
- Each requirement is a user story plus acceptance criteria.
- Fill the out-of-scope and open-questions sections — empty ones signal incomplete thinking.
- Adapt depth to context: lighter for agile features, heavier for regulated domains.
Try the PRD workflow in Cadenly
Skip the blank page — Cadenly's PRD workflow generates each section from your answers and keeps them consistent with each other.
Start free →