product-management

# Product Management

Umbrella skill for PM workflows: specs, roadmaps, stakeholder comms, research synthesis, competitive analysis, metrics review, sprint planning, and product brainstorming. Each mode loads its own reference files on demand.

---

## Mode Detection

Classify into one mode before proceeding.

| Mode | Signal Phrases | Reference |
|------|---------------|-----------|
| **SPEC** | write spec, PRD, feature requirements, acceptance criteria, user stories | `references/spec-writing.md` |
| **ROADMAP** | roadmap, prioritize, Now/Next/Later, reprioritize, timeline, OKR alignment | `references/roadmap-planning.md` |
| **STAKEHOLDER** | stakeholder update, status report, executive brief, launch announcement | (inline templates) |
| **RESEARCH** | synthesize research, interview analysis, user feedback, personas, thematic analysis | `references/research-synthesis.md` |
| **COMPETITIVE** | competitive brief, competitor analysis, battle card, positioning, win/loss | (inline templates) |
| **METRICS** | metrics review, KPI, funnel analysis, retention, cohort, dashboard, OKR scoring | `references/metrics-review.md` |
| **SPRINT** | sprint planning, backlog grooming, capacity, sprint goal, carryover | (inline templates) |
| **BRAINSTORM** | brainstorm, explore problem, stress-test idea, thinking partner, assumption testing | (Socratic — see below) |

If the request spans modes, pick the primary mode and note the secondary.

---

## Workflow by Mode

### SPEC Mode

**Load**: `references/spec-writing.md`, `references/llm-pm-failure-modes.md`

1. **Understand** — Accept any input: feature name, problem statement, user request, vague idea.
2. **Gather context** — Ask conversationally (not a wall of questions):
   - User problem and who experiences it
   - Target users / segments
   - Success metrics (how will we know it worked?)
   - Constraints: technical, timeline, regulatory, dependencies
   - Prior art: attempted before? Existing solutions?
3. **Generate PRD** with these sections:

| Section | Content |
|---------|---------|
| Problem Statement | 2-3 sentences. Who, how often, cost of not solving. Grounded in evidence. |
| Goals | 3-5 measurable outcomes. Outcomes not outputs. |
| Non-Goals | 3-5 explicit exclusions with rationale. |
| User Stories | "As a [specific type], I want [capability] so that [benefit]." Group by persona. Include edge cases. |
| Requirements | P0 (must-have), P1 (nice-to-have), P2 (future). Each with acceptance criteria. |
| Success Metrics | Leading (days-weeks) and lagging (weeks-months). Specific targets with measurement method. |
| Open Questions | Tagged by owner (eng, design, legal, data). Blocking vs non-blocking. |
| Timeline | Hard deadlines, dependencies, phasing. |

4. **Review** — Offer iteration, expansion, follow-up artifacts (design brief, ticket breakdown).

**Acceptance criteria format**: Given/When/Then or checklist. Cover happy path, error cases, edge cases. No ambiguous words ("fast", "intuitive") without concrete definitions.

**Scope management**: Write explicit non-goals. Any scope addition requires a scope removal or timeline extension. Separate v1 from v2. Time-box investigations.

### ROADMAP Mode

**Load**: `references/roadmap-planning.md`, `references/llm-pm-failure-modes.md`

1. **Current state** — Get existing roadmap (paste, describe, or build from scratch).
2. **Determine operation**:

| Operation | Inputs | Key Actions |
|-----------|--------|-------------|
| Add item | Name, priority, effort, timeframe, owner, dependencies | Suggest placement based on priorities and capacity |
| Update status | Item + new status (not started / in progress / at risk / blocked / completed / cut) | For at-risk/blocked: require blocker + mitigation |
| Reprioritize | What changed (strategy shift, new data, resource change) | Apply framework (RICE, ICE, MoSCoW, Value/Effort). Show before/after. |
| Move timeline | Why (scope change, dependency slip, resource constraint) | Identify downstream impacts. Flag hard-deadline conflicts. |
| Create new | Timeframe, format preference, initiative list | Use Now/Next/Later unless user specifies otherwise |

3. **Generate** — Status overview, items grouped by timeframe/theme, risks/dependencies, change summary.
4. **Follow up** — Offer audience-specific formatting, change communication drafts.

**Capacity rule**: When adding to roadmap, always ask "What comes off?" Roadmaps are zero-sum against capacity.

### STAKEHOLDER Mode

1. **Update type**: Weekly / Monthly / Launch / Ad-hoc
2. **Audience detection**:

| Audience | Frame | Length |
|----------|-------|--------|
| Executives | Outcome-focused, G/Y/R status, strategic alignment | < 300 words |
| Engineering | Technical detail, links to PRs/tickets, decisions needed with options | As needed |
| Cross-functional | Impact on their team, asks with deadlines, input opportunities | Medium |
| Customers | Benefits-focused, no jargon, honest timelines | Short |
| Board | Metrics-driven, risk-focused, strategic | Very concise |

3. **Generate** using audience-appropriate template.
4. **Risk communication** — Use ROAM framework (Resolved, Owned, Accepted, Mitigated). Every risk comes with: clear statement, quantified impact, likelihood with evidence, mitigation plan, specific ask.

**Executive update rule**: Lead with conclusion, not journey. "We shipped X and it moved Y" not "we had 14 standups." Status color reflects reality, not optimism.

**Gate**: Update draft exists. Audience-appropriate framing verified (no engineering jargon in exec updates, no hand-waving in engineering updates). Every risk has a ROAM classification.

### RESEARCH Mode

**Load**: `references/research-synthesis.md`, `references/llm-pm-failure-modes.md`

1. **Gather inputs** — Accept any combination: pasted text, uploaded files, described findings.
2. **Process** — For each source extract: observations, verbatim quotes, behaviors (vs stated preferences), pain points, positive signals, context