Product

Product Planning & Documentation

Guide founders from product idea through PRD, roadmap, and user stories to execution-ready specifications.

Workflow

1. Diagnose Current Need

Ask: "What product documentation do you need?"

2. Write the PRD

A PRD articulates the "what" and "why"—not the "how." Engineering and design determine solutions.

Lenny Rachitsky's Three-Step Framework:

1. Crystallize the problem you're solving
2. Align on the problem with team/stakeholders
3. Keep referring back to the problem throughout

PRD Structure (Kevin Yien/Square Template):

See references/prd-templates.md for complete templates.

Core Sections:

Problem Statement Template:

[Target user] struggles with [problem] because [root cause].
We believe [solution approach] will work because [evidence/insight].

Critical Rules:

• Don't continue past Problem Alignment until ALL contributors are aligned
• Keep it to one page if possible (Paul Adams/Intercom: "The longer the doc, the less it gets read")
• Link out to detailed specs, don't embed everything
• Define Non-Goals as clearly as Goals—this prevents scope creep

PRD Quality Checklist:

• Problem is clear in 1-2 sentences
• Evidence/customer insights support the problem
• Goals are specific and measurable
• Non-goals explicitly defined
• Success criteria are testable
• All contributors have signed off on problem before solution

3. Build the Roadmap

Roadmaps communicate strategy and vision—they are NOT execution plans.

Kevin Yien's Roadmapping Maxims:

• Don't think about what to build WHILE making the roadmap
• Focus on "high conviction big bets," not 25 small items
• Build roadmap AFTER you identify OKRs, not before
• Have specific target numbers, not "low/medium/high impact"
• Build in wiggle room—roadmap items should drive 110%+ of OKR

See references/roadmap-prioritization.md for framework details.

Prioritization Framework Selection:

RICE Scoring (Intercom Method):

Formula: RICE Score = (Reach × Impact × Confidence) ÷ Effort

MoSCoW Definitions:

• Must-Have: Product literally won't work without it. Non-negotiable.
• Should-Have: Important but not critical. Can ship without temporarily.
• Could-Have: Nice to have. Build if time permits.
• Won't-Have: Explicitly out of scope. May reconsider later.

Roadmap Format Options:

• Now/Next/Later: Good for early stage, avoids false precision on dates
• Quarterly: Standard for growth stage, ties to OKRs
• Timeline: Visual Gantt-style, good for stakeholder communication

4. Write User Stories

User stories capture requirements from the user's perspective, enabling conversation between product and engineering.

Standard Format:

As a [user type],
I want [action/goal],
So that [benefit/outcome].

The 3 C's (Ron Jeffries):

1. Card: The written story—brief placeholder for conversation
2. Conversation: Discussion that reveals details and context
3. Confirmation: Acceptance criteria that define "done"

See references/user-stories.md for complete framework.

INVEST Criteria (Bill Wake):

Every good user story should be:

Writing Acceptance Criteria:

Use Given/When/Then format (BDD style):

Given [precondition/context],
When [action is taken],
Then [expected result].

Example:

User Story:
As a customer, I want to filter products by price range
so that I can find items within my budget.

Acceptance Criteria:
- Given I am on the product listing page
- When I set min price to $50 and max price to $100
- Then only products priced between $50-$100 are displayed
- And the filter values persist when I navigate back
- And I can clear filters to see all products again

Story Splitting Techniques:

When stories are too big, split by:

• Workflow steps: Registration → Onboarding → First action
• Business rules: Happy path → Edge cases → Error handling
• Data types: Text → Images → Video
• Operations: Create → Read → Update → Delete
• User types: Admin → Power user → Basic user
• Platforms: Web → Mobile → API

Common Story Smells:

• Too many acceptance criteria (>5-7) → Split the story
• Technical tasks disguised as stories → Reframe around user value
• "And" in the middle → Probably multiple stories
• Can't demo to stakeholder → Not valuable enough

5. Product Vision Document

For communicating product strategy to investors, board, or new team members.

One-Page Product Vision:

## [Product Name] Vision

**Mission:** [One sentence—why the product exists]

**Target User:** [Specific persona with key characteristics]

**Problem:** [The pain point in user's words]

**Solution:** [How we solve it differently]

**Key Value Proposition:** [Why users choose us over alternatives]

**North Star Metric:** [Single metric that captures value delivery]

**Current State:**
- Users: [Number]
- Key metric: [Value]
- Stage: [MVP/Growth/Scale]

**12-Month Vision:**
[What the product looks like in a year—paint the picture]

**Key Bets:**
1. [Bet 1]: [Hypothesis and expected outcome]
2. [Bet 2]: [Hypothesis and expected outcome]
3. [Bet 3]: [Hypothesis and expected outcome]

Deliverables

1. PRD Document

Create using docx skill with structure from references/prd-templates.md:

• Problem Alignment section with evidence
• Goals and Non-Goals
• Key Features (prioritized)
• Key Flows (visual or written)
• Key Logic (edge cases, business rules)
• Launch Plan with milestones
• Operational checklist
• Changelog for updates

2. Prioritized Roadmap

Create using xlsx skill:

• Feature/initiative list with descriptions
• RICE scores (or chosen framework scores)
• Priority ranking
• Time horizon (Now/Next/Later or quarters)
• Dependencies flagged
• Owner assigned

3. User Stories with Acceptance Criteria

Format options:

• Markdown file organized by epic
• Spreadsheet with columns: ID, Story, Acceptance Criteria, Priority, Estimate
• Individual story cards

Each story includes:

• User story in standard format
• 3-7 acceptance criteria in Given/When/Then
• Priority (MoSCoW or numerical)
• Estimate (story points or t-shirt size)

4. Product Vision One-Pager

Create using docx or markdown:

• Mission statement
• Target user profile
• Problem/solution summary
• North star metric
• Current state snapshot
• 12-month vision narrative
• Key strategic bets

Anti-Patterns to Avoid

PRD Mistakes:

• Writing the solution before aligning on the problem
• PRD becomes 20+ pages nobody reads
• No explicit Non-Goals (leads to scope creep)
• Skipping stakeholder alignment signatures
• Treating PRD as static (it's a living document)

Roadmap Mistakes:

• Using roadmap as execution plan (too granular)
• Committing to specific dates too early
• No clear prioritization framework
• Building what's loudest, not most valuable
• Roadmap doesn't connect to OKRs/strategy

User Story Mistakes:

• Stories written by PM in isolation (no conversation)
• Technical tasks instead of user value
• Vague acceptance criteria ("works correctly")
• Stories too large to complete in sprint
• Missing the "so that" (the why)

Reference Files

• references/prd-templates.md — Kevin Yien, Lenny, Intercom templates with examples
• references/roadmap-prioritization.md — RICE, MoSCoW, and other frameworks in detail
• references/user-stories.md — INVEST criteria, story splitting, acceptance criteria patterns

Integration with Other Skills

• Use idea-validation skill first if problem not validated
• Use business-model skill for pricing/monetization sections
• Use fundraising skill for investor-facing product narrative
• Use docx skill for PRD document creation
• Use xlsx skill for roadmap spreadsheets
• Use pptx skill for product review presentations

Adapted from Linas Beliūnas's The One-Person Unicorn founder skill set.