| name | write-prd |
| description | Write a Product Requirements Document (PRD). Use when the user says "write a PRD", "document this feature", "product requirements for X", "write requirements", "I need a PRD", "pitch this feature", or wants to formalize a feature or product idea into a structured doc - even if they don't explicitly say "PRD".
|
Overview
Based on Shape Up by Ryan Singer (Basecamp). A PRD defines the problem, the appetite, and the solution boundaries - not a detailed spec. The key insight from Shape Up: fix the time, flex the scope. Define how much the team is willing to spend before deciding what to build.
Workflow
Step 1: Set the Appetite
Before writing requirements, define the appetite - how much time is this worth?
- Small batch: 1-2 weeks
- Big batch: 4-6 weeks
If the solution requires more time than the appetite allows, cut the scope - don't extend the time.
Step 2: Write the Problem Statement
One paragraph. Answer: what is broken or missing today, who is affected, and what is the cost of not solving it. Avoid mentioning solutions here.
Step 3: Write the Pitch (Shape Up format)
Structure:
# PRD: [Feature Name]
**Appetite:** [Small batch / Big batch]
**Status:** Draft
**Author:** [your name]
## Problem
[What's broken, who's affected, cost of inaction]
## Solution
[Fat marker sketch - broad strokes, not pixel-perfect]
## Rabbit Holes
[Specific technical or design traps to avoid]
## No-Gos
[Explicitly what this does NOT include]
Step 4: Write the Solution at the right altitude
Shape Up's "fat marker sketch" principle: describe the solution broadly enough that engineers have room to make decisions. Over-specifying kills ownership and slows delivery.
Write requirements at the level of: "Users can do X" - not "There is a button in the top-right corner."
Step 5: Define Rabbit Holes
List specific traps the team could fall into. Examples:
- "Don't rebuild the notification system - use existing infrastructure"
- "Don't support bulk operations in v1"
Step 6: Define No-Gos
Explicit list of what this does NOT cover. This is the most important section for scope control.
Step 7: Add Open Questions
Format:
Q: [question]
Owner: [name]
Due: [date]
Anti-Patterns
1. Specifying solutions in the problem statement
Bad: "We need to add a modal because users don't see the CTA."
Good: "30% of users drop off at checkout. The CTA is not visible enough."
2. No appetite defined
Bad: PRD with requirements but no time boundary.
Good: "This is a small batch - 2 weeks max. If the solution needs more, cut scope."
3. Missing No-Gos
Bad: PRD with only what's included.
Good: Explicit No-Gos that prevent scope creep during build.
4. Over-specified requirements
Bad: "The button is blue, 48px, positioned top-right with 16px margin."
Good: "Users can trigger X from the main action area." (Let design decide the details.)
Quality Checklist
