Build a structured PRD that connects problem, users, solution, and success criteria. Use when turning discovery notes into an engineering-ready document for a major initiative.

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. Input Works best with: The feature or initiative the PRD covers. Also useful: Discovery notes, problem statements, user research, success metrics, and constraints — paste whatever exists; the workflow slots it into the right phases and skips what's already answered. Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re ask. Arriving empty handed? That works too. The workflow starts at problem definition and builds up from there. Example invocation: Build a PRD for self serve workspace provisioning — here are my discovery notes and the OKR it ladders to. 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) 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 Aligning cross functional teams on scope and requirements Documenting decisions for future reference Onboarding new team members to a project When NOT to Use This For small bug fixes or trivial features (overkill) When problem and solution are already clear and aligned (just write user stories) For continuous discovery experiments (use Lean UX Canvas instead) Facilitation Source of Truth When running this workflow as a guided conversation, use [ workshop facilitation ](../workshop facilitation/SKILL.md) as the interaction protocol. It defines: session heads up + entry mode (Guided, Context dump, Best guess) one question turns with plain language prompts progress labels (for example, Context Qx/8 and Scoring Qx/5) interruption handling and pause/resume behavior numbered recommendations at decision points quick select numbered response options for regular questions (include Other (specify) when useful) This file defines the workflow sequence and domain specific outputs. If there is a conflict, follow this file's workflow logic. Application Use template.md as the fill in document. The template includes: Per section coaching blocks — each section has its own Instructions, Steps, Contributing Skills, and Activities so the template is self guiding even without this workflow. Inline gap tagging — tag every gap as 🔶 Assumption (plausible but unvalidated) or 🔵 Open Question (unknown, needs discovery). Tag inline where the gap appears, not just at the end. Cross section recommendation prompts — after completing each section, a "Before moving on" block checks consistency with prior sections and warns about what the next section will need. Self assessment — after Section 10, a diagnostic captures the strongest section, weakest section, top assumptions to validate, and the recommended next step before sharing the PRD. Skill cross reference table — maps 15 skills to the specific sections they feed (e.g., problem framing canvas → Section 2, epic breakdown advisor → Section 7). This workflow orchestrates 8 phases over 2 4 days , using multiple component and interactive skills. The phases below describe the facilitation sequence; the template captures the output. Phase 1: Executive Summary (30 minutes) Goal: Write a one paragraph overview for skimmers. Activities 1. Draft Executive Summary Format: "We're building [solution] for [persona] to solve [problem], which will result in [impact]." Example: "We're building a guided onboarding checklist for non technical small business owners to solve the problem of 60% drop off in the first 24 hours due to lack of guidance, which will increase activation rate from 40% to 60% and reduce churn by 10%." Participants: PM Duration: 30 minutes Output: One paragraph summary Tip: Write this first (forces clarity), but refine it last (after other sections are complete). Phase 2: Problem Statement (60 minutes) Goal: Frame the customer problem with evidence. Activities 1. Write Problem Statement Use: skills/problem statement/SKILL.md (component) Input: Discovery insights from skills/discovery process/SKILL.md or skills/problem framing canvas/SKILL.md Participants: PM Duration: 30 minutes Output: Structured problem statement Example Problem Statement: 2. Add Supporting Context (Optional) Customer journey map: If problem spans multiple touchpoints Use: skills/customer journey mapping workshop/SKILL.md output Jobs to be done: If motivations are key Use: skills/jobs to be done/SKILL.md output Outputs from Phase 2 Problem statement: Who, what, why, evidence Supporting artifacts: Journey map, JTBD (if relevant) Phase 3: Target Users & Personas (30 minutes) Goal: Define who you're building for. Activities 1. Document Personas Use: skills/proto persona/SKILL.md (component) output Participants: PM Duration: 30 minutes Format: Include persona name, role, goals, pain points, behaviors Example: Outputs from Phase 3 Primary persona: Detailed profile Secondary personas: (if applicable) Phase 4: Strategic Context (45 minutes) Goal: Explain why this matters to the business and why now. Activities 1. Document Business Goals Source: Company OKRs, strategic memos, roadmap Format: Link feature to business outcomes Example: "This initiative supports our Q1 OKR: Reduce churn from 15% to 8%. Improving onboarding activation directly impacts retention." 2. Size Market Opportunity (Optional) Use: skills/tam sam som calculator/SKILL.md (interactive) output When: For major initiatives, new products, exec presentations Example: "TAM: 50M small businesses globally. SAM: 5M using SaaS tools. SOM: 500K solopreneurs in our target segments. Improving onboarding could unlock 30% of SAM (1.5M potential customers)." 3. Document Competitive Landscape (Optional) Source: Competitor research, G2/Capterra reviews Example: "Competitors (Competitor A, B) have guided onboarding. Our lack of guidance is cited as a churn reason in exit surveys." 4. Explain "Why Now?" Rationale: Why prioritize this now vs. later? Example: "Churn spiked 15% in Q4. Onboarding is the 1 driver (60% churn in first 30 days). Fixing this is critical to hitting retention OKR." Outputs from Phase 4 Business goals: OKRs or strategic initiatives Market opportunity: TAM/SAM/SOM (if applicable) Competitive context: How competitors address this Why now: Urgency rationale Phase 5: Solution Overview (60 minutes) Goal: Describe what you're building (high level, not detailed spec). Activities 1. Write Solution Description Format: High level overview, 2 3 paragraphs Example: 2. Add User Flows or Wireframes (Optional) Use: Design tools (Figma, Sketch), or hand drawn sketches When: For complex features requiring visual explanation Output: Embedded in PRD or linked 3. Reference Story Map (Optional) Use: skills/user story mapping workshop/SKILL.md output When: For complex features with multiple release slices Output: Link to story map Outputs from Phase 5 Solution description: High level overview User flows/wireframes: (if applicable) Story map: (if applicable) Phase 6: Success Metrics (30 minutes) Goal: Define how you'll measure success. Activities 1. Define Primary Metric Question: What is the ONE metric this feature must move? Example: "Activation rate (% of users completing first action within 24 hours)" Target: "Increase from 40% to 60%" 2. Define Secondary Metrics Question: What else should we monitor (but not optimize for)? Examples: Time to first action (reduce from 3 days to 1 day) Completion rate of onboarding checklist (target: 80%) Support ticket volume (reduce "How do I get started?" tickets by 50%) 3. Define Guardrail Metrics Question: What should NOT get worse? Example: "Sign up conversion rate (don't add friction to signup flow)" Example: Outputs from Phase 6 Primary metric: What you're optimizing for Secondary metrics: Additional success indicators Guardrail metrics: What shouldn't regress Phase 7: User Stories & Requirements (90 120 minutes) Goal: Break solution into user stories with acceptance criteria. Activities 1. Write Epic Hypothesis Use: skills/epic hypothesis/SKILL.md (component) Participants: PM Duration: 30 minutes Output: Epic hypothesis statement Example: "We believe that adding a guided onboarding checklist for non technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance. We'll measure success by activation rate 30 days post launch." 2. Break Down Epic into User Stories Use: skills/epic breakdown advisor/SKILL.md (interactive with Richard Lawrence's 9 patterns) Participants: PM, design, engineering Duration: 90 minutes Output: User stories split by patterns (workflow, CRUD, business rules, etc.) 3. Write User Stories Use: skills/user story/SKILL.md (component) Participants: PM Duration: 30 minutes per story Format: User story + acceptance criteria Example User Stories: 4. Document Constraints & Edge Cases Technical constraints: Platform limitations, browser support, etc. Edge cases: What if user skips step 2? What if they complete steps out of order? Outputs from Phase 7 Epic hypothesis: Testable statement User stories: 3 10 stories with acceptance criteria Constraints: Technical limitations, edge cases Phase 8: Out of Scope & Dependencies (30 minutes) Goal: Define what you're NOT building and what you depend on. Activities 1. Document Out of Scope Format: List features/requests explicitly excluded Rationale: Why not building now? Example: 2. Document Dependencies Technical dependencies: Platform upgrades, API changes required External dependencies: Third party integrations, partnerships Team dependencies: Design handoff, data pipeline work Example: 3. Document Open Questions Unresolved decisions:

prd-development