| name | prd-templates |
| description | PRD structure, writing patterns, and success metric definition. Use when authoring a product requirements document, writing a PRFAQ, or defining success criteria for a development cycle. |
PRD Templates
A PRD (Product Requirements Document) is the contract between Product and Development for a cycle. A weak PRD produces ambiguous builds, rework, and missed metrics. A strong PRD makes clear what's being built, why, what done looks like, and what's explicitly out of scope.
When to Use This Skill
- Writing a PRD for an upcoming development cycle
- Defining success metrics for a product initiative
- Scoping a cycle against engineering capacity
- Writing a PRFAQ (press release / FAQ) for a new product direction
- Reviewing a PRD for completeness before planning
PRD Structure
Minimal Viable PRD (for small cycles)
# PRD: [Feature Name]
## Problem Statement
[1-2 sentences: what user problem are we solving? Who has this problem?]
## Proposed Solution
[What we're building. Not implementation details — the user-facing change.]
## Success Metrics
- Primary: [The one metric that determines if this worked]
- Secondary: [Supporting metrics to watch]
- Guardrails: [Metrics that must NOT get worse]
## Scope
### In Scope
- [Feature or behavior 1]
- [Feature or behavior 2]
### Out of Scope
- [Explicitly excluded items — especially things stakeholders might assume are included]
## Constraints
- Timeline: [Hard deadline if any]
- Technical: [Known technical constraints]
- Regulatory: [Compliance requirements if any]
## Open Questions
- [ ] [Question that needs answering before or during build]
Full PRD (for large or high-stakes cycles)
# PRD: [Feature or Initiative Name]
**Author:** [Name]
**Status:** Draft / In Review / Approved
**Cycle:** [Quarter / Sprint range]
**Last updated:** [Date]
---
## 1. Problem Statement
### User Problem
[Who is affected, what's the situation, what's the pain or unmet need]
### Business Problem
[Why this matters from a business perspective — revenue, retention, competitive position]
### Evidence
- [Research finding 1 — with source]
- [Data point 1 — with source]
- [Quote or observation from user research]
---
## 2. Goals and Non-Goals
### Goals
- [What this initiative is trying to achieve]
### Non-Goals
- [What this initiative explicitly does NOT address]
---
## 3. Proposed Solution
### Summary
[2-3 sentence description of what we're building]
### User Experience Overview
[High-level description of what the user will experience. Not a spec — a narrative.]
---
## 4. Success Metrics
| Metric | Baseline | Target | Measurement Method |
|--------|---------|--------|--------------------|
| [Primary metric] | [Current value] | [Target] | [How measured] |
| [Secondary metric] | [Current value] | [Target] | [How measured] |
| [Guardrail metric] | [Current value] | Must not decrease | [How measured] |
**Measurement window:** [How long after launch before evaluating?]
---
## 5. Feature Backlog
Stack-ranked list of features for this cycle. Each item has: description, user story, and priority tier.
### Must Have (blocks launch)
| # | Feature | User Story |
|---|---------|-----------|
| 1 | [Feature] | As a [user type], I want [capability] so that [outcome] |
### Should Have (strong preference, deprioritize if capacity is tight)
| # | Feature | User Story |
|---|---------|-----------|
### Could Have (nice to have, cut if needed)
| # | Feature | User Story |
|---|---------|-----------|
### Won't Have This Cycle (explicitly deferred)
| Feature | Reason for Deferral |
|---------|-------------------|
---
## 6. Constraints and Dependencies
### Technical Constraints
- [Constraint 1]
### External Dependencies
- [Team / Service / API we depend on]
### Timeline Constraints
- [Hard dates and why they're hard]
---
## 7. Assumptions
| Assumption | Validation Status | Risk if Wrong |
|-----------|------------------|---------------|
| [Assumption 1] | Validated / Unvalidated | [Impact] |
| [Assumption 2] | Validated / Unvalidated | [Impact] |
---
## 8. Open Questions
- [ ] [Question] — Owner: [Name] — Due: [Date]
PRFAQ Format
The PRFAQ (Press Release / FAQ) is Amazon's method for defining a product by writing the announcement first. It forces clarity about customer benefit before diving into requirements.
# Press Release: [Product/Feature Name]
**FOR IMMEDIATE RELEASE**
**[Company] Launches [Feature], Enabling [Customer Benefit]**
[City, Date] — [Company] today announced [Feature], a new capability that [one-sentence value proposition]. Starting today, [user type] can [key action], [outcome].
"[Quote from a hypothetical satisfied customer describing the benefit in their words]"
[Feature] addresses [the problem] that [affected users] have faced with [current state]. With [Feature], users can now [key capability 1] and [key capability 2], resulting in [measurable outcome].
[Feature] is available [to whom, when, how].
---
# Frequently Asked Questions
**Q: Who is this for?**
A: [Target user description]
**Q: What problem does it solve?**
A: [Problem statement in user language]
**Q: How does it work?**
A: [User-facing explanation, no technical jargon]
**Q: What does it NOT do?**
A: [Explicit scope limitations]
**Q: How will users find and start using it?**
A: [Discovery and activation path]
**Q: How will we know if it's working?**
A: [Success metrics in plain language]
Success Metric Definition
Metric Hierarchy
North Star Metric
└── Primary Success Metric (for this initiative)
├── Leading Indicator (early signal, visible within days/weeks)
└── Lagging Indicator (confirms success, weeks/months)
└── Guardrail Metrics (must not degrade)
Metric Quality Checklist
A well-defined metric is:
Common Metric Mistakes
| Mistake | Example | Fix |
|---|
| Vanity metric | "Increase page views" | Tie to a business outcome: "Increase checkout conversion" |
| Unmeasurable | "Improve user happiness" | Define: "Increase NPS from 32 to 40" |
| Too broad | "Improve retention" | Scope to cycle: "Increase 30-day retention for new users acquired via organic search" |
| No baseline | "Achieve 70% task completion" | Always document current baseline |
Best Practices
- Write the out-of-scope section first — it's the hardest and most important part
- Define guardrail metrics — the things that must not get worse are as important as the success metrics
- Open questions are features too — unresolved questions in the PRD become rework during the cycle
- PRD is a living document — update it as decisions are made; it's the record of what was agreed
- Write for development agents as the audience — if something would require a clarifying question during build, it's not specific enough
