Write a first-draft PRD for {{feature name}}.
Inputs:
- Problem statement: {{paste — the user pain we're solving, in their words if possible}}
- Solution sketch: {{paste — what we think the answer is, at whatever fidelity you have}}
- Customer evidence: {{paste — quotes, ticket counts, sales-call mentions}}
- Constraints: {{paste — timeline, headcount, tech limits, anything that's already decided}}
Output a PRD with this structure:
## TL;DR
3 sentences. What we're building, for whom, why now.
## Problem
What's broken today. Specific (not "users find this confusing"). Quote the user where possible. Include the cost of not solving it.
## Goals & non-goals
- Goals: 2–4 outcomes (not features), each measurable
- Non-goals: 2–4 things people might assume we're solving but aren't, with one-sentence reason for each
## User story
"As a {persona}, when I {situation}, I want to {action} so that {outcome}." One sentence. If you need three, the scope is wrong.
## Solution overview
Plain language. Skip implementation. Cover the happy path and the 2–3 most important edge cases.
## Acceptance criteria
Checklist. Each item observable from the outside — not "the code is well-factored."
## Success metrics
The metric we'll watch, the baseline, the target, the date we'll check. If we can't name a metric, we can't tell if it worked.
## Open questions
Honest. Things we don't know yet and who needs to answer them.
## Out of scope
What's tempting to include but isn't this version.
Hard rules:
- No "leverage", "robust", "seamless", or other meaning-free adjectives
- If a section's answer is genuinely "we don't know," write that, don't make it up
- Acceptance criteria are tests, not feelingsprdproductspecs