| name | prd-outliner |
| description | Writes a complete product requirements document (2–4 pages) from a feature brief. Sections: problem statement, solution, personas, use cases, acceptance criteria (testable), success metrics (with baseline and target), dependencies, risks, competitive context, and non-scope. All acceptance criteria are outcome-focused, not effort-focused. All success metrics have specific numeric targets. |
PRD Outliner
When to activate
When a feature concept, user problem, or business opportunity is ready to move from pitch to detailed specification. Use this to create a complete PRD that can be handed to engineering, design, and other stakeholders for review.
When NOT to use
Do not use for bug fixes or minor refinements — those don't need a full PRD. Do not use if the problem is not yet clearly defined. Do this skill only after problem definition is complete.
Instructions
- Start with the problem statement. Interview the requesting stakeholder and/or customer data to define: who is affected, what is the current friction, what is the business impact of that friction. One paragraph max.
- Define the solution in one paragraph. This is the proposed way to solve the problem. Keep it short; details come in the use cases.
- Create 2–3 user personas affected by this feature. Each has a name, role, and one-sentence goal.
- Describe 2–3 use cases from each persona's perspective. "As a [persona], I want [action] so that [outcome]."
- Write acceptance criteria. These must be testable — you could write an automated test for each one. Use "can," "will," "does" — not "should," "might," "ideally."
- Define success metrics. Each metric has: (a) baseline — where you are now, (b) target — where you want to go, (c) measurement plan — how you'll track it.
- List dependencies: what from engineering (API, database schema), design, data, or third parties is needed.
- Identify 2–4 risks and specific mitigation steps for each.
- Competitive context: how are competitors solving this? What's your differentiation?
- Non-scope: what is NOT in this PRD. This prevents scope creep.
Output Format
# [Feature Name] — PRD
## Problem Statement
[1 paragraph, max 150 words. Who, what friction, business impact.]
## Solution Overview
[1 paragraph, max 100 words. What we're building and why.]
## User Personas
- **[Persona 1]** — [role] — Goal: [one-sentence goal]
- **[Persona 2]** — [role] — Goal: [one-sentence goal]
## Use Cases
[2–3 per persona. "As a [persona], I want [action] so that [outcome]."]
## Success Metrics
| Metric | Baseline | Target | Measurement Plan |
|---|---|---|---|
| [Metric 1] | [current] | [goal] | [how we measure] |
| [Metric 2] | [current] | [goal] | [how we measure] |
## Acceptance Criteria
- [ ] [Can do X] (testable)
- [ ] [Will show Y] (observable)
- [ ] [Does not Z] (boundary condition)
## Dependencies
- Engineering: [APIs, schema, integrations needed]
- Design: [Components, flows, brand resources needed]
- Data: [Analytics events, dashboards needed]
- Third-party: [APIs, vendors needed]
## Risks & Mitigations
| Risk | Impact | Mitigation |
|---|---|---|
| [Risk 1] | High/Med/Low | [Specific mitigation step] |
## Competitive Context
[How competitors solve this. Your differentiation in 2–3 sentences.]
## Non-Scope
[Explicitly list 2–3 things NOT in this PRD.]
