product-management

name	product-management
description	Product management workflows — feature specs, roadmap planning, stakeholder updates, user research synthesis, competitive analysis, metrics review, sprint planning. Use when writing specs, updating roadmaps, briefing stakeholders, synthesizing research, or reviewing product metrics.
routing	{"triggers":["product management","feature spec","PRD","roadmap","stakeholder update","user research","sprint planning","product metrics"],"category":"business","force_route":false,"pairs_with":[]}
user-invocable	true

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.
3. Thematic analysis:
   • Familiarize -> Initial coding -> Theme development -> Theme review -> Theme refinement -> Report
   • Affinity mapping: one observation per note, let clusters emerge, split large clusters.
   • Triangulation: methodological, source, temporal. Findings supported by multiple sources are stronger.
4. Priority matrix:

	High Impact	Low Impact
High Frequency	Top priority	Quality-of-life
Low Frequency	Segment-specific	Note and deprioritize

5. Generate synthesis: Research overview, 5-8 key findings (with evidence, frequency, impact, confidence), user segments/personas, opportunity areas, actionable recommendations, open questions.

Critical rule: Distinguish behaviors from stated preferences. Behavioral data always outweighs what users say they want. Quote attribution uses participant type ("Enterprise admin, 200-person team"), never names.

COMPETITIVE Mode

1. Scope — Which competitor(s)? Full comparison or specific area? What decision does this inform?
2. Research — Product pages, pricing, changelogs, customer reviews (G2, Capterra), job postings (strategic signals), community discussions.
3. Generate brief:
   • Competitor overview (company, positioning, momentum)
   • Feature comparison matrix (Strong/Adequate/Weak/Absent ratings)
   • Positioning analysis (For [target] who [need], [Product] is a [category] that [benefit])
   • Honest strengths and weaknesses
   • Opportunities and threats
   • Strategic implications: build/accelerate/deprioritize, differentiate vs parity, positioning adjustments
4. Competitive set levels: Direct (same problem, same way), Indirect (same problem, different way), Adjacent (could expand into your space), Substitute (entirely different approach including "do nothing").

Honesty rule: Dismissing competitors makes analysis useless. Rate based on real product experience and customer feedback, not marketing claims. Be honest about where competitors lead.

Gate: Competitive brief exists with feature matrix, positioning analysis, and strategic implications. At least one honest "they lead here" finding present.

METRICS Mode

Load: references/metrics-review.md, references/llm-pm-failure-modes.md

1. Gather data — Get metrics with comparison data (previous period, targets). Ask about known events (launches, incidents, seasonality).
2. Organize — Use metrics hierarchy:

Level	Purpose	Examples
North Star	Core value delivered	WAU completing core workflow
L1 (Health)	Lifecycle stages	Acquisition, Activation, Engagement, Retention, Monetization, Satisfaction
L2 (Diagnostic)	Drill-down	Funnel steps, feature adoption, segment breakdowns, performance

3. Analyze — For each metric: current value, trend, vs target, rate of change, anomalies. Identify correlations, leading indicators, segment-driven aggregate trends.
4. Generate review: Summary (2-3 sentences), scorecard table, trend analysis, bright spots, areas of concern, recommended actions, caveats.
5. Goal-setting support: OKRs (2-3 objectives, 2-4 KRs each, outcomes not outputs, 70% completion = target for stretch). Target-setting: baseline -> benchmark -> trajectory -> effort -> confidence.

Context rule: Absolute numbers without comparison are useless. Always show vs previous period, vs target, vs benchmark. Small fluctuations are noise — focus on meaningful changes.

SPRINT Mode

1. Gather: Team roster + availability, sprint length, prioritized backlog, carryover, dependencies.
2. Capacity calculation: Available days minus overhead (meetings, on-call, PTO). Rule of thumb: 60-70% of time on planned work.
3. Allocation: 70% planned features, 20% tech health, 10% unplanned buffer.
4. Generate sprint plan:
   • Sprint goal (one sentence)
   • Capacity table (person, available days, allocation, notes)
   • Sprint backlog (P0 must-ship, P1 should-ship, P2 stretch)
   • Planned capacity vs sprint load (target 70-80%)
   • Risks with impact and mitigation
   • Definition of done
   • Key dates (start, mid-sprint check, demo, retro)
5. Carry over honestly — If something did not ship, understand why before re-committing.

Gate: Sprint plan exists with goal, capacity table, prioritized backlog, and load vs capacity check showing 70-80% target.

