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)

• One-paragraph overview (problem + solution + impact)

• Who has this problem?
• What is the problem?
• Why is it painful?
• Evidence (customer quotes, data, research)

• Primary persona(s)
• Secondary persona(s)
• Jobs-to-be-done

• Business goals (OKRs)
• Market opportunity (TAM/SAM/SOM)
• Competitive landscape
• Why now?

• High-level description
• User flows or wireframes
• Key features

• Primary metric (what we're optimizing for)
• Secondary metrics
• Targets (current → goal)

• Epic hypothesis
• User stories with acceptance criteria
• Edge cases, constraints

• What we're NOT building (and why)

• Technical dependencies
• External dependencies (integrations, partnerships)
• Risks and mitigations

• Unresolved decisions
• Areas requiring discovery

undefined

• 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

• 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

• 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

• 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)

workshop-facilitation

• 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)

• 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

• 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

undefined

• User impact: Wastes time (30-60 min trying to figure out product), never reaches "aha moment," churns before experiencing value
• Business impact: 60% activation rate → high churn, low LTV, poor word-of-mouth

• Interviews: 8/10 churned users said "I didn't know what to do first" (discovery interviews, Feb 2026)
• Analytics: 60% of signups complete 0 actions within 24 hours (Mixpanel, Jan 2026)
• Support tickets: "How do I get started?" is #1 support question (350 tickets/month)
• Customer quote: "I logged in, saw an empty dashboard, and thought 'now what?' I gave up and went back to my spreadsheet."

**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

• Problem statement: Who, what, why, evidence
• Supporting artifacts: Journey map, JTBD (if relevant)

• Use:

  skills/proto-persona/SKILL.md

  (component) output
• Participants: PM
• Duration: 30 minutes
• Format: Include persona name, role, goals, pain points, behaviors

undefined

• Role: Freelance consultant, solopreneur
• Company size: 1 person (no IT support)
• Tech savviness: Low (uses email, spreadsheets, basic SaaS)
• Goals: Get value from software fast without technical expertise
• Pain points: Overwhelmed by complex UIs, no time to watch tutorials, needs immediate value
• Current behavior: Signs up for products, tries for 1 day, churns if not immediately useful

• Role: Owner-operator, manages team
• Needs: Onboard team members quickly
• Differs from primary: More tolerant of complexity, willing to invest setup time

undefined

• Primary persona: Detailed profile
• Secondary personas: (if applicable)

• 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."

• 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)."

• 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."

• 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."

• Business goals: OKRs or strategic initiatives
• Market opportunity: TAM/SAM/SOM (if applicable)
• Competitive context: How competitors address this
• Why now: Urgency rationale

• Format: High-level overview, 2-3 paragraphs
• Example:

undefined

1. User signs up and logs in for the first time
2. Modal appears: "Let's get you set up! Complete these 3 steps to get started."
3. Checklist shows:
   • ☐ Create your first project
   • ☐ Invite a teammate (optional)
   • ☐ Complete a sample task
4. As user completes each step, checklist updates with checkmarks
5. After completion, celebration modal: "You're all set! Here's what to do next."

• Minimal: Only 3 core steps (not overwhelming)
• Dismissible: Users can skip if they prefer to explore
• Progress tracking: Visual progress bar (1/3, 2/3, 3/3)
• Celebration: Positive reinforcement when complete

**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

• Solution description: High-level overview
• User flows/wireframes: (if applicable)
• Story map: (if applicable)

• 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%"

• 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%)

• Question: What should NOT get worse?
• Example: "Sign-up conversion rate (don't add friction to signup flow)"

undefined

• Current: 40%
• Target: 60%
• Timeline: Measure 30 days after launch

• Time-to-first-action: Reduce from 3 days to 1 day
• Onboarding checklist completion rate: 80% of users complete all 3 steps
• Support tickets: Reduce "How do I get started?" tickets from 350/month to 175/month

• Sign-up conversion rate: Maintain at 10% (don't add friction to signup)

undefined

• Primary metric: What you're optimizing for
• Secondary metrics: Additional success indicators
• Guardrail metrics: What shouldn't regress

• Use:

  skills/epic-hypothesis/SKILL.md

  (component)
• Participants: PM
• Duration: 30 minutes
• Output: Epic hypothesis statement

"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."

• 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.)

• Use:

  skills/user-story/SKILL.md

  (component)
• Participants: PM
• Duration: 30 minutes per story
• Format: User story + acceptance criteria

undefined

• When user logs in for the first time, modal appears with checklist
• Checklist shows 3 steps: "Create project," "Invite teammate," "Complete task"
• Modal is dismissible (close button)
• If dismissed, checklist doesn't reappear (user preference saved)

