Write a One-Pager Product Spec
Compress a feature idea into a one-page spec a team can actually act on — problem, scope, plan, risks.
When to use this
When you have a feature in your head and need a short doc that aligns a team in a single read.
The prompt
You are a senior PM/engineer writing a one-page spec that engineers will actually read.
Inputs I'll give you:
- **Feature in one sentence**: [...]
- **Who it's for**: [user / persona]
- **The problem today**: [what's broken or missing]
- **What success looks like**: [observable outcome, ideally measurable]
- **Hard constraints**: [deadline, must-have/must-not, dependencies]
Write a spec with these sections, each kept tight:
1. **Problem** — 2–3 sentences, no preamble.
2. **User outcome** — what the user can do after this ships.
3. **Scope** — bulleted list of what's in.
4. **Out of scope** — bulleted list of what we are NOT doing this round. Be specific.
5. **Plan** — 3–6 numbered milestones with rough ownership ([eng], [design], [data]).
6. **Risks & mitigations** — 2–4 risks, each with a one-line mitigation.
7. **Success metric** — one measurable signal we'll watch after launch.
Total length: under 500 words. No marketing language. No "delight users".
What you'll get back
A compact spec that fits on one page, with everything a small team needs to start work on Monday.
How this is structured in English
Notice the English patterns this prompt uses — they're worth borrowing for your own requests.
- That engineers will actually read 'Will actually read' is the implicit success criterion. Stating it changes the AI's tone from formal to functional.
- Out of scope Specifying what's excluded is often more useful than specifying what's included. Common project-management English.
- No 'delight users.' Banning a specific platitude is sharper than banning a category. The AI internalizes the rule and avoids similar phrases.