notque/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.
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 | Failure Mode | |-----------|-----------|-------------| | 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 |

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.