BRAINSTORM Mode (Socratic)

This mode is fundamentally different. The PM does not get a deliverable. They get a thinking partner. Be opinionated. Push back. Bring unexpected angles. Challenge assumptions.

Session principles:

• Apply frameworks to the specific problem at hand
• Generate, evaluate, then discuss before handing over
• Challenge ideas actively — push back with reasons
• Hold divergent exploration open before converging
• Explore multiple directions before committing

Sub-modes — Detect which fits and shift as conversation evolves:

Sub-mode	When	Approach
Problem Exploration	PM has a problem area, not a defined problem	Ask "who has this problem?" and "what are they doing today?" Map the ecosystem. Distinguish symptoms from root causes.
Solution Ideation	Problem is well-defined, need options	Generate 5-7 distinct approaches before evaluating. Include one "do the opposite" and one "remove something." Resist early convergence.
Assumption Testing	PM has a direction, needs stress-testing	List every assumption (stated + unstated). Find the riskiest one. Suggest the cheapest test. Play devil's advocate.
Strategy Exploration	Big bets, positioning, direction	Map possible moves. Think in bets (odds, payoff). Consider second-order effects and competitive responses.

Session rhythm: Frame -> Diverge -> Provoke -> Converge -> Capture.

Ideation techniques:

• Constraint removal: "What if no technical/budget/political constraints?"
• Analogies: "How does [another industry] solve this?"
• Inversion: "How would we make this worse?" Then reverse.
• Decomposition: Break into subproblems, solve independently, recombine.
• User hat-switching: Power user? New user? Admin? Someone who hates the product?

Frameworks as thinking tools (use when they help, not as templates):

Framework	Structure	Anti-pattern
HMW	"How might we [outcome] for [user] without [constraint]?"	Too broad ("improve onboarding") or too narrow ("add tooltip to step 3")
JTBD	"When [situation], I want to [motivation] so I can [outcome]."	Functional jobs are easy; emotional and social jobs are often more powerful. Ask "what did they fire?"
Opportunity Solution Tree	Outcome -> Opportunities (from research) -> Solutions (multiple per opportunity) -> Experiments (cheapest test)	Opportunities must trace to evidence, not imagination. One solution per opportunity = not enough exploration.
First Principles	State assumption -> Break to fundamentals -> Question each -> Rebuild	Use when team is stuck in incrementalism
OODA	Observe -> Orient -> Decide -> Act -> loop	Most teams get stuck in Orient. OODA says: orient with what you have, act, let next cycle correct.
Reverse Brainstorming	"How to make this worse?" -> List -> Reverse each	When team is stuck; people are better at identifying wrong than imagining right.

Provocation prompts:

• "What is the strongest argument against this?"
• "Who would hate this and why?"
• "What are we not seeing?"
• "What if the opposite were true?"
• "What is the 10x more ambitious version?"

Gate: Session produced at least one challenge the PM hadn't considered. Captured decisions/next-steps documented. Frameworks used as thinking tools, not dumped as checklists.

---

LLM Failure Modes in PM Work

See references/llm-pm-failure-modes.md for the complete failure mode catalog (vague specs, fabricated research, generic competitive analysis, metrics without context, happy-path-only specs, framework regurgitation, scope creep enablement). Universal failure modes in skills/shared-patterns/llm-domain-failure-modes-base.md.

---

Prioritization Frameworks (Cross-Mode Reference)

Used in SPEC, ROADMAP, and SPRINT modes.

Framework	Formula / Method	Best For
RICE	(Reach x Impact x Confidence) / Effort	Large backlog, quantitative comparison
ICE	Impact x Confidence x Ease (1-10 each)	Quick prioritization, early-stage
MoSCoW	Must / Should / Could / Won't	Scoping a release, forcing prioritization conversations
Value vs Effort	2x2 matrix: Quick Wins, Big Bets, Fill-ins, Money Pits	Visual prioritization in team sessions

Anti-pattern: Using a framework as a rubber stamp for a decision already made. If the RICE score does not match intuition, investigate why — do not just adjust the inputs until it does.

---

Output Conventions

• Markdown with clear headers. Scannable. Busy stakeholders read headers and bold text.
• Tables for comparisons, scorecards, feature matrices.
• Status labels: Done, On Track, At Risk, Blocked, Not Started.
• Executive content: < 300 words. Engineering content: as detailed as needed.
• Every recommendation is specific enough to act on. "Improve onboarding" is not actionable. "Add progress indicator to setup flow" is.