prd-development

## Purpose Guide product managers through structured PRD (Product Requirements Document) creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document. Use this to move from scattered notes and Slack threads to a clear, comprehensive PRD that aligns stakeholders, provides engineering context, and serves as a source of truth—avoiding ambiguity, scope creep, and the "build what's in my head" trap. This is not a waterfall spec—it's a living document that captures strategic context, customer problems, proposed solutions, and success criteria, evolving as you learn through delivery. ## Key Concepts ### What is a PRD? A PRD (Product Requirements Document) is a structured document that answers: 1. **What problem are we solving?** (Problem statement) 2. **For whom?** (Target users/personas) 3. **Why now?** (Strategic context, business case) 4. **What are we building?** (Solution overview) 5. **How will we measure success?** (Metrics, success criteria) 6. **What are the requirements?** (User stories, acceptance criteria, constraints) 7. **What are we NOT building?** (Out of scope) ### PRD Structure (Standard Template) ```markdown # [Feature/Product Name] PRD ## 1. Executive Summary - One-paragraph overview (problem + solution + impact) ## 2. Problem Statement - Who has this problem? - What is the problem? - Why is it painful? - Evidence (customer quotes, data, research) ## 3. Target Users & Personas - Primary persona(s) - Secondary persona(s) - Jobs-to-be-done ## 4. Strategic Context - Business goals (OKRs) - Market opportunity (TAM/SAM/SOM) - Competitive landscape - Why now? ## 5. Solution Overview - High-level description - User flows or wireframes - Key features ## 6. Success Metrics - Primary metric (what we're optimizing for) - Secondary metrics - Targets (current → goal) ## 7. User Stories & Requirements - Epic hypothesis - User stories with acceptance criteria - Edge cases, constraints ## 8. Out of Scope - What we're NOT building (and why) ## 9. Dependencies & Risks - Technical dependencies - External dependencies (integrations, partnerships) - Risks and mitigations ## 10. Open Questions - Unresolved decisions - Areas requiring discovery ``` ### Why This Works - **Alignment:** Ensures everyone (PM, design, eng, stakeholders) understands the "why" - **Context preservation:** Captures research and strategic rationale for future reference - **Decision log:** Documents what's in scope, out of scope, and why - **Execution clarity:** Provides engineering with user stories and acceptance criteria ### Anti-Patterns (What This Is NOT) - **Not a detailed spec:** PRDs frame the problem and solution; they don't specify UI pixel-by-pixel - **Not waterfall:** PRDs evolve as you learn; they're not frozen contracts - **Not a substitute for collaboration:** PRDs complement conversation, not replace it ### When to Use This - Starting a major feature or product initiative - Al