The worst PRDs are the ones nobody reads. I've seen 40-page specification documents gathering dust while engineers message the PM every hour for clarification. I've also seen three-sentence PRDs that led to three different teams building three different interpretations of the same feature. A good PRD creates shared understanding. It answers the questions engineers will have before they start coding, without burying those answers in bureaucratic text nobody has time to read. ## Why PRDs Fail Most PRD failures follow predictable patterns: | Failure Mode | What Happens | Better Approach | | ------------------- | ---------------------------------------- | -------------------------------------------- | | Solution before why | Specifies features without user problems | Start with problem statement, then solutions | | Too vague | "Fast", "user-friendly", "secure" | Specific, testable requirements | | Too detailed | 40 pages of edge cases | Focus on primary use cases, defer edge cases | | Written in vacuum | PM writes alone, throws over wall | Collaborative draft with eng/design input | | Frozen in time | Never updated after kickoff | Living document that evolves | ## What Belongs in a PRD Every PRD needs these seven sections: ### 1. Problem Statement **2-3 sentences** that explain: - Who has this problem? - How are they dealing with it today? - What's the cost of continuing with the status quo? **Bad:** "Users want a better export experience." **Good:** "Small business owners reconciling monthly books spend 2 hours manually copying transaction data from Stripe into QuickBooks. 60% of our support tickets are about export errors." ### 2. User Stories (3-5 primary use cases) Format: **AS A** [user] **WHEN** [situation] **I WANT TO** [action] **SO THAT** [outcome] Include acceptance criteria—testable conditions that define "done." ### 3. Success Metrics Define 2-3 specific, measurable outcomes: | Bad Metric | Good Metric | | ---------------------------- | ----------------------------------------------------------------- | | "Improve user experience" | "Reduce checkout time from 4 min to 2 min" | | "Increase engagement" | "Increase trial-to-paid conversion from 15% to 20% within 30 days" | | "Make it easier" | "80% of users complete first action without documentation" | ### 4. Requirements **Functional** (what it must do): - Clear, specific capabilities an engineer can build and QA can test - Avoid vague terms like "fast" or "user-friendly" **Non-functional** (how well it must do it): - Performance: "Dashboard loads in <2s on 3G with 1000 transactions" - Security: "OAuth 2.0 with MFA for admin accounts" - Accessibility: "WCAG 2.1 Level AA, keyboard navigation" - Compatibility: "Chrome, Firefox, Safari (last 2 versions)" ### 5. Explicitly Out of Scope List 3-5 things stakeholders might assume are included but aren't: - **What** you're not building - **Why** it's out of scope - **When** (if ever) you might revisit **Example:** "Mobile app deferred to Q3—95% of usage happens on desktop, would delay core features by 3 months." ### 6. Visual Communication Text alone isn't enough. Engineers need to see what you're describing. Include: **Design mockups:** Link to Figma files showing the UI. Don't paste screenshots—link to live designs that stay updated. **Prototypes:** When interactions are complex, a clickable prototype says more than paragraphs of text. See [High-Fidelity Prototyping](/chapter/high-fidelity-prototyping) for building realistic prototypes, or run an [AI Prototyping Sprint](/chapter/ai-prototyping-sprint) to create one in 4 hours. **Flow diagrams:** User flows, state machines, or system diagrams for complex logic. **Data models:** If you're defining new entities, show their relationships. **Example:** Instead of "Users can filter transactions by date," show a mockup of the date picker and write: "Users select start/end dates using the calendar component (see Frame 12 in Figma). Selected range appears as chips above the table." Visual artifacts prevent misinterpretation. When everyone's looking at the same mockup, there's less room for "I thought you meant..." ### 7. Open Questions For each TBD decision: - Who should decide this? - What information do they need? - What's a reasonable default? - When must this be resolved? ## The 60-Minute PRD Sprint **Minutes 0-15: Define the Problem** 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? ## Example: Transaction Export Feature Here's what a complete user story looks like in practice: **User Story:** _AS A_ small business owner using Stripe for payment processing _WHEN_ I'm reconciling my monthly books at month-end _I WANT TO_ filter transactions by date range and export to CSV _SO THAT_ I can import directly into QuickBooks, saving 2 hours/month **Acceptance Criteria:** - Date picker supports custom range (any start/end in past 2 years) - CSV includes: ID, date, amount, currency, customer, status, fees - Export completes in <5s for up to 10,000 transactions - Filename format: `stripe-transactions-YYYY-MM-DD.csv` - Browser download (not email) on clicking "Export" - Specific error messages (not generic "something went wrong") **Out of Scope for V1:** - Scheduled/automated exports (planned for V2) - PDF format (low demand from user research) - Exports >10K transactions (affects <1% of users) This level of detail prevents back-and-forth. The engineer knows what to build. The designer knows what interactions to design. QA knows what to test. ## Common Mistakes **Mistake 1: Writing in a vacuum** Share early drafts with engineering and design. When people contribute to shaping the PRD, they're invested in building it. **Mistake 2: Vague requirements** "The page should load fast" means nothing. "Dashboard loads in <2s on 3G with 1000 transactions" is testable. **Mistake 3: No "not doing" list** Stakeholders will assume their pet feature is included unless you explicitly say it's not. **Mistake 4: Frozen document** Best PRDs evolve. When you discover your assumption was wrong during development, update the PRD. It's your shared memory, not a legal contract. **Mistake 5: No measurable success** "Improve the experience" isn't a metric. "Reduce checkout abandonment from 40% to 25%" is. ## Making PRDs People Actually Read **Lead with why.** Engineers who understand the problem make better decisions than those following a spec. **Use clear structure.** Headers and bullets get read. Walls of text get skimmed. **Link, don't duplicate.** Point to Figma files rather than pasting screenshots. The PRD is a map, not a novel. **Keep it current.** Delete outdated sections. A PRD with stale info trains people to ignore it. **Make it collaborative.** Use comments. Encourage questions. The PRD that feels like "our shared plan" gets more engagement than "the PM's specification." ## Your Action Items Start with the problem, not the solution Write 3-5 user stories with specific acceptance criteria Define both functional and non-functional requirements Explicitly list what's out of scope and why Identify dependencies, risks, and mitigation strategies Add open questions with assigned owners Share early drafts for feedback before finalizing Keep the PRD updated as you learn during development Review completed features against the PRD to capture learnings The best PRD isn't the longest or the most detailed—it's the one that creates shared understanding between product, design, and engineering. It's the document everyone refers to when questions arise, and the artifact that explains why you made the decisions you did.