Product Management

When to Use

• Building or updating a product roadmap
• Prioritizing a backlog of features or initiatives
• Writing a product requirements document (PRD) or product spec
• Creating user stories with clear acceptance criteria
• Planning milestones, sprints, or quarterly product goals
• Evaluating inbound feature requests from customers or stakeholders
• Making build vs buy decisions for product components
• Auditing an existing roadmap for focus, alignment, or missing rationale
• Communicating product plans to engineering, design, or leadership

Prioritization Frameworks

RICE Scoring

Score each initiative on four dimensions:

RICE Score = (Reach × Impact × Confidence) / Effort

Example:

ICE Scoring (Lightweight Alternative)

ICE Score = Impact × Confidence × Ease

Best for quick triage when you don't have detailed reach data.

MoSCoW Method

Categorize rather than score:

Value vs Effort Matrix

For visual prioritization:

         High Value
              │
    Quick     │    Big Bets
    Wins ★    │    (plan carefully)
              │
──────────────┼──────────────
              │
    Fill-ins  │    Money Pit
    (maybe)   │    (avoid)
              │
         Low Value

    Low Effort ←──────→ High Effort

• Quick wins (high value, low effort): Do these first
• Big bets (high value, high effort): Plan, resource, and schedule these
• Fill-ins (low value, low effort): Only when nothing else is available
• Money pit (low value, high effort): Decline or defer indefinitely

Roadmapping

Roadmap Types

Now / Next / Later

The simplest and most honest roadmap format:

Roadmap Principles

• Outcomes over outputs: Frame roadmap items as problems to solve, not features to build
• No fixed dates without scope trade-offs: If the date is fixed, scope must flex (and vice versa)
• Theme by strategic goal: Group roadmap items under 3-5 strategic themes (growth, retention, platform, etc.)
• Exclude the backlog: A roadmap is not a project list; only include items with intentional prioritization
• Review monthly: Remove completed items, re-evaluate priorities, add new learnings

Roadmap Anti-patterns

• Feature factory: Shipping features without connecting them to business outcomes
• Date-driven: Every item has a deadline with no scope flexibility
• Stakeholder-driven: Roadmap determined by who yells loudest, not by data
• No pruning: Items stay on the roadmap for years without review
• Everything is P0: No real prioritization — everything is "critical"

Product Specification (PRD)

PRD Template

# [Feature Name]

## Meta
- **Author**: [Name]
- **Status**: Draft / In Review / Approved
- **Target release**: [Quarter or milestone]
- **Last updated**: [Date]

## Problem Statement
[What problem does this solve? Who has this problem? How painful is it?
Include data: support tickets, user research, churn analysis.]

## Goal
[What outcome will this feature drive? Be specific and measurable.]

**Success metric**: [Primary metric this feature moves]
**Target**: [Quantified goal, e.g., "Reduce onboarding drop-off from 40% to 25%"]

## Non-Goals
[Explicitly state what this feature will NOT do. Prevents scope creep.]

- Not building [X]
- Not supporting [Y] in this iteration
- Not optimizing for [Z] persona

## User Stories

### Story 1: [Persona] [action]
**As a** [persona],
**I want to** [action],
**So that** [outcome].

**Acceptance criteria**:
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]

### Story 2: [Persona] [action]
[Same format]

## Design
[Link to designs, wireframes, or mockups.
Include key interaction flows and edge cases.]

## Technical Approach
[High-level technical direction agreed with engineering.
Not a full design doc — enough to unblock estimation.]

- Approach: [Brief description]
- Key dependencies: [APIs, services, libraries]
- Data model changes: [New tables, schema changes]
- Migration needed: [Yes/No — if yes, link to migration plan]

## Edge Cases
| Scenario | Expected behavior |
|----------|------------------|
| [Edge case 1] | [What happens] |
| [Edge case 2] | [What happens] |
| [Error condition] | [How the system responds] |

## Open Questions
- [ ] [Unresolved question 1]
- [ ] [Unresolved question 2]

## Rollout Plan
| Phase | Audience | Duration | Success criteria |
|-------|----------|----------|-----------------|
| Internal dogfood | Team | 1 week | No critical bugs |
| Beta | 10% of users | 2 weeks | [Metric threshold] |
| GA | All users | — | [Metric threshold] |

## Dependencies
| Dependency | Owner | Status | Blocking? |
|-----------|-------|--------|-----------|
| [API change] | [Team] | [Status] | Yes/No |

Writing Good User Stories

Acceptance Criteria Rules

• Write as Given / When / Then or checklist format
• Each criterion must be independently verifiable
• Include happy path AND edge cases
• Specify error states and messages
• Define performance expectations if relevant (e.g., "loads in <2s")
• NO implementation details — describe what, not how

Feature Request Evaluation

When a feature request comes in (from customers, sales, or stakeholders):

Decision: Build / Defer / Decline

Product Audit Checklist

When reviewing an existing product roadmap or spec:

• Is every roadmap item tied to a measurable business outcome?
• Is there a prioritization framework applied (not just gut feeling)?
• Are non-goals explicitly stated in specs?
• Do user stories have acceptance criteria that QA can test independently?
• Is the roadmap reviewed and pruned at least monthly?
• Are feature requests evaluated against strategic themes before committing?
• Is scope separated from timeline (fixed date = flexible scope)?
• Are edge cases and error states documented in specs?
• Is there a rollout plan with phased rollout, not big-bang release?
• Is the roadmap communicated in a format appropriate for each audience?

Output Format

When delivering product management artifacts, structure the output as:

1. Context: Product area, strategic theme, and current state
2. Prioritized list: Initiatives scored and ranked with chosen framework
3. Roadmap: Now/Next/Later or timeline view with rationale
4. Spec (if applicable): Full PRD following the template
5. Risks and dependencies: What could block delivery
6. Success metrics: How to measure whether this worked