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.

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:

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:

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:

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:

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:

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:

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

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.

Failure modes: 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.