• When user completes step 1, checkmark appears next to "Create project"
• Progress bar updates (1/3 → 2/3 → 3/3)
• Checklist persists across sessions (if user logs out and back in)

• When user completes all 3 steps, celebration modal appears
• Message: "You're all set! Here's what to do next: [suggested next actions]"
• Confetti animation (optional, nice-to-have)

**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?

• Epic hypothesis: Testable statement
• User stories: 3-10 stories with acceptance criteria
• Constraints: Technical limitations, edge cases

• Format: List features/requests explicitly excluded
• Rationale: Why not building now?

undefined

• Advanced onboarding personalization (e.g., different checklists per persona) — Adds complexity, test simple version first
• Video tutorials embedded in checklist — Resource-intensive, validate checklist concept first
• Gamification (badges, points) — Nice-to-have, focus on core workflow guidance

• Mobile-optimized onboarding (desktop-first for now)

**2. Document Dependencies**
- **Technical dependencies:** Platform upgrades, API changes required
- **External dependencies:** Third-party integrations, partnerships
- **Team dependencies:** Design handoff, data pipeline work

**Example:**

```markdown

• Design: Wireframes for checklist UI (ETA: Week 1)
• Engineering: No technical dependencies (uses existing modals framework)

• Risk: Users dismiss checklist immediately, never see it
  • Mitigation: Track dismissal rate; if >50%, iterate on messaging or timing
• Risk: Checklist steps are too generic, don't resonate with all personas
  • Mitigation: Start with primary persona (Solo Entrepreneur Sam), personalize later

**3. Document Open Questions**
- **Unresolved decisions:** Areas requiring discovery or discussion

**Example:**

```markdown

• Should checklist be mandatory or optional? (Decision: Optional, dismissible)
• Should we A/B test checklist vs. no checklist? (Decision: Yes, show to 50% of new users)
• What happens if user completes steps out of order? (Decision: Allow any order, update checklist dynamically)

undefined

• Out of scope: What we're NOT building
• Dependencies: What we need before starting
• Risks: Potential blockers and mitigations
• Open questions: Unresolved decisions

Day 1:
├─ Phase 1: Executive Summary (30 min)
├─ Phase 2: Problem Statement (60 min)
│  └─ Use: skills/problem-statement/SKILL.md
├─ Phase 3: Target Users & Personas (30 min)
│  └─ Use: skills/proto-persona/SKILL.md
└─ Phase 4: Strategic Context (45 min)
   └─ Use: skills/tam-sam-som-calculator/SKILL.md (optional)

Day 2:
├─ Phase 5: Solution Overview (60 min)
│  └─ Use: skills/user-story-mapping-workshop/SKILL.md (optional)
├─ Phase 6: Success Metrics (30 min)
└─ Phase 7: User Stories & Requirements (90-120 min)
   ├─ Use: skills/epic-hypothesis/SKILL.md
   ├─ Use: skills/epic-breakdown-advisor/SKILL.md
   └─ Use: skills/user-story/SKILL.md

Day 3:
├─ Phase 8: Out of Scope & Dependencies (30 min)
└─ Review & Refine (60 min)
   └─ Read full PRD, polish, get feedback

Day 4 (Optional):
└─ Stakeholder Review & Approval
   └─ Present PRD to stakeholders, incorporate feedback

• Fast track: 1.5-2 days (straightforward feature, clear requirements)
• Typical: 2-3 days (includes discovery synthesis, stakeholder review)
• Complex: 3-4 days (major initiative, multiple personas, extensive user stories)

• 60% of trial users drop off in first 24 hours

• Activation rate: 40% → 60%

undefined

• skills/problem-statement/SKILL.md

  (component)

• skills/problem-framing-canvas/SKILL.md

  (interactive, for context)

• skills/customer-journey-mapping-workshop/SKILL.md

  (interactive, optional)

• skills/proto-persona/SKILL.md

  (component)

• skills/jobs-to-be-done/SKILL.md

  (component, optional)

• skills/tam-sam-som-calculator/SKILL.md

  (interactive, optional)

• skills/user-story-mapping-workshop/SKILL.md

  (interactive, optional)

• skills/epic-hypothesis/SKILL.md

  (component)

• skills/epic-breakdown-advisor/SKILL.md

  (interactive)

• skills/user-story/SKILL.md

  (component)

• Martin Eriksson, "How to Write a Good PRD" (2012) — PRD structure
• Marty Cagan, Inspired (2017) — Product spec principles
• Amazon, "Working Backwards" (PR/FAQ format) — Alternative to PRD

• [If Dean has PRD templates, link here]

prd-development.md

/skills/workflows/