qa-aman 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
- Appetite is defined (small or big batch)
- Problem statement explains "why", not "what"
- Solution is at the right altitude - no pixel-level specs
- Rabbit holes are listed
- No-Gos are explicit
- Open questions have owners and due dates