Most PRDs are either too long (nobody reads them) or too short (everybody interprets them differently). The goal isn't documentation for its own sake—it's creating shared understanding so the team builds the right thing. A good PRD answers every question an engineer might have before they start coding, without requiring a 30-page document to do it. ## What Belongs in a PRD | Section | Purpose | Length | |---------|---------|--------| | Problem Statement | Why are we building this? | 2-3 sentences | | User Stories | Who needs what and why? | 3-5 stories | | Success Metrics | How do we know it worked? | 2-3 metrics | | Requirements | What exactly must it do? | Detailed list | | Non-Requirements | What are we explicitly NOT doing? | 3-5 items | | Design Specs | How should it look/feel? | Links to designs | | Technical Notes | Constraints, dependencies, risks | As needed | | Open Questions | What do we still need to decide? | List with owners | ## Example: Stripe-Style User Story Bad user story: "As a user, I want to see my transactions." Good user story: | Component | Content | |-----------|---------| | User | Small business owner using Stripe for payments | | Situation | End of month, reconciling books | | Want | Filter transactions by date range and export to CSV | | So that | Can import into QuickBooks without manual data entry | | Acceptance Criteria | • Date picker with custom range • CSV includes all transaction fields • Export completes in <5 seconds for up to 10K transactions | ## The 60-Minute PRD Sprint **Minutes 0-15: Define the Problem** Start with why, not what. Use this prompt: I'm writing a PRD for [FEATURE NAME]. Help me articulate: 1. What problem are we solving? (Not the solution—the actual user pain) 2. Who has this problem? (Specific user type with context) 3. How are they solving it today? (Current workaround) 4. What's the cost of the status quo? (Time, money, frustration) 5. Why now? (What changed that makes this important) 6. How will we know we solved it? (Observable change in behavior or metrics) Be specific and avoid generic statements like "users want a better experience." **Minutes 15-35: Generate User Stories** For this problem: [PASTE PROBLEM STATEMENT] Generate 5 user stories using this format: AS A [specific user type with context] WHEN [specific situation/trigger] I WANT TO [action/capability] SO THAT [outcome/benefit] ACCEPTANCE CRITERIA: • [Testable condition 1] • [Testable condition 2] • [Testable condition 3] For each story, also note: - Priority (must-have, should-have, nice-to-have) - Edge cases to consider - What "done" looks like **Minutes 35-50: Define Requirements** Based on these user stories: [PASTE USER STORIES] Generate a requirements list with: FUNCTIONAL REQUIREMENTS (What it must do): - List each capability with clear, testable criteria NON-FUNCTIONAL REQUIREMENTS (How well it must do it): - Performance (speed, capacity) - Security (auth, data protection) - Accessibility (WCAG level, screen reader support) - Compatibility (browsers, devices) EXPLICITLY OUT OF SCOPE: - What we're NOT building (prevents scope creep) - Why each item is out of scope DEPENDENCIES: - APIs, services, or features this requires - Teams we need input from RISKS: - What could go wrong - Mitigation for each risk **Minutes 50-60: Add Open Questions** Review this PRD draft: [PASTE YOUR PRD SO FAR] Identify: 1. OPEN QUESTIONS: Decisions we haven't made yet (with suggested owner for each) 2. ASSUMPTIONS: Things we're assuming are true (flag risky assumptions) 3. MISSING INFO: Data or research we need before building 4. EDGE CASES: Unusual scenarios we haven't addressed For each open question, suggest: - Who should decide this? - What information do they need to decide? - What's a reasonable default if we can't decide quickly? ## Requirements Writing Tips | Bad Requirement | Why It's Bad | Good Requirement | |-----------------|--------------|------------------| | "Fast loading" | Not measurable | "Page loads in <2 seconds on 3G" | | "User-friendly interface" | Subjective | "User completes task in <3 clicks" | | "Secure authentication" | Vague | "OAuth 2.0 with MFA support" | | "Should work on mobile" | Incomplete | "Responsive design, touch targets ≥44px" | ## Common Mistakes **Mistake 1: Solution before problem** Starting with "we need a button that..." instead of "users struggle with..." leads to building features nobody needs. **Mistake 2: No success metrics** If you can't measure whether the feature worked, you'll never know if it was worth building. **Mistake 3: Missing edge cases** Engineers will find them during development. Better to identify them in the PRD where discussion is cheap. **Mistake 4: PRD as handoff** A PRD is a conversation starter, not a specification thrown over the wall. Engineers should be involved in writing it. ## Your Action Items Start with the problem, not the solution Write 3-5 user stories with acceptance criteria Define functional and non-functional requirements Explicitly list what's out of scope Identify dependencies and risks Add open questions with owners Review with engineering before finalizing Update PRD as you learn during development The best PRD is one that engineers actually read and refer back to. Keep it focused, keep it updated, and remember: the document exists to create shared understanding, not to cover your ass.