Prd Development

PRD Structure (Standard Template)

# [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
• 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 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 for the full fill-in structure.

This workflow orchestrates 8 phases over 2-4 days, using multiple component and interactive skills.

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. Problem Statement

### Who has this problem?
Non-technical small business owners (solopreneurs, 1-10 employees) who sign up for our SaaS product.

### What is the problem?
60% of users abandon onboarding within the first 24 hours because they don't know what to do first. They see an empty dashboard with no guidance, get overwhelmed by options, and leave.

### Why is it painful?
- **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

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

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:

## 3. Target Users & Personas

### Primary Persona: Solo Entrepreneur Sam
- **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

### Secondary Persona: Small Business Owner (5-10 employees)
- **Role:** Owner-operator, manages team
- **Needs:** Onboard team members quickly
- **Differs from primary:** More tolerant of complexity, willing to invest setup time

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:

## 5. Solution Overview

We're building a **guided onboarding checklist** that walks new users through core workflows step-by-step when they first log in.

**How it works:**
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."

**Key features:**
- 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

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:

## 6. Success Metrics

### Primary Metric
**Activation rate** (% of users completing first action within 24 hours)
- **Current:** 40%
- **Target:** 60%
- **Timeline:** Measure 30 days after launch

### Secondary Metrics
- **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

### Guardrail Metrics
- **Sign-up conversion rate:** Maintain at 10% (don't add friction to signup)

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:

## 7. User Stories & Requirements

### Epic Hypothesis
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.

### User Stories

**Story 1: Display onboarding checklist on first login**
As a new user, I want to see a guided checklist when I first log in, so I know what to do first.

**Acceptance Criteria:**
- [ ] 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)

**Story 2: Track checklist progress**
As a new user, I want to see my progress as I complete checklist steps, so I feel a sense of accomplishment.

**Acceptance Criteria:**
- [ ] 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)

**Story 3: Celebrate checklist completion**
As a new user, I want to receive positive feedback when I complete the checklist, so I feel confident using the product.

**Acceptance Criteria:**
- [ ] 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?

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:

## 8. Out of Scope

**Not included in this release:**
- **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

**Future consideration:**
- 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:

## 9. Dependencies & Risks

### Dependencies
- **Design:** Wireframes for checklist UI (ETA: Week 1)
- **Engineering:** No technical dependencies (uses existing modals framework)

### Risks & Mitigations
- **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:

## 10. Open Questions

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

Outputs from Phase 8

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

Complete Workflow: End-to-End Summary

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

Total Time Investment:

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

Examples

See examples/sample.md for full PRD examples.

Mini example excerpt:

## 2. Problem Statement
- 60% of trial users drop off in first 24 hours
## 6. Success Metrics
- Activation rate: 40% → 60%

Common Pitfalls

Pitfall 1: PRD Written in Isolation

Symptom: PM writes PRD alone, presents finished doc to team

Consequence: No buy-in, team doesn't understand rationale

Fix: Collaborate on Phase 7 (user stories) with design + eng; review draft PRD before finalizing

Pitfall 2: No Evidence in Problem Statement

Symptom: "We believe users have this problem" (no data, no quotes)

Consequence: Team questions whether problem is real

Fix: Use discovery insights from skills/discovery-process/SKILL.md; include customer quotes, analytics, support tickets

Pitfall 3: Solution Too Prescriptive

Symptom: PRD specifies exact UI, pixel dimensions, button colors

Consequence: Removes design collaboration, becomes waterfall spec

Fix: Keep Phase 5 high-level; let design own UI details

Pitfall 4: No Success Metrics

Symptom: PRD defines problem + solution but no metrics

Consequence: Can't validate if feature succeeded

Fix: Always define primary metric in Phase 6 (what you're optimizing for)

Pitfall 5: Out of Scope Not Documented

Symptom: No section on what's NOT being built

Consequence: Scope creep, stakeholders expect features not planned

Fix: Explicitly document out of scope in Phase 8

References

Related Skills (Orchestrated by This Workflow)

Phase 2:

• skills/problem-statement/SKILL.md (component)
• skills/problem-framing-canvas/SKILL.md (interactive, for context)
• skills/customer-journey-mapping-workshop/SKILL.md (interactive, optional)

Phase 3:

• skills/proto-persona/SKILL.md (component)
• skills/jobs-to-be-done/SKILL.md (component, optional)

Phase 4:

• skills/tam-sam-som-calculator/SKILL.md (interactive, optional)

Phase 5:

• skills/user-story-mapping-workshop/SKILL.md (interactive, optional)

Phase 7:

• skills/epic-hypothesis/SKILL.md (component)
• skills/epic-breakdown-advisor/SKILL.md (interactive)
• skills/user-story/SKILL.md (component)

External Frameworks

• 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

Dean's Work

• [If Dean has PRD templates, link here]

Skill type: Workflow Suggested filename: prd-development.md Suggested placement: /skills/workflows/ Dependencies: Orchestrates 8+ component and interactive skills across 8 phases