Agent Skills › deanpeters/Product-Manager-Skills

deanpeters/Product-Manager-Skills

GitHub

评估获客渠道的财务可行性,基于单位经济、客户质量和可扩展性,辅助决定扩展、测试或终止渠道。

55 个 Skill 5,576

安装全部 Skills

npx skills add deanpeters/Product-Manager-Skills --all -g -y
更多选项

预览集合内 Skills

npx skills add deanpeters/Product-Manager-Skills --list

集合内 Skills (55)

评估获客渠道的财务可行性,基于单位经济、客户质量和可扩展性,辅助决定扩展、测试或终止渠道。
评估特定获客渠道(如付费搜索、SDR)的投入产出比 决定是否扩大、测试或停止某个增长渠道 优化营销预算分配
skills/acquisition-channel-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill acquisition-channel-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "acquisition-channel-advisor",
    "type": "interactive",
    "intent": "Guide product managers through evaluating whether to scale, test, or kill an acquisition channel based on unit economics (CAC, LTV, payback), customer quality (retention, NRR), and scalability (magic number, volume potential). Use this to make data-driven go-to-market decisions and optimize channel mix for sustainable growth.",
    "best_for": [
        "Deciding whether a paid or outbound channel deserves more budget",
        "Comparing channel quality, payback, and scalability side by side",
        "Making scale, test, or kill decisions with finance-backed reasoning"
    ],
    "scenarios": [
        "Should we keep investing in paid LinkedIn ads for enterprise leads?",
        "Compare content marketing, outbound email, and partner referrals as acquisition channels",
        "Help me decide whether to scale or kill our webinar acquisition channel"
    ],
    "description": "Evaluate acquisition channels using unit economics, customer quality, and scalability. Use when deciding whether to scale, test, or kill a growth channel.",
    "argument-hint": "[channel to evaluate]"
}

Purpose

Guide product managers through evaluating whether to scale, test, or kill an acquisition channel based on unit economics (CAC, LTV, payback), customer quality (retention, NRR), and scalability (magic number, volume potential). Use this to make data-driven go-to-market decisions and optimize channel mix for sustainable growth.

This is not a channel strategy framework—it's a financial lens for channel evaluation that helps you avoid scaling unprofitable channels or killing channels with fixable problems. Use when deciding how to allocate marketing budget across channels.

Input

Works best with: The acquisition channel you're evaluating (e.g., paid search, outbound SDR, partner referrals). Also useful: Any metrics you already have — CAC, LTV, payback period, retention/NRR by channel — plus company stage and the decision on the table (scale, test, or kill).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking which channel you're evaluating and what data you have.

Example invocation: Evaluate our paid LinkedIn channel: CAC $2,400, LTV $9,000, 14-month payback, flat retention vs. organic.

Key Concepts

The Channel Evaluation Framework

A systematic approach to evaluate acquisition channels:

  1. Unit Economics — What does it cost to acquire, and what's the return?

    • CAC (Customer Acquisition Cost)
    • LTV (Lifetime Value)
    • LTV:CAC ratio
    • Payback period
  2. Customer Quality — Do customers from this channel stick around and expand?

    • Cohort retention rate (by channel)
    • Churn rate (by channel)
    • NRR (Net Revenue Retention by channel)
    • Expansion rate
  3. Scalability — Can this channel sustain growth at the volume you need?

    • Magic Number (S&M efficiency)
    • Addressable volume (TAM of channel)
    • Saturation risk (diminishing returns)
    • CAC trend (increasing, stable, decreasing)
  4. Strategic Fit — Does this channel align with your go-to-market strategy?

    • Customer segment match (SMB vs. enterprise)
    • Sales motion compatibility (PLG vs. sales-led)
    • Brand positioning alignment

Decision Matrix

LTV:CAC Payback Customer Quality Scalability Decision
>3:1 <12mo Good retention High volume Scale aggressively
2-3:1 12-18mo Average retention Medium volume Test & optimize
<2:1 >18mo Poor retention Low volume Kill or fix

Anti-Patterns (What This Is NOT)

  • Not vanity metrics: "We got 10,000 signups!" means nothing if they churn in 30 days
  • Not CAC-only thinking: Low CAC with terrible retention is worse than high CAC with great retention
  • Not ignoring payback: 5:1 LTV:CAC with 36-month payback is a cash trap
  • Not scaling broken channels: Pouring money into inefficient channels accelerates failure

When to Use This Framework

Use this when:

  • Evaluating whether to scale a new channel (content, paid, events, etc.)
  • Deciding how to allocate marketing budget across channels
  • Assessing whether to kill an underperforming channel
  • Comparing channels to optimize ROI
  • Planning annual marketing budget allocation

Don't use this when:

  • Channel is brand-new (<3 months, <100 customers) — not enough data
  • You're testing channel fit (this is for evaluation, not experimentation)
  • Strategic channels (e.g., enterprises require field sales regardless of CAC)
  • You don't have channel-level data (need to track CAC, retention by source)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 4 adaptive questions, offering 3-5 enumerated options at decision points.


Step 0: Gather Context

Agent asks:

"Let's evaluate this acquisition channel. Please provide:

Channel details:

  • Channel name (e.g., Google Ads, content marketing, outbound sales, partnerships)
  • How long have you been using this channel? (months)
  • Current monthly spend on this channel

Customer acquisition:

  • Customers acquired per month (from this channel)
  • CAC for this channel (if known, otherwise we'll calculate)

Business context:

  • Blended CAC (across all channels)
  • Blended LTV
  • Current MRR/ARR
  • Target growth rate (% MoM or YoY)

You can provide estimates if you don't have exact numbers."


Step 1: Evaluate Unit Economics

Agent calculates (if not provided):

CAC = Monthly Spend / Customers Acquired per Month

Agent asks:

"Now let's compare this channel's unit economics to your blended metrics.

Channel Unit Economics:

  • Channel CAC: $___
  • Blended CAC (all channels): $___
  • Channel LTV: $___ (if known; otherwise we'll use blended LTV as proxy)
  • Blended LTV: $___

Questions:

  1. Do customers from this channel have similar LTV to other channels?

    • Similar (use blended LTV)
    • Higher (they upgrade more, stick around longer)
    • Lower (they churn faster or are smaller deals)
    • Unknown (need to analyze cohort data)
  2. What's the payback period for this channel?

    • We can calculate: CAC / (Monthly ARPU × Gross Margin %)
    • Or you can provide it"

Based on answers, agent calculates:

  • LTV:CAC ratio for channel
  • Payback period
  • Comparison to blended metrics

Agent flags:

  • ✅ If LTV:CAC >3:1 and payback <12 months: "Strong unit economics"
  • ⚠️ If LTV:CAC 2-3:1 or payback 12-18 months: "Marginal unit economics"
  • 🚨 If LTV:CAC <2:1 or payback >18 months: "Poor unit economics"

Step 2: Assess Customer Quality

Agent asks:

"How do customers from this channel perform compared to other channels?

Retention & Expansion:

  1. What's the churn rate for customers from this channel?

    • Lower than blended (they stick around longer)
    • Same as blended (no difference)
    • Higher than blended (they churn faster)
    • Unknown (need cohort analysis)
  2. What's the NRR for customers from this channel?

    • Higher than blended (they expand more)
    • Same as blended (no difference)
    • Lower than blended (they contract or churn more)
    • Unknown (need cohort analysis)
  3. What's the customer profile from this channel?

    • Ideal customer profile (ICP) — perfect fit
    • Close to ICP — mostly good fit
    • Off ICP — many poor-fit customers
    • Unknown"

Based on answers, agent evaluates:

  • High quality: Lower churn, higher NRR, ICP match
  • ⚠️ Medium quality: Similar to blended, mostly good fit
  • 🚨 Low quality: Higher churn, lower NRR, off ICP

Agent flags:

  • If high quality: "Premium channel—customers are better than average"
  • If low quality: "Quality problem—customers aren't sticking or expanding"

Step 3: Evaluate Scalability

Agent asks:

"Can this channel scale to meet your growth targets?

Efficiency & Volume:

  1. What's the S&M efficiency for this channel (Magic Number)?

    • Calculate: (New MRR from channel × 4) / Channel S&M Spend
    • Or provide if known
  2. What's the addressable volume for this channel?

    • Large (can scale 10x+ from current spend)
    • Medium (can scale 2-5x)
    • Small (near saturation, maybe 1.5x)
    • Unknown
  3. What's the CAC trend for this channel?

    • Decreasing (getting more efficient over time)
    • Stable (consistent CAC)
    • Increasing (diminishing returns, saturation)
    • Unknown (too early to tell)
  4. How much growth do you need from acquisition?

    • We'll calculate: Target growth - expansion/retention growth = acquisition gap"

Based on answers, agent evaluates:

  • Highly scalable: Magic number >0.75, large volume, stable/decreasing CAC
  • ⚠️ Moderately scalable: Magic number 0.5-0.75, medium volume, stable CAC
  • 🚨 Not scalable: Magic number <0.5, small volume, increasing CAC

Step 4: Deliver Recommendations

Agent synthesizes:

  • Unit economics (LTV:CAC, payback)
  • Customer quality (retention, NRR, ICP fit)
  • Scalability (magic number, volume, CAC trend)
  • Strategic fit

Agent offers 3-4 recommendations:


Recommendation Pattern 1: Scale Aggressively

When:

  • LTV:CAC >3:1 AND
  • Payback <12 months AND
  • Customer quality good or better AND
  • Magic Number >0.75 AND
  • Addressable volume large

Recommendation:

"Scale this channel aggressively — Excellent economics + scalability

Unit Economics:

  • CAC: $___
  • LTV: $___
  • LTV:CAC: ___:1 ✅ (>3:1 threshold)
  • Payback: ___ months ✅ (<12 months)

Customer Quality:

  • Retention: [Better than / Same as / Worse than] blended
  • NRR: [Higher / Same / Lower]
  • ICP Fit: [High / Medium / Low]

Scalability:

  • Magic Number: ___ ✅ (>0.75 = efficient)
  • Addressable Volume: Large
  • CAC Trend: [Stable / Decreasing]

Why this is a winner:

  • Every $1 spent returns $__ in LTV
  • Payback in under a year = fast cash recovery
  • [Customer quality insight]
  • Can scale 5-10x from current spend

How to scale:

  1. Increase budget by 50-100% next month
    • Current: $___ /month → Target: $___ /month
  2. Monitor key metrics weekly:
    • CAC (should stay <$___)
    • Magic Number (should stay >0.75)
    • Customer quality (retention, NRR)
  3. Scale until:
    • CAC increases >20% (saturation signal)
    • Magic Number drops <0.75 (efficiency declining)
    • Volume caps out

Expected impact:

  • Current: ___ customers/month
  • Target (2x spend): ___ customers/month
  • MRR impact: +$___/month
  • Payback: Still ~___ months even at 2x scale

Risk: Low. Strong unit economics support aggressive scaling."


Recommendation Pattern 2: Test & Optimize

When:

  • LTV:CAC 2-3:1 OR
  • Payback 12-18 months OR
  • Customer quality average OR
  • Magic Number 0.5-0.75

Recommendation:

"Test & optimize before scaling — Marginal economics, fixable

Current State:

  • CAC: $___
  • LTV: $___
  • LTV:CAC: ___:1 ⚠️ (2-3:1 = marginal)
  • Payback: ___ months ⚠️ (12-18 months)
  • Magic Number: ___ ⚠️ (0.5-0.75 = acceptable, not great)

Customer Quality:

  • Retention: [Same as blended / Slightly worse]
  • NRR: [Same / Lower]
  • Issue: [Specific problem, e.g., "Higher churn in first 90 days"]

Diagnosis: [One of these:]

  • High CAC: Spending too much to acquire
  • Low LTV: Customers churn too fast or don't expand
  • Poor targeting: Attracting off-ICP customers
  • Inefficient conversion: High cost-per-click but low conversion rate

How to optimize:

If CAC is the problem:

  1. Improve conversion rate (optimize landing pages, offer, onboarding)
  2. Reduce cost-per-click (better targeting, ad creative)
  3. Shorten sales cycle (faster qualification, better demos)

If LTV is the problem:

  1. Improve onboarding for customers from this channel
  2. Target higher-value segments within channel
  3. Add expansion plays (upsell, cross-sell)

If targeting is the problem:

  1. Narrow audience (exclude poor-fit segments)
  2. Improve messaging (attract better-fit customers)
  3. Add qualification step (reduce poor-fit signups)

Timeline:

  • Spend 4-8 weeks optimizing
  • Track CAC and LTV weekly
  • Target: LTV:CAC >3:1, payback <12 months
  • If you hit targets: scale
  • If you can't fix it: consider killing

Don't scale yet: Current economics are break-even at best. Fix first, then scale."


Recommendation Pattern 3: Kill or Pause

When:

  • LTV:CAC <1.5:1 AND
  • No clear path to improvement

Recommendation:

"Kill this channel (or pause) — Economics don't support investment

Why:

  • CAC: $___
  • LTV: $___
  • LTV:CAC: ___:1 🚨 (<2:1 = unsustainable)
  • Payback: ___ months 🚨 (>18 months = cash trap)

Problem:

  • You're spending $___ to acquire a customer worth $___
  • [Losing money / Barely breaking even / Taking too long to recover cost]

Customer Quality:

  • Retention: [Worse than blended]
  • NRR: [Lower]
  • ICP Fit: [Poor]

What's broken: [Specific diagnosis:]

  • CAC too high (spending $___ vs. blended $___)
  • LTV too low (customers churn at ___% vs. blended ___%)
  • Both (bad unit economics from both sides)

Should you fix or kill?

Fix if:

  • You have a hypothesis to improve CAC by 50%+ (better targeting, conversion)
  • You have a hypothesis to improve LTV by 50%+ (better onboarding, ICP focus)
  • This is a strategically important channel (e.g., enterprise requires field sales)

Kill if:

  • No clear path to 3:1 LTV:CAC
  • Better channels available (reallocate budget there)
  • Small addressable volume (not worth fixing)

Recommendation: Kill and reallocate budget

Reallocate to:

  • Channel X (LTV:CAC = ___:1, can scale)
  • Channel Y (Magic Number = ___, efficient)

What to do with budget:

  • Current channel spend: $___/month
  • Reallocate to [top-performing channel]
  • Expected impact: [better CAC, better LTV, faster payback]

Exception: If this channel is <10% of total S&M spend, just pause it. Not worth fixing."


Recommendation Pattern 4: Invest to Learn (Strategic Channel)

When:

  • Poor unit economics BUT
  • Strategic importance (enterprise channel, brand building, long-term)

Recommendation:

"Continue, but cap investment — Strategic value > short-term ROI

Financial Reality:

  • CAC: $___
  • LTV: $___
  • LTV:CAC: ___:1 (below 3:1 threshold)
  • Payback: ___ months (long)

Why continue despite poor economics:

  • [Strategic reason: e.g., "Enterprise segment requires field events, but deals are 12-month sales cycles"]
  • [Brand building: e.g., "Conferences build brand awareness that drives inbound long-term"]
  • [Market positioning: e.g., "Need to be present in this channel for credibility"]

How to manage:

  1. Cap spend — Don't scale until economics improve
    • Current: $___/month
    • Cap at: $___/month (hold steady)
  2. Track leading indicators — Don't just look at short-term CAC/LTV
    • Pipeline influence
    • Brand awareness lift
    • Referral rate from this channel
  3. Re-evaluate quarterly
    • If economics improve (LTV:CAC >3:1): scale
    • If economics stay poor: reconsider strategy

Timeline:

  • Give it [6-12 months] to show results
  • If no improvement: kill or reduce drastically

Risk: You're subsidizing growth. Make sure it's worth it."


Step 5: Compare Across Channels (Optional)

If user has multiple channels, agent can generate:

Channel CAC LTV LTV:CAC Payback Magic Number Quality Recommendation
Google Ads $500 $2,000 4:1 8mo 0.9 High Scale
Content $200 $1,500 7.5:1 4mo 1.2 High Scale
Outbound $10K $50K 5:1 18mo 0.6 Medium Optimize
Events $15K $30K 2:1 24mo 0.3 Low Kill

Budget allocation recommendation:

  1. Scale: Content (highest efficiency)
  2. Scale: Google Ads (strong economics)
  3. Optimize: Outbound (improve magic number)
  4. Kill: Events (reallocate budget)

Examples

See examples/ folder for sample conversation flows. Mini examples below:

Example 1: Scale (Content Marketing)

Channel: Organic content (blog, SEO)

  • CAC: $200
  • LTV: $3,000
  • LTV:CAC: 15:1
  • Payback: 3 months
  • Magic Number: 1.8
  • Customer quality: High (lower churn, higher NRR)

Recommendation: Scale aggressively. Exceptional unit economics, fast payback, high-quality customers. Increase content spend 2-3x.


Example 2: Optimize (Paid Search)

Channel: Google Ads

  • CAC: $800
  • LTV: $2,000
  • LTV:CAC: 2.5:1
  • Payback: 14 months
  • Magic Number: 0.6
  • Customer quality: Lower (higher churn in first 90 days)

Recommendation: Test & optimize before scaling. CAC is high, onboarding is weak for this segment. Improve landing page, target higher-intent keywords, better onboarding for paid customers.


Example 3: Kill (Trade Shows)

Channel: Industry events

  • CAC: $20,000
  • LTV: $30,000
  • LTV:CAC: 1.5:1
  • Payback: 30 months
  • Magic Number: 0.2
  • Customer quality: Low (off-ICP, many tire-kickers)

Recommendation: Kill. CAC too high, payback too long, poor customer quality. Reallocate budget to content and paid search.


Common Pitfalls

Pitfall 1: Scaling Broken Channels

Symptom: "Let's 10x our Google Ads spend!" (LTV:CAC is 1.5:1)

Consequence: You accelerate cash burn without improving unit economics. Lose money faster.

Fix: Only scale channels with LTV:CAC >3:1 and payback <12 months. Fix broken channels before scaling.


Pitfall 2: Ignoring Customer Quality

Symptom: "CAC is only $100!" (but customers churn in 30 days)

Consequence: Low CAC means nothing if LTV is also low. You're acquiring churners, not customers.

Fix: Track cohort retention and NRR by channel. Low CAC + high churn = bad channel.


Pitfall 3: Celebrating Vanity Metrics

Symptom: "We got 10,000 signups from this campaign!" (5% convert to paid)

Consequence: Signups don't pay bills. CAC is calculated on paid customers, not signups.

Fix: Track CAC on paid customers only. Ignore vanity metrics like signups, impressions, clicks.


Pitfall 4: Averaging Across Channels

Symptom: "Blended CAC is $500" (but hiding that one channel is $10K CAC)

Consequence: Bad channels hide in blended metrics. You don't know which channels to kill.

Fix: Track CAC, LTV, payback by channel. Compare channels individually.


Pitfall 5: Short-Term CAC Optimization

Symptom: "We reduced CAC 50%!" (by targeting low-intent, low-LTV customers)

Consequence: CAC dropped but so did LTV. Unit economics got worse, not better.

Fix: Optimize for LTV:CAC ratio, not CAC alone. Higher CAC with higher LTV is better.


Pitfall 6: Ignoring Payback Period

Symptom: "LTV:CAC is 6:1, this channel is amazing!" (payback is 48 months)

Consequence: You run out of cash before recovering CAC. Great ratio, terrible cash flow.

Fix: Pair LTV:CAC with payback period. 3:1 with 8-month payback beats 6:1 with 36-month payback.


Pitfall 7: Killing Channels Too Early

Symptom: "This channel didn't work after 2 weeks"

Consequence: Channels need time to optimize. Killing too early wastes learning.

Fix: Give channels 3-6 months and 100+ customers before evaluating. Track trends, not snapshots.


Pitfall 8: Over-Relying on One Channel

Symptom: "90% of our customers come from Google Ads"

Consequence: Algorithm change, competitor outbids you, channel saturates = business grinds to halt.

Fix: Diversify channels. No single channel should be >50% of new customer acquisition.


Pitfall 9: Forgetting Incrementality

Symptom: "This retargeting campaign has great ROI!" (but customers would've converted anyway)

Consequence: You're paying for conversions that would happen organically. Inflated ROI.

Fix: Test incrementality with holdout groups. Only count truly incremental conversions.


Pitfall 10: Strategic Channels Without Limits

Symptom: "Enterprise events are strategic, we can't stop!" (losing $500K/year)

Consequence: "Strategic" becomes an excuse for burning cash indefinitely.

Fix: Cap spend on strategic channels. Set timeline for improvement (6-12 months). If no progress, kill.


References

Related Skills

  • saas-economics-efficiency-metrics — CAC, LTV, payback, magic number calculations
  • saas-revenue-growth-metrics — NRR, churn, cohort analysis by channel
  • finance-metrics-quickref — Fast lookup for channel evaluation metrics
  • feature-investment-advisor — Similar ROI framework for feature decisions
  • business-health-diagnostic — Broader business health assessment

External Frameworks

  • Brian Balfour (Reforge): Channel-product fit framework
  • David Skok: "SaaS Metrics" — CAC, LTV, and payback for channels
  • Tomasz Tunguz: SaaS channel benchmarking
  • First Round Review: "How to Find and Scale Your Growth Channels"

Provenance

  • Adapted from research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md (Decision Framework #2)
  • Channel economics from research/finance/Finance for Product Managers.md
指导产品经理将复杂重复任务设计为多智能体并行工作流,通过明确边界和交接实现自动化编排。帮助用户从线性管理转向系统级协调,让AI处理研究验证,PM专注战略决策,提升产出效率与业务结果。
需要将复杂的PM任务分解为多个并行子任务 希望用多智能体协作替代手动或线性流程 设计涉及AI、人类和数据交互的自动化工作流
skills/agent-orchestration-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill agent-orchestration-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "agent-orchestration-advisor",
    "type": "interactive",
    "theme": "ai-agents",
    "intent": "Guide product managers through designing multi-agent workflows — breaking complex, repetitive tasks into parallel, specialized AI agents rather than linear, sequential processes. Covers the 4 dimensions of orchestration, agent boundary design, launch control tower monitoring, and evaluation frameworks.",
    "best_for": [
        "Breaking a complex PM workflow into parallel, specialized AI agents",
        "Designing agent boundaries, handoffs, and human review points",
        "Setting up launch control tower monitoring for agentic workflows"
    ],
    "scenarios": [
        "I spend hours on competitive research every week — help me design agents to run it in parallel",
        "Our AI workflow is one giant sequential prompt chain — help me re-architect it as an orchestrated system"
    ],
    "description": "Design multi-agent AI workflows with clear boundaries, handoffs, and monitoring. Use when a complex PM task should run as parallel specialized agents instead of one linear process.",
    "argument-hint": "[workflow or task to orchestrate]",
    "estimated_time": "15-25 min"
}

Purpose

Guide product managers through designing multi-agent workflows—breaking complex, repetitive PM tasks into parallel, specialized AI agents rather than linear, sequential processes or manual execution. Use this to transition from "document-heavy administrator" to "systems-level orchestrator" who coordinates a "living system" of AI agents, human teams, and market data interacting continuously.

Key Shift: From linear project management (one task at a time) to orchestration (multiple agents working simultaneously, each with clear boundaries and handoffs).

This is not about prompt writing—it's about architecting workflows where AI agents handle repetitive research, synthesis, and validation while PMs focus on strategy and decision-making.

Input

Works best with: The workflow or recurring task you want to orchestrate — described in a sentence or two, however manual or messy it is today. Also useful: Where it breaks down now (too slow, too sequential, too dependent on you), the tools your team already uses, and whether you've worked through context-engineering-advisor first (it's the prerequisite discipline).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking which PM workflow eats the most of your week, then walks the four orchestration dimensions against it.

Example invocation: Design an orchestration for our weekly competitive intel: today one PM spends 6 hours scraping, summarizing, and briefing — sequentially.

Key Concepts

Orchestration vs. Project Management

Dimension Project Management Orchestration
Approach Linear oversight of schedules and human tasks Managing "living system" where AI agents, humans, and data interact continuously
Task Flow Sequential (finish A, then B, then C) Parallel (A, B, C run simultaneously)
PM Role Document-heavy administrator Systems-level leader coordinating automated systems + human judgment
Focus Output (features shipped) Outcome (business results, learning velocity)
Risk Management Manual tracking and mitigation Real-time monitoring with agentic systems flagging gaps

Critical Insight: Orchestration is not about replacing humans—it's about force-multiplying human judgment by automating repetitive, time-consuming tasks.


The Four Dimensions of Orchestration

1. Coordination of Multi-Agent Workflows

Breaking complex tasks into specialized agents that run in parallel.

Example:

  • Manual (Old): PM spends 8 hours compiling competitive intel, then 4 hours synthesizing customer feedback, then 3 hours identifying roadmap gaps = 15 hours sequentially
  • Orchestrated (New): Three agents run simultaneously:
    • Agent A: Competitive intel (research agent)
    • Agent B: Customer synthesis (synthesis agent)
    • Agent C: Roadmap gap analysis (analysis agent)
    • Total time: 8 hours (limited by slowest agent), PM reviews outputs in 2 hours = 10 hours total, 5 hours saved

Key Principle: Shift from manual selection to hypothesis orchestration—agents generate hypotheses, PM validates and decides.

2. Leadership of Cross-Functional AI Pods

Governing diverse teams (data scientists, ML engineers, compliance, ethicists) to ensure solutions are scalable, ethical, and aligned.

What it includes:

  • Embedding diversity-aware workflows
  • Risk management (not afterthought)
  • Ethical orchestration (ensuring AI doesn't "go rogue")
  • Cross-functional alignment (engineering, compliance, design)

PM Role: Guardian of Governance—ensures AI systems reflect company values.

3. Launch Control Tower Function

Real-time monitoring of organizational readiness across functions using agentic systems to flag gaps before critical failures.

What it monitors:

  • Support readiness (docs, training, escalation paths)
  • Marketing readiness (messaging, assets, GTM plan)
  • Operations readiness (infrastructure, scaling, monitoring)

Key Principle: Agentic systems act as early warning system—flag gaps before they become blockers.

4. Strategic Intent Alignment (Context Engineering Applied)

Feeding AI agents the correct mix of mission, constraints, and priorities to ensure automated decisions reflect company values.

Connection: This is context engineering at the orchestration layer. See context-engineering-advisor for foundations.

What agents need:

  • Product constraints (what we will/won't build)
  • Strategic priorities (what matters most right now)
  • Operational definitions (shared glossary)
  • Evidence standards (what counts as validation)

The Four AI Management Workflows (Productside Blueprint)

Every PM must master these workflows to move fast while staying grounded:

  1. Context Engineering ✅ (Foundation)

    • Create AI workspace that remembers product domain, research, JTBD, personas, constraints
    • Skill: context-engineering-advisor
  2. Synthetic Evals 📋 (Quality Assurance)

    • Automated validation tests for AI reasoning
    • Generate synthetic data, run workflows against traces
    • Eliminates 80% of hallucination risk
  3. Agentic WorkflowsWe're here

    • Agents handle repetitive tasks (competitive intel, customer synthesis, roadmap gaps)
    • PM focuses on strategy
  4. Vibe Coding 📋 (Rapid Prototyping)

    • Generate clickable prototypes from context workspace
    • Collapse feedback loops from weeks to hours
    • Connection: pol-probe-advisor (Vibe-Coded PoL Probes)

AI-Shaped Problems (Teresa Torres)

What makes a problem "AI-shaped"?

  • Previously difficult to scale due to human involvement (e.g., synthesizing 50 user interviews)
  • Falls short with current non-AI solutions (e.g., manual competitive tracking)
  • Requires consistency at scale (e.g., risk analysis across 100 features)

Key Insight: "While AI makes building easier, choosing what to build remains the primary challenge." Orchestration helps with the "building" part so PMs can focus on "choosing."


The Four Big Risks (Marty Cagan, AI Era)

The orchestrator manages these risks across the organization:

Risk Standard Definition AI Era Layer Orchestrator's Role
Value Risk Will customers pay? Does AI provide enough incremental benefit vs. cost? Validate value with PoL probes before orchestrating
Usability Risk Can users figure it out? Is the UX right? (Chat often isn't!) Test workflows with real users
Feasibility Risk Can we build it? Do we understand "physics of AI"? Token budget? Design within technical constraints
Viability Risk Can we sell/support? Legal limits? Data privacy? Sustainable OpEx? Monitor costs, compliance, scalability

Anti-Patterns (What This Is NOT)

  • Not about replacing PMs: Orchestration amplifies judgment, doesn't eliminate it
  • Not about automating everything: Some tasks require human empathy and context
  • Not about complexity for its own sake: Only orchestrate when it saves significant time or improves quality
  • Not about "set it and forget it": Orchestrated workflows require monitoring and maintenance

When to Use This Skill

Use this when:

  • You have repetitive PM tasks that take 5+ hours per week (competitive analysis, customer synthesis, roadmap maintenance)
  • You're doing sequential work that could be parallelized (research, then synthesis, then analysis)
  • You need consistency at scale (analyze 50 features for risk, synthesize 100 customer interviews)
  • You're spending time on execution instead of strategy

Don't use this when:

  • The task is one-time or infrequent (not worth orchestration overhead)
  • Human judgment is critical at every step (empathy-driven work)
  • The task is already fast enough (don't over-engineer)
  • You haven't built context engineering foundations first (see context-engineering-advisor)

Application

This interactive skill uses adaptive questioning to design multi-agent workflows step-by-step.


Step 0: Gather Context

Agent asks:

Before we design your orchestrated workflow, let's gather context:

Current PM Work:

  • What repetitive tasks take the most time each week? (competitive analysis, customer synthesis, roadmap updates, etc.)
  • How much time do you spend on these tasks? (hours per week)
  • Are these tasks sequential (one after another) or could they run in parallel?

Desired Outcome:

  • What would "good enough" automation look like? (80% reduction in manual work? Higher consistency?)
  • What parts require human judgment? (final decisions, empathy, ethical considerations)

Technical Context:

  • Do you have context engineering foundations? (constraints registry, operational glossary—see context-engineering-advisor)
  • What AI tools do you currently use? (Claude Projects, ChatGPT, custom agents)

You can describe briefly or paste examples.


Step 1: Assess if Task is AI-Shaped

Agent asks:

Let's determine if your task is suited for orchestration. Which statement best describes your situation?

Select one:

  1. "I spend 10+ hours per week on repetitive research/synthesis tasks"

    • Examples: Compiling competitive intelligence, synthesizing customer feedback, tracking feature requests
    • Assessment: High potential for orchestration
  2. "I have a task that requires multiple sequential steps, and each step is time-consuming"

    • Examples: Research competitors → Synthesize findings → Identify gaps → Update roadmap (15 hours total, done sequentially)
    • Assessment: Good candidate for parallelization
  3. "I need consistency at scale—analyzing many similar items"

    • Examples: Risk analysis for 50 features, synthesizing 100 user interviews, tracking 20 competitors
    • Assessment: Perfect for orchestration (agents ensure consistency)
  4. "I have a task that's mostly human judgment and empathy"

    • Examples: Stakeholder negotiation, team coaching, ethical trade-offs
    • Assessment: Not a good candidate for orchestration (keep human-driven)

User response: [Selection]

Agent analyzes:

Based on your selection:

  • Options 1-3: Proceed to workflow design
  • Option 4: Recommend keeping task human-driven; suggest alternative approaches (e.g., use AI for research, but keep decision-making human)

Step 2: Decompose Task into Agent-Specific Subtasks

Agent asks:

Let's break your task into discrete subtasks, each handled by a specialized agent.

For the task you selected, what are the distinct steps?

Example Decomposition (Competitive Intelligence):

Manual Process (Old):

  1. Research 10 competitors' product pages (3 hours)
  2. Track recent feature launches (2 hours)
  3. Analyze pricing changes (2 hours)
  4. Synthesize into competitive landscape doc (3 hours)
  5. Identify strategic gaps (2 hours) Total: 12 hours, done sequentially

Orchestrated Process (New):

  • Agent A (Research): Scrape competitors' product pages, extract features
  • Agent B (Launch Tracker): Monitor competitors' release notes, blog posts, social media
  • Agent C (Pricing Analyzer): Track pricing pages, identify changes
  • Agent D (Synthesis): Compile findings from A, B, C into structured report
  • Agent E (Gap Analysis): Compare our roadmap vs. competitor features, flag gaps Total: Agents A-C run in parallel (3 hours), then D and E run sequentially (2 hours) = 5 hours + 1 hour PM review = 6 hours total (50% time saved)

Agent offers:

I'll help you decompose your task. Describe your current process step-by-step, and I'll identify:

  • Which steps can be agent-handled
  • Which steps can run in parallel
  • Which steps require human judgment

User response: [Describe process]

Agent provides: Decomposed workflow with agent assignments.


Step 3: Design Parallel vs. Sequential Flows

Agent asks:

Now let's design the workflow topology—which agents run in parallel vs. sequentially.

Three Flow Patterns:

Pattern 1: Full Parallel (Fastest)

[Agent A] ─┐
[Agent B] ─┼─→ [PM Review] → [Decision]
[Agent C] ─┘
  • All agents run simultaneously
  • PM reviews all outputs together
  • Use when: Agents are independent (no dependencies between them)

Pattern 2: Pipeline (Sequential with Handoffs)

[Agent A] → [Agent B] → [Agent C] → [PM Review] → [Decision]
  • Each agent depends on previous agent's output
  • Use when: Later agents need earlier agents' results

Pattern 3: Hybrid (Parallel + Sequential)

[Agent A] ─┐
[Agent B] ─┼─→ [Agent D] → [Agent E] → [PM Review] → [Decision]
[Agent C] ─┘
  • Some agents run in parallel, feed into sequential agents
  • Use when: Early steps are independent, later steps synthesize

For your task, which pattern fits best?

Options:

  1. Full Parallel — All agents are independent
  2. Pipeline — Each agent needs the previous one's output
  3. Hybrid — Mix of parallel and sequential
  4. Not sure — [Agent analyzes your decomposition and recommends]

User response: [Selection]

Agent provides: Visual workflow diagram with agent dependencies.


Step 4: Define Agent Boundaries and Handoffs

Agent asks:

Now let's define what each agent knows (context boundaries) and how agents hand off to each other.

For each agent, define:

  1. Agent Name & Purpose (What's its job?)
  2. Context Needed (What information does it need?)
    • Always-available (from context engineering)
    • Retrieved on-demand (specific to this run)
  3. Output Format (What does it produce?)
  4. Handoff to Next Agent (What gets passed? What gets filtered?)

Example (Competitive Intelligence Orchestration):

Agent A: Competitor Research Agent

  • Purpose: Scrape 10 competitors' product pages, extract features
  • Context Needed:
    • Always-available: List of competitors (from constraints registry)
    • Retrieved: Competitor URLs (from database)
  • Output Format: Structured JSON: {competitor, features[], last_updated}
  • Handoff: Passes JSON to Agent D (Synthesis Agent)

Agent D: Synthesis Agent

  • Purpose: Compile findings from Agents A, B, C into structured report
  • Context Needed:
    • Always-available: Report template, writing tone (from context workspace)
    • Retrieved: Outputs from Agents A, B, C
  • Output Format: Markdown document with sections: Overview, Key Features, Pricing, Launch Activity
  • Handoff: Passes report to Agent E (Gap Analysis Agent)

Agent offers:

I'll help you define boundaries for each agent. For your workflow, let's define:

  • What context each agent needs (always-available vs. retrieved)
  • What format each agent produces (JSON, Markdown, structured data)
  • How agents hand off (what's passed vs. filtered)

User response: [Describe agent needs]

Agent provides: Complete agent boundary definitions + handoff specifications.


Step 5: Implement Strategic Intent Alignment

Agent asks:

To prevent agents from "going rogue," we need to feed them the correct mix of mission, constraints, and priorities.

Strategic Intent Checklist (Per Agent):

  1. Mission: What is this agent's primary goal?

    • Example: "Identify competitive threats that could impact Q2 roadmap"
  2. Constraints: What must the agent NOT do?

    • Example: "Do not recommend features outside our strategic focus areas"
    • Example: "Do not scrape data from sites that prohibit it (check robots.txt)"
  3. Priorities: If the agent must choose, what matters most?

    • Example: "Prioritize features launched in last 30 days over older features"
  4. Evidence Standards: What counts as valid information?

    • Example: "Only cite information from official product pages, release notes, or verified blog posts"

Connection: This is context engineering applied to orchestration. See context-engineering-advisor for deeper guidance.

Agent offers:

For each agent in your workflow, let's define:

  • Mission (what's the goal?)
  • Constraints (what's out of bounds?)
  • Priorities (what matters most?)
  • Evidence standards (what counts as valid?)

User response: [Define strategic intent per agent]

Agent provides: Strategic intent document for each agent.


Step 6: Set Up Launch Control Tower Monitoring

Agent asks:

The Launch Control Tower provides real-time monitoring to flag gaps before they become critical failures.

What to Monitor (Three Dimensions):

1. Agent Performance:

  • Are agents completing tasks on time?
  • Are outputs meeting quality standards?
  • Are agents staying within token/cost budgets?

2. Organizational Readiness (If Launching a Feature):

  • Support readiness: Docs updated? Training complete? Escalation paths defined?
  • Marketing readiness: Messaging finalized? Assets created? GTM plan locked?
  • Operations readiness: Infrastructure scaled? Monitoring in place? Rollback plan ready?

3. Risk Flags:

  • Are agents producing unexpected outputs? (potential hallucination)
  • Are agents violating constraints? (ethical/compliance issues)
  • Are handoffs failing? (Agent B not receiving Agent A's output correctly)

Monitoring Approach:

Option 1: Manual Dashboard

  • Weekly PM review of agent outputs
  • Spot-check quality, compare to golden datasets
  • Manual risk flag identification

Option 2: Automated Monitoring

  • Agents log outputs to central dashboard
  • Automated evals run on each output (see Step 7)
  • Alerts triggered when quality drops below threshold

Option 3: Hybrid

  • Automated evals + weekly PM review
  • Alerts for critical issues, PM spot-checks others

Which monitoring approach fits your team's maturity?

Options:

  1. Manual Dashboard (Lower maturity, smaller scale)
  2. Automated Monitoring (Higher maturity, larger scale)
  3. Hybrid (Recommended for most teams)

User response: [Selection]

Agent provides: Monitoring plan with specific metrics and alert thresholds.


Step 7: Create Evaluation Plan

Agent asks:

To ensure orchestrated workflows produce high-quality outputs, we need an evaluation framework.

The Four Eval Types (From Research):

Eval Type Method When to Use
Golden Datasets 20-100 examples of real inputs + expected outputs Baseline quality measurement
Code Assertions Rules output must follow (e.g., must contain valid JSON) Structural validation
LLM-as-Judge Powerful model (GPT-4o) grades agent output Rapid automated feedback
Human Evals PM manually reviews traces Ultimate check for "taste" and "product sense"

Evaluation Process:

  1. Collect Traces: Log inputs and outputs for each agent run
  2. Review Weekly: Annotate traces to categorize failure modes
  3. Build Failure Mode Taxonomy: Common errors (hallucination, constraint violation, low quality)
  4. Create Automated Evals: Target common failure modes with Golden Datasets or Code Assertions
  5. Iterate: Refine agent prompts/context based on eval results

For your workflow, which evals make sense?

Options:

  1. Start with Golden Datasets — Create 20 examples of good outputs for each agent
  2. Start with Code Assertions — Define structural rules (e.g., output must be valid JSON with required fields)
  3. Start with Human Evals — PM reviews every output for first 2 weeks, identifies patterns
  4. All three — Comprehensive eval strategy (recommended for critical workflows)

User response: [Selection]

Agent provides: Evaluation plan with specific eval types, frequencies, and success criteria.


Step 8: Implementation Plan & Next Steps

Agent synthesizes:

Here's your complete orchestrated workflow plan:

┌─────────────────────────────────────────────────────────────┐
│ ORCHESTRATED WORKFLOW: [Your Task Name]                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ TOPOLOGY: [Full Parallel / Pipeline / Hybrid]              │
│                                                             │
│ AGENTS:                                                     │
│ • Agent A: [Name] - [Purpose]                              │
│ • Agent B: [Name] - [Purpose]                              │
│ • Agent C: [Name] - [Purpose]                              │
│                                                             │
│ FLOW:                                                       │
│ [Agent A] ─┐                                                │
│ [Agent B] ─┼─→ [Agent D] → [PM Review] → [Decision]        │
│ [Agent C] ─┘                                                │
│                                                             │
│ CONTEXT BOUNDARIES:                                         │
│ • Always-available: [List]                                  │
│ • Retrieved on-demand: [List]                               │
│                                                             │
│ STRATEGIC INTENT:                                           │
│ • Mission: [Per agent]                                      │
│ • Constraints: [Per agent]                                  │
│ • Priorities: [Per agent]                                   │
│                                                             │
│ MONITORING:                                                 │
│ • Approach: [Manual / Automated / Hybrid]                   │
│ • Metrics: [List]                                           │
│ • Alert thresholds: [List]                                  │
│                                                             │
│ EVALUATION:                                                 │
│ • Golden Datasets: [Y/N]                                    │
│ • Code Assertions: [Y/N]                                    │
│ • Human Evals: [Frequency]                                  │
│                                                             │
│ TIME SAVINGS:                                               │
│ • Manual (old): [X hours]                                   │
│ • Orchestrated (new): [Y hours]                             │
│ • Savings: [X-Y hours per week]                             │
└─────────────────────────────────────────────────────────────┘

Implementation Roadmap:

Week 1: Build Context Foundations

  • If not already done, complete context-engineering-advisor
  • Create constraints registry, operational glossary
  • Document strategic intent for each agent

Week 2: Implement First Agent

  • Start with simplest agent (usually research or data collection)
  • Test with 5 real examples
  • Validate output quality

Week 3: Add Remaining Agents

  • Implement agents 2-5 (depending on your workflow)
  • Test handoffs between agents
  • Validate full workflow end-to-end

Week 4: Set Up Monitoring & Evals

  • Implement chosen monitoring approach
  • Create Golden Datasets (if selected)
  • Run first week of human evals, identify failure modes

Week 5+: Iterate & Scale

  • Refine agent prompts based on eval results
  • Add automated evals targeting common failures
  • Scale to more use cases

Success Criteria:

  • ✅ Time savings: 30%+ reduction in manual work
  • ✅ Quality: Agent outputs meet quality bar 80%+ of time
  • ✅ Consistency: Outputs follow template/format 95%+ of time
  • ✅ Monitoring: Alerts catch issues before PM notices
  • ✅ Evaluation: Failure mode taxonomy documented, automated evals in place

Agent offers:

Would you like me to:

  1. Export this workflow plan as a Markdown document?
  2. Provide implementation templates (agent prompt templates, monitoring dashboard, eval checklists)?
  3. Recommend tools for building this orchestration (Claude Projects, custom APIs, orchestration platforms)?

Examples

Example 1: Competitive Intelligence Orchestration

Context:

  • PM at B2B SaaS company
  • Tracks 10 competitors
  • Manual process: 12 hours per week (research, synthesis, gap analysis)

Goal: Reduce to 6 hours with orchestrated workflow

Workflow Design:

Agents:

  • Agent A (Research): Scrapes competitors' product pages, extracts features
  • Agent B (Launch Tracker): Monitors release notes, blogs, social media for new launches
  • Agent C (Pricing Analyzer): Tracks pricing pages, identifies changes
  • Agent D (Synthesis): Compiles findings from A, B, C into structured report
  • Agent E (Gap Analysis): Compares our roadmap vs. competitors, flags strategic gaps

Topology: Hybrid (A, B, C in parallel → D → E → PM Review)

Strategic Intent:

  • Mission (Agent E): "Identify competitive threats that could impact Q2 roadmap"
  • Constraint (Agent E): "Do not recommend features outside our strategic focus areas (enterprise security, AI-powered analytics)"
  • Priority (Agent B): "Prioritize features launched in last 30 days"

Monitoring:

  • Hybrid approach: Automated evals + weekly PM review
  • Metrics: Agent completion time, output quality score (LLM-as-Judge)
  • Alert: If Agent E flags >5 critical gaps (potential strategic threat)

Evaluation:

  • Golden Datasets: 20 examples of well-synthesized competitive reports
  • Code Assertions: Output must be valid JSON with required fields (competitor, features[], pricing[], launch_date)
  • Human Evals: PM reviews one full workflow run per week

Result:

  • Time: 12 hours → 6 hours (50% savings)
  • Quality: Consistent format, no missed competitors
  • Strategic value: Gap analysis flags threats 2 weeks earlier than manual process

Example 2: Customer Feedback Synthesis

Context:

  • PM at consumer app
  • Receives 200+ pieces of feedback per week (app reviews, support tickets, NPS comments)
  • Manual process: 8 hours per week (reading, tagging, synthesizing themes)

Goal: Reduce to 2 hours with orchestrated workflow

Workflow Design:

Agents:

  • Agent A (Ingestion): Collects feedback from App Store, Google Play, Zendesk, NPS surveys
  • Agent B (Tagging): Tags feedback by category (bug, feature request, usability, performance)
  • Agent C (Sentiment): Classifies sentiment (positive, neutral, negative, critical)
  • Agent D (Theme Extraction): Identifies recurring themes across feedback
  • Agent E (Prioritization): Scores themes by frequency + sentiment intensity
  • Agent F (Synthesis): Generates weekly synthesis report with top 5 themes + example quotes

Topology: Pipeline (A → B → C → D → E → F → PM Review)

Strategic Intent:

  • Mission (Agent D): "Identify unmet customer needs that could become roadmap opportunities"
  • Constraint (Agent E): "Do not deprioritize critical bugs, even if infrequent"
  • Priority (Agent F): "Focus on themes affecting 10+ users in last 7 days"

Monitoring:

  • Automated: Dashboard shows agent completion status, error rate
  • Alerts: If Agent C flags >10 "critical" sentiment items (escalate to PM immediately)

Evaluation:

  • Golden Datasets: 50 examples of well-tagged, well-synthesized feedback
  • LLM-as-Judge: Weekly eval of Agent D's theme extraction quality
  • Human Evals: PM spot-checks 10% of tagged feedback

Result:

  • Time: 8 hours → 2 hours (75% savings)
  • Quality: Themes now backed by quantitative data (frequency, sentiment)
  • Strategic value: Identified 3 high-impact themes that became Q2 roadmap features

Example 3: Risk Analysis at Scale

Context:

  • PM at enterprise platform
  • Needs to analyze 50 features for risk (security, compliance, performance, usability)
  • Manual process: 15 hours (30 minutes per feature)

Goal: Reduce to 5 hours with orchestrated workflow

Workflow Design:

Agents:

  • Agent A (Security Risk): Analyzes feature for security vulnerabilities (data exposure, auth issues)
  • Agent B (Compliance Risk): Checks feature against regulatory requirements (GDPR, HIPAA, SOC2)
  • Agent C (Performance Risk): Estimates load impact, identifies scaling concerns
  • Agent D (Usability Risk): Flags complex workflows, accessibility issues
  • Agent E (Synthesis): Compiles risk scores, generates risk matrix

Topology: Full Parallel (A, B, C, D run simultaneously → E → PM Review)

Strategic Intent:

  • Mission (All agents): "Flag risks that could delay launch or harm customers"
  • Constraint (Agent B): "Must cite specific regulatory requirements (not vague warnings)"
  • Priority (Agent E): "Prioritize risks by impact × likelihood (standard risk matrix)"

Monitoring:

  • Automated: Dashboard shows risk distribution (low/medium/high/critical)
  • Alerts: If any feature scores "critical" risk (escalate to PM + leadership)

Evaluation:

  • Golden Datasets: 30 examples of well-analyzed features with known risks
  • Code Assertions: Risk scores must be {low, medium, high, critical}—no other values
  • Human Evals: Security team reviews Agent A outputs monthly

Result:

  • Time: 15 hours → 5 hours (67% savings)
  • Quality: Consistent risk scoring across all 50 features
  • Strategic value: Identified 3 critical risks that would have been missed in manual review

Common Pitfalls

1. Orchestrating Before Context Engineering

Failure Mode: Building agent workflows without context foundations (constraints, glossary, evidence standards).

Consequence: Agents produce inconsistent outputs, violate constraints, hallucinate.

Fix: Complete context-engineering-advisor first. Build constraints registry, operational glossary, strategic intent documents.


2. Over-Orchestrating Simple Tasks

Failure Mode: Creating complex multi-agent workflows for tasks that take <2 hours per week.

Consequence: Orchestration overhead (setup, monitoring, maintenance) exceeds time saved.

Fix: Only orchestrate tasks that take 5+ hours per week or require consistency at scale.


3. No Evaluation Plan

Failure Mode: "Set it and forget it"—agents run without quality checks.

Consequence: Quality drift over time, unnoticed hallucinations, constraint violations.

Fix: Implement Golden Datasets + weekly Human Evals at minimum. Build failure mode taxonomy, create automated evals.


4. Ignoring Handoff Failures

Failure Mode: Assuming agents will correctly pass data to each other without testing.

Consequence: Agent B receives malformed data from Agent A, produces garbage output.

Fix: Test handoffs explicitly. Validate data format at each handoff. Use Code Assertions to enforce structure.


5. Forgetting the "PM Review" Step

Failure Mode: Treating orchestrated workflows as fully autonomous—no human oversight.

Consequence: Agents make decisions that lack context, empathy, or strategic alignment.

Fix: Always include PM Review step. Agents generate hypotheses/recommendations; PM validates and decides.


References

Related Skills

External Frameworks

  • Dean PetersThe Product Manager as an Orchestrator (Productside research)
  • Dean PetersProductside Blueprint (Four AI Management Workflows: Context Engineering, Synthetic Evals, Agentic Workflows, Vibe Coding)
  • Teresa TorresContinuous Discovery Habits (5 AI PM disciplines: Context Engineering, Orchestration, Observability, Evals, Maintenance)
  • Marty CaganEmpowered (4 big risks: Value, Usability, Feasibility, Viability)

Tools & Platforms

  • Claude Projects — Simple orchestration with multiple agents in one project
  • LangChain — Framework for building agent chains
  • LangGraph — State machine orchestration for complex workflows
  • n8n / Zapier — No-code workflow automation (simpler orchestrations)
评估产品工作处于AI自动化(AI-first)还是AI重塑(AI-shaped)阶段,识别2026年五大PM能力差距,并推荐优先构建的能力以提升组织AI成熟度。
评估团队AI成熟度 选择下一个要构建的团队能力 区分AI自动化与AI重塑策略
skills/ai-shaped-readiness-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill ai-shaped-readiness-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "ai-shaped-readiness-advisor",
    "type": "interactive",
    "theme": "ai-agents",
    "intent": "Assess whether your product work is **\"AI-first\"** (using AI to automate existing tasks faster) or **\"AI-shaped\"** (fundamentally redesigning how product teams operate around AI capabilities). Use this to evaluate your readiness across **5 essential PM competencies for 2026**, identify gaps, and get concrete recommendations on which capability to build first.",
    "best_for": [
        "Assessing whether your team is AI-first or genuinely AI-shaped",
        "Identifying which of the 5 AI competencies to build next",
        "Understanding your product org's AI maturity honestly"
    ],
    "scenarios": [
        "My team uses AI tools but I'm not sure if we're working differently or just automating the same tasks",
        "I want to assess my product org's AI maturity and prioritize where to invest next quarter"
    ],
    "description": "Assess whether your product work is AI-first or AI-shaped. Use when evaluating AI maturity and choosing the next team capability to build.",
    "argument-hint": "[team or workflow context]",
    "estimated_time": "15-20 min"
}

Purpose

Assess whether your product work is "AI-first" (using AI to automate existing tasks faster) or "AI-shaped" (fundamentally redesigning how product teams operate around AI capabilities). Use this to evaluate your readiness across 5 essential PM competencies for 2026, identify gaps, and get concrete recommendations on which capability to build first.

Key Distinction: AI-first is cute (using Copilot to write PRDs faster). AI-shaped is survival (building a durable "reality layer" that both humans and AI trust, orchestrating AI workflows, compressing learning cycles).

This is not about AI tools—it's about organizational redesign around AI as co-intelligence. The interactive skill guides you through a maturity assessment, then recommends your next move.

Input

Works best with: A description of how your team currently uses AI in its product work — even 'barely' is a valid answer. Also useful: Team size, product domain, and which of the 5 competencies you suspect is weakest.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking how AI currently shows up in your team's day-to-day product work.

Example invocation: Assess my team: 6 PMs, we use ChatGPT for PRD drafts and meeting summaries but nothing in our discovery or delivery process has changed.

Key Concepts

AI-First vs. AI-Shaped

Dimension AI-First (Cute) AI-Shaped (Survival)
Mindset Automate existing tasks Redesign how work gets done
Goal Speed up artifact creation Compress learning cycles
AI Role Task assistant Strategic co-intelligence
Advantage Temporary efficiency gains Defensible competitive moat
Example "Copilot writes PRDs 2x faster" "AI agent validates hypotheses in 48 hours instead of 3 weeks"

Critical Insight: If a competitor can replicate your AI usage by throwing bodies at it, it's not differentiation—it's just efficiency (which becomes table stakes within months).


The 5 Essential PM Competencies (2026)

These competencies define AI-shaped product work. You'll assess your maturity on each.

1. Context Design

Building a durable "reality layer" that both humans and AI can trust—treating AI attention as a scarce resource and allocating it deliberately.

What it includes:

  • Documenting what's true vs. assumed
  • Immutable constraints (technical, regulatory, strategic)
  • Operational glossary (shared definitions)
  • Evidence standards (what counts as validation)
  • Context boundaries (what to persist vs. retrieve)
  • Memory architecture (short-term conversational + long-term persistent)
  • Retrieval strategies (semantic search, contextual retrieval)

Key Principle: "If you can't point to evidence, constraints, and definitions, you don't have context. You have vibes."

Critical Distinction: Context Stuffing vs. Context Engineering

  • Context Stuffing (AI-first): Jamming volume without intent ("paste entire PRD")
  • Context Engineering (AI-shaped): Shaping structure for attention (bounded domains, retrieve with intent)

The 5 Diagnostic Questions:

  1. What specific decision does this support?
  2. Can retrieval replace persistence?
  3. Who owns the context boundary?
  4. What fails if we exclude this?
  5. Are we fixing structure or avoiding it?

AI-first version: Pasting PRDs into ChatGPT; no context boundaries; "more is better" mentality AI-shaped version: CLAUDE.md files, evidence databases, constraint registries AI agents reference; two-layer memory architecture; Research→Plan→Reset→Implement cycle to prevent context rot

Deep Dive: See context-engineering-advisor for detailed guidance on diagnosing context stuffing and implementing memory architecture.


2. Agent Orchestration

Creating repeatable, traceable AI workflows (not one-off prompts).

What it includes:

  • Defined workflow loops: research → synthesis → critique → decision → log rationale
  • Each step shows its work (traceable reasoning)
  • Workflows run consistently (same inputs = predictable process)
  • Version-controlled prompts and agents

Key Principle: One-off prompts are tactical. Orchestrated workflows are strategic.

AI-first version: "Ask ChatGPT to analyze this user feedback" AI-shaped version: Automated workflow that ingests feedback, tags themes, generates hypotheses, flags contradictions, logs decisions


3. Outcome Acceleration

Using AI to compress learning cycles (not just speed up tasks).

What it includes:

  • Eliminate validation lag (PoL probes run in days, not weeks)
  • Remove approval delays (AI pre-validates against constraints)
  • Cut meeting overhead (async AI synthesis replaces status meetings)

Key Principle: Do less, purposefully. AI removes bottlenecks, not generates more work.

AI-first version: "AI writes user stories faster" AI-shaped version: "AI runs feasibility checks overnight, eliminating 2 weeks of technical discovery"


4. Team-AI Facilitation

Redesigning team systems so AI operates as co-intelligence, not an accountability shield.

What it includes:

  • Review norms (who checks AI outputs, when, how)
  • Evidence standards (AI must cite sources, not hallucinate)
  • Decision authority (AI recommends, humans decide—clear boundaries)
  • Psychological safety (team can challenge AI without feeling "dumb")

Key Principle: AI amplifies judgment, doesn't replace accountability.

AI-first version: "I used AI" as excuse for bad outputs AI-shaped version: Clear review protocols; AI outputs treated as drafts requiring human validation


5. Strategic Differentiation

Moving beyond efficiency to create defensible competitive advantages.

What it includes:

  • New customer capabilities (what can users do now that they couldn't before?)
  • Workflow rewiring (processes competitors can't replicate without full redesign)
  • Economics competitors can't match (10x cost advantage through AI)

Key Principle: "If a competitor can copy it by throwing bodies at it, it's not differentiation."

AI-first version: "We use AI to write better docs" AI-shaped version: "We validate product hypotheses in 2 days vs. industry standard 3 weeks—ship 6x more validated features per quarter"


Anti-Patterns (What This Is NOT)

  • Not about AI tools: Using Claude vs. ChatGPT doesn't matter. Redesigning workflows matters.
  • Not about speed: Writing PRDs 2x faster isn't strategic if PRDs weren't the bottleneck.
  • Not about automation: Automating bad processes just scales the bad.
  • Not about replacing humans: AI-shaped orgs augment judgment, not eliminate it.

When to Use This Skill

Use this when:

  • You're using AI tools but not seeing strategic advantage
  • You suspect you're "AI-first" (efficiency) but want to be "AI-shaped" (transformation)
  • You need to prioritize which AI capability to build next
  • Leadership asks "How are we using AI?" and you're not sure how to answer strategically
  • You want to assess team readiness for AI-powered product work

Don't use this when:

  • You haven't started using AI at all (start with basic tools first)
  • You're looking for tool recommendations (this is about organizational design, not tooling)
  • You need tactical "how to write a prompt" guidance (use skills for that)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill uses adaptive questioning to assess your maturity across 5 competencies, then recommends which to prioritize.

Facilitation Protocol (Mandatory)

  1. Ask exactly one question per turn.
  2. Wait for the user's answer before asking the next question.
  3. Use plain-language questions (no shorthand labels as the primary question). If needed, include an example response format.
  4. Show progress on every turn using user-facing labels:
    • Context Qx/8 during context gathering
    • Scoring Qx/5 during maturity scoring
    • Include "questions remaining" when practical.
  5. Do not use internal phase labels (like "Step 0") in user-facing prompts unless the user asks for internal structure details.
  6. For maturity scoring questions, present concise 1-4 choices first; share full rubric details only if requested.
  7. For context questions, offer concise numbered quick-select options when practical, plus Other (specify) for open-ended answers. Accept multi-select replies like 1,3 or 1 and 3.
  8. Give numbered recommendations only at decision points, not after every answer.
  9. Decision points include:
    • After the full context summary
    • After the 5-dimension maturity profile
    • During priority selection and action-plan path selection
  10. When recommendations are shown, enumerate clearly (1., 2., 3.) and accept selections like #1, 1, 1 and 3, 1,3, or custom text.
  11. If multiple options are selected, synthesize a combined path and continue.
  12. If custom text is provided, map it to the closest valid path and continue without forcing re-entry.
  13. Interruption handling is mandatory: if the user asks a meta question ("how many left?", "why this label?", "pause"), answer directly first, then restate current progress and resume with the pending question.
  14. If the user says to stop or pause, halt the assessment immediately and wait for explicit resume.
  15. If the user asks for "one question at a time," keep that mode for the rest of the session unless they explicitly opt out.
  16. Before any assessment question, give a short heads-up on time/length and let the user choose an entry mode.

Session Start: Heads-Up + Entry Mode (Mandatory)

Agent opening prompt (use this first):

"Quick heads-up before we start: this usually takes about 7-10 minutes and up to 13 questions total (8 context + 5 scoring).

How do you want to do this?

  1. Guided mode: I’ll ask one question at a time.
  2. Context dump: you paste what you already know, and I’ll skip anything redundant.
  3. Best guess mode: I’ll make reasonable assumptions where details are missing, label them, and keep moving."

Accept selections as #1, 1, 1 and 3, 1,3, or custom text.

Mode behavior:

  • If Guided mode: Run Step 0 as written, then scoring.
  • If Context dump: Ask for pasted context once, summarize it, identify gaps, and:
    • Skip any context questions already answered.
    • Ask only the minimum missing context needed (0-2 clarifying questions).
    • Move to scoring as soon as context is sufficient.
  • If Best guess mode: Ask for the smallest viable starting input (role/team + primary goal), then:
    • Infer missing details using reasonable defaults.
    • Label each inferred item as Assumption.
    • Include confidence tags (High, Medium, Low) for each assumption.
    • Continue without blocking on unknowns.

At the final summary, include an Assumptions to Validate section when context dump or best guess mode was used.


Step 0: Gather Context

Agent asks:

Collect context using this exact sequence, one question at a time:

  1. "Which AI tools are you using today?"
  2. "How does your team usually use AI today: one-off prompts, reusable templates, or multi-step workflows?"
  3. "Who uses AI consistently today: just you, PMs, or cross-functional teams?"
  4. "About how many PMs, engineers, and designers are on your team?"
  5. "What stage are you in: startup, growth, or enterprise?"
  6. "How are decisions made: centralized, distributed, or consensus-driven?"
  7. "What competitive advantage are you trying to build with AI?"
  8. "What's the biggest bottleneck slowing learning and iteration today?"

After question 8, summarize back in 4 lines:

  • Current AI usage pattern
  • Team context
  • Strategic intent
  • Primary bottleneck

Step 1: Context Design Maturity

Agent asks:

Let's assess your Context Design capability—how well you've built a "reality layer" that both humans and AI can trust, and whether you're doing context stuffing (volume without intent) or context engineering (structure for attention).

Which statement best describes your current state?

  1. Level 1 (AI-First / Context Stuffing): "I paste entire documents into ChatGPT every time I need something. No shared knowledge base. No context boundaries."

    • Reality: One-off prompting with no durability; "more is better" mentality
    • Problem: AI has no memory; you repeat yourself constantly; context stuffing degrades attention
    • Context Engineering Gap: No answers to the 5 diagnostic questions; persisting everything "just in case"
  2. Level 2 (Emerging / Early Structure): "We have some docs (PRDs, strategy memos), but they're scattered. No consistent format. Starting to notice context stuffing issues (vague responses, normalized retries)."

    • Reality: Context exists but isn't structured for AI consumption; no retrieval strategy
    • Problem: AI can't reliably find or trust information; mixing always-needed with episodic context
    • Context Engineering Gap: No context boundary owner; no distinction between persist vs. retrieve
  3. Level 3 (Transitioning / Context Engineering Emerging): "We've started using CLAUDE.md files and project instructions. Constraints registry exists. We're identifying what to persist vs. retrieve. Experimenting with Research→Plan→Reset→Implement cycle."

    • Reality: Structured context emerging, but not comprehensive; context boundaries defined but not fully enforced
    • Problem: Coverage is patchy; some areas well-documented, others vibe-driven; inconsistent retrieval practices
    • Context Engineering Progress: Can answer 3-4 of the 5 diagnostic questions; context boundary owner assigned; starting to use two-layer memory
  4. Level 4 (AI-Shaped / Context Engineering Mastery): "We maintain a durable reality layer: constraints registry (20+ entries), evidence database, operational glossary (30+ terms). Two-layer memory architecture (short-term conversational + long-term persistent via vector DB). Context boundaries defined and owned. AI agents reference these automatically. We use Research→Plan→Reset→Implement to prevent context rot."

    • Reality: Comprehensive, version-controlled context both humans and AI trust; retrieval with intent (not completeness)
    • Outcome: AI operates with high confidence; reduces hallucination and rework; token usage optimized; no context stuffing
    • Context Engineering Mastery: Can answer all 5 diagnostic questions; context boundary audited quarterly; quantitative efficiency tracking: (Accuracy × Coherence) / (Tokens × Latency)

Select your level: [1, 2, 3, or 4]

Note: If you selected Level 1-2 and struggle with context stuffing, consider using context-engineering-advisor to diagnose and fix Context Hoarding Disorder before proceeding.

User response: [Selection]

Agent records: Context Design maturity = [Level X]


Step 2: Agent Orchestration Maturity

Agent asks:

Now let's assess Agent Orchestration—whether you have repeatable AI workflows or just one-off prompts.

Which statement best describes your current state?

  1. Level 1 (AI-First): "I type prompts into ChatGPT as needed. No saved workflows or templates."

    • Reality: Tactical, ad-hoc usage
    • Problem: Inconsistent results; can't scale or audit
  2. Level 2 (Emerging): "I have a few saved prompts I reuse. Maybe some custom GPTs or Claude Projects."

    • Reality: Repeatable prompts, but not full workflows
    • Problem: Each step is manual; no orchestration
  3. Level 3 (Transitioning): "We've built some multi-step workflows (research → synthesis → critique). Tracked in tools like Notion or Linear."

    • Reality: Workflows exist but require manual handoffs
    • Problem: Still human-in-the-loop for every step; not fully automated
  4. Level 4 (AI-Shaped): "We have orchestrated AI workflows that run autonomously: research → synthesis → critique → decision → log rationale. Each step is traceable and version-controlled."

    • Reality: Workflows run consistently; show their work at each step
    • Outcome: Reliable, auditable, scalable AI processes

Select your level: [1, 2, 3, or 4]

User response: [Selection]

Agent records: Agent Orchestration maturity = [Level X]


Step 3: Outcome Acceleration Maturity

Agent asks:

Next, Outcome Acceleration—are you using AI to compress learning cycles, or just speed up tasks?

Which statement best describes your current state?

  1. Level 1 (AI-First): "AI helps me write docs faster (PRDs, user stories). Saves me a few hours per week."

    • Reality: Efficiency gains on artifact creation
    • Problem: Docs weren't the bottleneck; learning cycles unchanged
  2. Level 2 (Emerging): "AI helps with research and synthesis (summarize user feedback, analyze competitors). Saves research time."

    • Reality: Modest learning acceleration
    • Problem: Still sequential; AI doesn't eliminate validation lag
  3. Level 3 (Transitioning): "We use AI to run experiments faster (PoL probes, feasibility checks). Cut validation time from weeks to days."

    • Reality: Learning cycles compressing
    • Problem: Not yet systematic; only applied to some experiments
  4. Level 4 (AI-Shaped): "AI systematically removes bottlenecks: overnight feasibility checks, async synthesis replaces meetings, automated validation against constraints. Learning cycles 5-10x faster."

    • Reality: Fundamental redesign of how learning happens
    • Outcome: Ship validated features 6x faster than competitors

Select your level: [1, 2, 3, or 4]

User response: [Selection]

Agent records: Outcome Acceleration maturity = [Level X]


Step 4: Team-AI Facilitation Maturity

Agent asks:

Now assess Team-AI Facilitation—how well you've redesigned team systems for AI as co-intelligence.

Which statement best describes your current state?

  1. Level 1 (AI-First): "I use AI privately. Team doesn't know or doesn't use it. No shared norms."

    • Reality: Individual tool usage, no team integration
    • Problem: Inconsistent quality; no accountability for AI outputs
  2. Level 2 (Emerging): "Team uses AI, but no formal review process. 'I used AI' mentioned casually."

    • Reality: Awareness but no structure
    • Problem: AI outputs treated as final; errors slip through
  3. Level 3 (Transitioning): "We have review norms emerging (AI outputs are drafts, not finals). Evidence standards discussed but not codified."

    • Reality: Cultural shift underway
    • Problem: Norms are informal; not everyone follows them
  4. Level 4 (AI-Shaped): "Clear protocols: AI outputs require human validation, evidence standards codified, decision authority explicit (AI recommends, humans decide). Team treats AI as co-intelligence."

    • Reality: AI integrated into team operating system
    • Outcome: High-quality outputs; psychological safety maintained

Select your level: [1, 2, 3, or 4]

User response: [Selection]

Agent records: Team-AI Facilitation maturity = [Level X]


Step 5: Strategic Differentiation Maturity

Agent asks:

Finally, Strategic Differentiation—are you creating defensible competitive advantages, or just efficiency gains?

Which statement best describes your current state?

  1. Level 1 (AI-First): "We use AI to work faster (write better docs, respond to customers quicker). Efficiency gains only."

    • Reality: Table-stakes improvements
    • Problem: Competitors can copy this within months
  2. Level 2 (Emerging): "AI enables us to do things we couldn't before (analyze 10x more data, test more hypotheses). New capabilities, but competitors could replicate."

    • Reality: Capability expansion, but not defensible
    • Problem: No moat; competitors hire more people to match
  3. Level 3 (Transitioning): "We've redesigned some workflows around AI (e.g., validate hypotheses in 2 days vs. 3 weeks). Starting to create separation."

    • Reality: Workflow advantages emerging
    • Problem: Not yet systematic; only applied in pockets
  4. Level 4 (AI-Shaped): "We've fundamentally rewired how we operate: customers get capabilities they can't get elsewhere, our learning cycles are 10x faster than industry standard, our economics are 5x better. Competitors can't replicate without full org redesign."

    • Reality: Defensible competitive moat
    • Outcome: Strategic advantage that compounds over time

Select your level: [1, 2, 3, or 4]

User response: [Selection]

Agent records: Strategic Differentiation maturity = [Level X]


Step 6: Assess Maturity Profile

Agent synthesizes:

Here's your AI-Shaped Readiness Profile:

┌─────────────────────────────┬───────┬──────────┐
│ Competency                  │ Level │ Maturity │
├─────────────────────────────┼───────┼──────────┤
│ 1. Context Design           │   X   │ [Label]  │
│ 2. Agent Orchestration      │   X   │ [Label]  │
│ 3. Outcome Acceleration     │   X   │ [Label]  │
│ 4. Team-AI Facilitation     │   X   │ [Label]  │
│ 5. Strategic Differentiation│   X   │ [Label]  │
└─────────────────────────────┴───────┴──────────┘

Overall Assessment: [AI-First / Emerging / Transitioning / AI-Shaped]

Maturity Labels:

  • Level 1: AI-First (efficiency only)
  • Level 2: Emerging (early capabilities)
  • Level 3: Transitioning (redesign underway)
  • Level 4: AI-Shaped (strategic transformation)

Overall Assessment Logic:

  • AI-First: Average level 1-1.5 (mostly Level 1s)
  • Emerging: Average level 2-2.5 (mostly Level 2s)
  • Transitioning: Average level 3-3.5 (mostly Level 3s)
  • AI-Shaped: Average level 3.5-4 (mostly Level 4s)

Step 7: Identify Priority Gap

Agent asks:

Based on your maturity profile, which competency should you prioritize first?

Agent analyzes dependencies:

Dependency Logic:

  1. Context Design is foundational — If Level 1-2, this must be priority #1 (Agent Orchestration and Outcome Acceleration depend on it)
  2. Agent Orchestration enables Outcome Acceleration — If Context Design is Level 3+, but Agent Orchestration is Level 1-2, prioritize orchestration
  3. Team-AI Facilitation is parallel — Can be developed alongside others, but required for scale
  4. Strategic Differentiation requires Levels 3+ on others — Don't focus here until foundational competencies are built

Agent recommends:

Based on your profile, I recommend focusing on [Competency Name] first because:

Option 1: Context Design (if Level 1-2)

  • Why: Without durable context, AI operates on vibes. Every workflow will be fragile.
  • Impact: Unlocks Agent Orchestration and Outcome Acceleration
  • Next Steps: Build CLAUDE.md files, start constraints registry, create operational glossary

Option 2: Agent Orchestration (if Context is 3+, but Orchestration is 1-2)

  • Why: You have context, but no repeatable workflows. Scaling requires orchestration.
  • Impact: Turn one-off prompts into reliable, traceable workflows
  • Next Steps: Document your most frequent AI workflow, version-control prompts, add traceability

Option 3: Outcome Acceleration (if Context + Orchestration are 3+)

  • Why: You have infrastructure; now compress learning cycles
  • Impact: Strategic advantage emerges from speed-to-learning
  • Next Steps: Identify biggest bottleneck in learning cycle, design AI workflow to eliminate it

Option 4: Team-AI Facilitation (if usage is individual, not team-wide)

  • Why: Can't scale if only you're AI-shaped; team must adopt
  • Impact: Organizational transformation, not just individual productivity
  • Next Steps: Establish review norms, codify evidence standards, create decision authority framework

Option 5: Strategic Differentiation (if all others are 3+)

  • Why: You have the foundation; now build the moat
  • Impact: Create defensible competitive advantage
  • Next Steps: Identify workflow competitors can't replicate, design AI-enabled customer capabilities

Which would you like to focus on?

Options:

  1. Accept recommendation — [Agent provides detailed action plan]
  2. Choose different priority — [Agent warns about dependencies but allows override]
  3. Focus on multiple simultaneously — [Agent suggests parallel tracks if feasible]

User response: [Selection]


Step 8: Generate Action Plan

Agent provides tailored action plan based on selected priority:


If Priority = Context Design

Goal: Build a durable "reality layer" that both humans and AI trust—move from context stuffing to context engineering.

Pre-Phase: Diagnose Context Stuffing (If Needed) If you're at Level 1-2, first diagnose context stuffing symptoms:

  1. Run through the 5 diagnostic questions (see context-engineering-advisor)
  2. Identify what you're persisting that should be retrieved
  3. Assign context boundary owner
  4. Create Context Manifest (what's always-needed vs. episodic)

Phase 1: Document Constraints (Week 1)

  1. Create a constraints registry:
    • Technical constraints (APIs, data models, performance limits)
    • Regulatory constraints (GDPR, HIPAA, etc.)
    • Strategic constraints (we will/won't build X)
  2. Apply diagnostic question #4 to each constraint: "What fails if we exclude this?"
  3. Format: Structured file AI agents can parse (YAML, JSON, or Markdown with frontmatter)
  4. Version control in Git

Phase 2: Build Operational Glossary (Week 2)

  1. List top 20-30 terms your team uses (e.g., "user," "customer," "activation," "churn")
  2. Define each unambiguously (avoid "it depends")
  3. Include edge cases and exceptions
  4. Add to CLAUDE.md or project instructions
  5. This becomes your long-term persistent memory (Declarative Memory)

Phase 3: Establish Evidence Standards + Context Boundaries (Week 3)

  1. Define what counts as validation:
    • User feedback: "X users said Y" (with quotes)
    • Analytics: "Metric Z changed by N%" (with dashboard link)
    • Competitive intel: "Competitor A launched B" (with source)
  2. Reject: "I think," "We feel," "It seems like"
  3. Define context boundaries using the 5 diagnostic questions:
    • What specific decision does each piece of context support?
    • Can retrieval replace persistence?
    • Who owns the context boundary?
  4. Create Context Manifest document
  5. Codify in team docs

Phase 4: Implement Memory Architecture + Workflows (Week 4)

  1. Set up two-layer memory:
    • Short-term (conversational): Summarize/truncate older parts of conversation
    • Long-term (persistent): Constraints registry + operational glossary (consider vector database for retrieval)
  2. Implement Research→Plan→Reset→Implement cycle:
    • Research: Allow chaotic context gathering
    • Plan: Synthesize into high-density SPEC.md or PLAN.md
    • Reset: Clear context window
    • Implement: Use only the plan as context
  3. Update AI prompts to reference constraints registry and glossary
  4. Test: Ask AI to cite constraints when making recommendations
  5. Measure: % of AI outputs that cite evidence vs. hallucinate; token usage efficiency

Success Criteria:

  • ✅ Constraints registry has 20+ entries
  • ✅ Operational glossary has 20-30 terms
  • ✅ Evidence standards documented and shared
  • ✅ Context Manifest created (always-needed vs. episodic)
  • ✅ Context boundary owner assigned
  • ✅ Two-layer memory architecture implemented
  • ✅ Research→Plan→Reset→Implement cycle tested on 1 workflow
  • ✅ AI agents reference these automatically
  • ✅ Token usage down 30%+ (less context stuffing)
  • ✅ Output consistency up (fewer retries)

Related Skills:

  • context-engineering-advisor (Interactive) — Deep dive on diagnosing context stuffing and implementing memory architecture
  • problem-statement.md — Define constraints before framing problems
  • epic-hypothesis.md — Evidence-based hypothesis writing

If Priority = Agent Orchestration

Goal: Turn one-off prompts into repeatable, traceable AI workflows.

Phase 1: Map Current Workflows (Week 1)

  1. Pick your most frequent AI use case (e.g., "analyze user feedback")
  2. Document every step you currently take:
    • Copy/paste feedback into ChatGPT
    • Ask for themes
    • Manually categorize
    • Write summary
  3. Identify pain points (manual handoffs, inconsistent results)

Phase 2: Design Orchestrated Workflow (Week 2)

  1. Define workflow loop:
    • Research: AI reads all feedback (structured input)
    • Synthesis: AI identifies themes (with evidence)
    • Critique: AI flags contradictions or weak signals
    • Decision: Human reviews and decides next steps
    • Log: AI records rationale and sources
  2. Each step must be traceable (show sources, reasoning)

Phase 3: Build and Test (Week 3)

  1. Implement workflow using:
    • Claude Projects (if simple)
    • Custom GPTs (if moderate)
    • API orchestration (if complex)
  2. Run on 3 past examples; compare to manual process
  3. Measure: Time saved, consistency improved, traceability added

Phase 4: Document and Scale (Week 4)

  1. Version-control prompts (Git)
  2. Document workflow steps for team
  3. Train 2 teammates; observe results
  4. Iterate based on feedback

Success Criteria:

  • ✅ At least 1 workflow runs consistently (same inputs → predictable process)
  • ✅ Each step is traceable (AI cites sources)
  • ✅ Team can replicate workflow without your involvement

Related Skills:

  • pol-probe-advisor.md — Use orchestrated workflows for validation experiments

If Priority = Outcome Acceleration

Goal: Use AI to compress learning cycles, not just speed up tasks.

Phase 1: Identify Bottleneck (Week 1)

  1. Map your current learning cycle (e.g., hypothesis → experiment → analysis → decision)
  2. Time each step
  3. Identify slowest step (usually: validation lag, approval delays, or meeting overhead)

Phase 2: Design AI Intervention (Week 2)

  1. Ask: "What if this step happened overnight?"
    • Feasibility checks: AI spike in 2 hours vs. 2 days
    • User research synthesis: AI analysis in 1 hour vs. 1 week
    • Approval pre-checks: AI validates against constraints before meeting
  2. Design minimal AI workflow to eliminate bottleneck

Phase 3: Run Pilot (Week 3)

  1. Test AI intervention on 1 real initiative
  2. Measure cycle time: before vs. after
  3. Validate quality: Did AI maintain rigor, or cut corners?

Phase 4: Scale (Week 4)

  1. If successful (cycle time down 50%+, quality maintained), apply to 3 more initiatives
  2. Document workflow
  3. Train team

Success Criteria:

  • ✅ Learning cycle compressed by 50%+ on at least 1 initiative
  • ✅ Quality maintained (no shortcuts that compromise rigor)
  • ✅ Team adopts the accelerated workflow

Related Skills:

  • pol-probe.md — Use AI to run PoL probes faster
  • discovery-process.md — Compress discovery cycles with AI

If Priority = Team-AI Facilitation

Goal: Redesign team systems so AI operates as co-intelligence, not accountability shield.

Phase 1: Establish Review Norms (Week 1)

  1. Codify rule: "AI outputs are drafts, not finals"
  2. Define review protocol:
    • Who reviews AI outputs? (peer, lead PM, cross-functional partner)
    • When? (before sharing externally, before decisions)
    • What to check? (accuracy, completeness, evidence citation)
  3. Share with team, get buy-in

Phase 2: Set Evidence Standards (Week 2)

  1. AI must cite sources (no hallucinations)
  2. Reject outputs that say "I think" or "it seems"
  3. Require: "According to [source], [fact]"
  4. Add to team operating docs

Phase 3: Define Decision Authority (Week 3)

  1. Clarify: AI recommends, humans decide
  2. Document who has authority to override AI recommendations (PM, team lead, cross-functional consensus)
  3. Create escalation path (what if AI and human disagree?)

Phase 4: Build Psychological Safety (Week 4)

  1. Team exercise: Share an AI mistake you caught (normalize catching errors)
  2. Reward critical thinking ("Good catch on that AI hallucination!")
  3. Avoid: "Why didn't you just use AI?" (shaming)

Success Criteria:

  • ✅ Review norms documented and followed by team
  • ✅ Evidence standards codified
  • ✅ Decision authority clear
  • ✅ Team comfortable challenging AI outputs

Related Skills:

  • problem-statement.md — Evidence-based problem framing
  • epic-hypothesis.md — Testable, evidence-backed hypotheses

If Priority = Strategic Differentiation

Goal: Create defensible competitive advantages, not just efficiency gains.

Phase 1: Identify Moat Opportunities (Week 1)

  1. Ask: "What could we do with AI that competitors can't replicate by adding headcount?"
    • New customer capabilities (e.g., "AI advisor suggests personalized roadmap")
    • Workflow rewiring (e.g., "Validate product ideas in 2 days vs. 3 weeks")
    • Economics shift (e.g., "Deliver enterprise features at SMB prices via AI automation")
  2. List 5 candidates
  3. Prioritize by defensibility (how hard to copy?)

Phase 2: Design AI-Enabled Capability (Week 2)

  1. Pick top candidate
  2. Design end-to-end workflow:
    • What does customer experience?
    • What does AI do behind the scenes?
    • What human judgment is required?
  3. Sketch MVP (minimum viable moat)

Phase 3: Build and Test (Weeks 3-4)

  1. Build prototype (can be PoL probe, not production)
  2. Test with 5 customers
  3. Measure: Does this create value competitors can't match?

Phase 4: Validate Moat (Week 5)

  1. Ask: "How would a competitor replicate this?"
    • If answer is "hire more people," it's not a moat
    • If answer is "redesign their entire org," you have a moat
  2. Document competitive analysis
  3. Decide: Build full version, pivot, or kill

Success Criteria:

  • ✅ Identified at least 1 AI-enabled capability competitors can't easily copy
  • ✅ Validated with customers (they see the value)
  • ✅ Confirmed defensibility (competitor analysis)

Related Skills:

  • positioning-statement.md — Articulate your AI-driven differentiation
  • jobs-to-be-done.md — Understand what customers hire your AI capabilities to do

Step 9: Track Progress (Optional)

Agent offers:

Would you like me to create a progress tracker for your AI-shaped transformation?

Tracker includes:

  • Current maturity levels (baseline)
  • Target maturity levels (goal state)
  • Action plan milestones (from Step 8)
  • Review cadence (weekly, monthly)

Options:

  1. Yes, create tracker — [Agent generates Markdown checklist]
  2. No, I'll track separately — [Agent provides summary]

Examples

Example 1: Early-Stage Startup (AI-First → Emerging)

Context:

  • Team: 2 PMs, 5 engineers
  • AI Usage: ChatGPT for writing PRDs, occasional Copilot usage
  • Goal: Move faster than larger competitors

Assessment Results:

  • Context Design: Level 1 (no structured context)
  • Agent Orchestration: Level 1 (one-off prompts)
  • Outcome Acceleration: Level 1 (docs faster, but learning cycles unchanged)
  • Team-AI Facilitation: Level 2 (team uses AI, but no norms)
  • Strategic Differentiation: Level 1 (efficiency only)

Recommendation: Focus on Context Design first.

Action Plan (Week 1-4):

  • Week 1: Create constraints registry (10 technical constraints)
  • Week 2: Build operational glossary (15 terms)
  • Week 3: Establish evidence standards
  • Week 4: Add context to CLAUDE.md files

Outcome: After 4 weeks, Context Design → Level 3. Unlocks Agent Orchestration next quarter.


Example 2: Growth-Stage Company (Transitioning → AI-Shaped)

Context:

  • Team: 10 PMs, 50 engineers, 5 designers
  • AI Usage: Claude Projects for research, custom workflows emerging
  • Goal: Build defensible AI advantage before IPO

Assessment Results:

  • Context Design: Level 3 (structured context, not comprehensive)
  • Agent Orchestration: Level 3 (some workflows, manual handoffs)
  • Outcome Acceleration: Level 2 (modest gains, not systematic)
  • Team-AI Facilitation: Level 3 (norms emerging, not codified)
  • Strategic Differentiation: Level 2 (new capabilities, but copyable)

Recommendation: Focus on Outcome Acceleration (foundation is solid; now compress learning cycles).

Action Plan (Week 1-4):

  • Week 1: Identify bottleneck (discovery cycles take 3 weeks)
  • Week 2: Design AI workflow to run overnight feasibility checks
  • Week 3: Pilot on 1 initiative (cut cycle to 5 days)
  • Week 4: Scale to 3 initiatives

Outcome: Learning cycles 5x faster → strategic separation from competitors → Level 4 Outcome Acceleration + Level 3 Strategic Differentiation.


Example 3: Enterprise Company (AI-First, Scattered Usage)

Context:

  • Team: 50 PMs, 300 engineers
  • AI Usage: Individual PMs use various tools, no consistency
  • Goal: Standardize AI usage, create cross-functional workflows

Assessment Results:

  • Context Design: Level 2 (docs exist, not structured for AI)
  • Agent Orchestration: Level 1 (no shared workflows)
  • Outcome Acceleration: Level 1 (efficiency only)
  • Team-AI Facilitation: Level 1 (private usage, no norms)
  • Strategic Differentiation: Level 1 (no advantage)

Recommendation: Focus on Team-AI Facilitation first (distributed team needs shared norms before building infrastructure).

Action Plan (Week 1-4):

  • Week 1: Establish review norms (AI outputs are drafts)
  • Week 2: Set evidence standards (AI must cite sources)
  • Week 3: Define decision authority (AI recommends, leads decide)
  • Week 4: Pilot with 3 teams, gather feedback

Outcome: Team-AI Facilitation → Level 3. Creates foundation for Context Design and Agent Orchestration next.


Common Pitfalls

1. Mistaking Efficiency for Differentiation

Failure Mode: "We use AI to write PRDs 2x faster—we're AI-shaped!"

Consequence: Competitors copy within 3 months; no lasting advantage.

Fix: Ask: "If a competitor threw 2x more people at this, could they match us?" If yes, it's efficiency (table stakes), not differentiation.


2. Skipping Context Design

Failure Mode: Building Agent Orchestration workflows without durable context.

Consequence: AI workflows are fragile (context changes break everything).

Fix: Context Design is foundational. Don't skip it. Build constraints registry, glossary, evidence standards first.


3. Individual Usage, Not Team Transformation

Failure Mode: "I'm AI-shaped, but my team isn't."

Consequence: Can't scale; workflows die when you're on vacation.

Fix: Prioritize Team-AI Facilitation. Shared norms > individual productivity.


4. Focusing on Tools, Not Workflows

Failure Mode: "Should we use Claude or ChatGPT?"

Consequence: Tool debates distract from organizational redesign.

Fix: Tools don't matter. Workflows matter. Focus on redesigning how work gets done, not which AI you use.


5. Speed Over Learning

Failure Mode: "AI helps us ship faster!"

Consequence: Ship the wrong thing faster (if you're not compressing learning cycles).

Fix: Outcome Acceleration is about learning faster, not building faster. Validate hypotheses in days, not weeks.


References

Related Skills

  • context-engineering-advisor (Interactive) — Deep dive on Context Design competency: Diagnose context stuffing, implement memory architecture, use Research→Plan→Reset→Implement cycle
  • problem-statement (Component) — Evidence-based problem framing (Context Design)
  • epic-hypothesis (Component) — Testable hypotheses with evidence standards
  • pol-probe-advisor (Interactive) — Use AI to compress validation cycles (Outcome Acceleration)
  • discovery-process (Workflow) — Apply AI-shaped principles to discovery
  • positioning-statement (Component) — Articulate your AI-driven differentiation (Strategic Differentiation)

External Frameworks

Further Reading

  • Ethan MollickCo-Intelligence (on AI as co-intelligence, not replacement)
  • Shreyas Doshi — Twitter threads on PM judgment augmentation with AI
  • Lenny Rachitsky — Newsletter interviews with AI-forward PMs
基于高度和视野两个维度的思维模型,用于诊断从产品经理到总监的转型痛点。通过区分范围与时间视角,帮助识别领导力差距,解决组织方向模糊或决策摩擦问题。
诊断从PM到总监的角色转型困难 分析职责范围(Scope)与时间规划(Horizon)的匹配度 在组织方向不明确时应用级联上下文地图
skills/altitude-horizon-framework/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill altitude-horizon-framework -g -y
SKILL.md
Frontmatter
{
    "name": "altitude-horizon-framework",
    "type": "component",
    "theme": "career-leadership",
    "intent": "Defines the two-axis mental model that distinguishes Director-level thinking from PM thinking: **Altitude** (how wide you zoom out) and **Horizon** (how far ahead you look). Use this to understand what actually changes in the transition, diagnose which transition zone is creating friction, and apply the Cascading Context Map when organizational direction is vague or absent.",
    "best_for": [
        "Understanding what actually changes when you move from PM to Director",
        "Diagnosing which transition zone is creating friction in your role",
        "Applying the Cascading Context Map when organizational direction is vague"
    ],
    "scenarios": [
        "I'm a senior PM trying to understand what changes when I become a Director",
        "I'm newly promoted to Director and something isn't clicking — help me diagnose it",
        "My team has no clear direction and I need to create context from a vague company strategy"
    ],
    "description": "Understand the PM-to-Director transition through altitude and horizon thinking. Use when diagnosing scope, time-horizon, or leadership-level gaps.",
    "estimated_time": "10-15 min"
}

Purpose

Defines the two-axis mental model that distinguishes Director-level thinking from PM thinking: Altitude (how wide you zoom out) and Horizon (how far ahead you look). Use this to understand what actually changes in the transition, diagnose which transition zone is creating friction, and apply the Cascading Context Map when organizational direction is vague or absent.

This is not a seniority hierarchy. A PM operating at the right altitude for their role is doing excellent work. A Director operating at PM altitude is leaving their actual job undone.

Input

Nothing required — this is a reference framework you can read start to finish. Also useful: Your current situation (role, the transition friction you're feeling, a decision you're weighing). With that, the framework can be applied directly to diagnose which transition zone you're in.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. Read it as a mental model; pair it with director-readiness-advisor for guided coaching.

Example invocation: Apply the altitude-horizon framework to my situation: senior PM, just inherited two more teams, drowning in delivery detail.

Key Concepts

The Two Axes

Altitude — Scope

  • PM altitude: Close to the ground. Customer problems, individual features, sprint priorities, specific team dynamics.
  • Director altitude: High-level view. Product portfolio, cross-functional systems, organizational dynamics, budget allocation, market positioning.
  • The shift is not about losing empathy for customers — it's about zooming out to see the entire restaurant, not just one table.

Horizon — Time

  • PM horizon: Days, weeks, sprints. A quarter at most.
  • Director horizon: Quarter as the starting point. Annual planning cycles, multi-year strategy, market shifts.
  • Directors plan for where the product ecosystem needs to be in a year, then work backward.

The Waiter vs. Restaurant Operator

The sharpest analogy for the role shift:

Dimension PM (Waiter) Director (Restaurant Operator)
Focus Individual diner experience Entire system — staffing, margins, menu, suppliers
Authority Influence without control Portfolio decisions, budget, resource allocation
Success metric Table seven is happy Restaurant is profitable, consistent, and scalable
Relationship to customers Direct, daily, intimate Aggregate patterns, buyer personas, market cohorts
Failure mode Ignoring Table Seven's needs Obsessing over Table Seven's lemons

The waiter excels at translating the experience of individual diners. The operator isn't ignoring diners — they're asking different questions: "Are we overspending on ingredients? Is a 75-page menu confusing customers? Do we need another server for the dinner rush?" Neither question is more important in absolute terms. They're appropriate to different roles.


Four Transition Zones

The PM → Director shift requires movement across four zones. Most people struggle with one or two more than the others — diagnosing which one is the leverage point.

Zone 1 — Thinking Altitude

  • Stop: Solving individual customer problems directly
  • Start: Designing systems and teams that solve classes of problems

Zone 2 — Persona Shift

  • Stop: Obsessing over individual user personas and daily customer touchpoints
  • Start: Thinking in buyer personas, market cohorts, organizational stakeholders, and executive dynamics

Zone 3 — Hero Syndrome Recovery

  • Stop: Being the person who saves the day and earns the pat on the back
  • Start: Getting satisfaction from team success — your product is your people, not the roadmap

Zone 4 — Direction Creation

  • Stop: Waiting for clear direction from above before moving
  • Start: Creating context cascades that translate company strategy into team clarity, even when inputs are incomplete

Named Failure Modes

Hero Syndrome What it looks like: Jumping in to solve problems directly. Staying close to the tactical work. Wanting visibility on individual wins. Why it happens: PMs are trained to be helpful and responsive. Directors get fewer pats on the back, so they regress to the old reward loop. The cost: You under-perform as a Director while over-functioning as a senior IC. Your team doesn't develop because you're in their way.

Allergic to Process What it looks like: Resisting shared structures. Letting high-performing PMs run their own playbooks independently. Why it happens: PMs naturally resist bureaucracy. Early director permissiveness can feel like "great leadership" and "trusting the team." The cost: Stakeholders across marketing, finance, and leadership can't synthesize inconsistent outputs. Without shared processes, teams become "monkeys in the room breaking glass."

People-Pleaser Leadership What it looks like: Wanting the team to like you. Avoiding hard feedback. Saying yes to stakeholder requests to preserve relationships. Why it happens: The skills that made you a great PM — listening, empathy, responsiveness — become liabilities at organizational scale. The cost: You confuse "popular" with "effective." Respect is built through clarity and hard calls, not niceness.

Instant Gratification Trap What it looks like: Reading leadership books, collecting certifications, asking "what do I need to do to get promoted?" Why it happens: PMs are good at optimization. They try to shortcut the experience requirement. The cost: Director readiness requires war stories and lived humility. You can study your way to fluency in the vocabulary, but not to readiness for the role.

Black-and-White Thinking What it looks like: "This seems like an obvious decision." "Why can't we fund both?" "Why is everything so political here?" Why it happens: PMs operate in cleaner problem spaces with clearer cause-and-effect. Director decisions involve competing constraints, limited information, and organizational dynamics. The cost: Fast decisions with low confidence create downstream chaos. The grayscale is not a failure of leadership — it's the actual terrain.


The Cascading Context Map

When organizational direction is vague or absent, Directors don't wait — they cascade.

The six steps:

  1. Listen to the top-level strategy — QBRs, company messaging, executive communications
  2. Extract key priorities leadership stated — Identify 3–5 themes, not 20 bullet points
  3. Map the second layer: "How does our business unit accomplish these objectives?"
  4. Map the third layer: "How does our product portfolio accomplish that?"
  5. Map the fourth layer: "What are my team's specific accountabilities that drive success at layer three?"
  6. Communicate the cascade to the team — Not just what to do, but why it connects upward

What this fixes: Teams "wandering in the wilderness" — shipping work that doesn't connect to strategy because the context was never translated for them.

The core principle: Even with incomplete direction from above, a Director's job is to fill the gap downward. Waiting for perfect clarity is a PM habit. Creating imperfect-but-useful clarity is a Director skill.


Application

Using This Framework as a PM (Pre-Transition)

  1. Identify which transition zone you're weakest in — not to act on it yet, but to know what to observe
  2. Use 1-on-1s with your manager to practice Zone 4: "How does my work connect to business strategy? What's the organizational context I'm not seeing?"
  3. Watch for Hero Syndrome habits now: do you jump in to solve things that others could solve with your coaching?
  4. Don't over-invest in Director thinking while you're still in a PM role. Serve your current scope with full commitment — director altitude will be available when the context requires it

Using This Framework as a Newly Promoted Director

  1. First 30 days: Draw your new Altitude & Horizon map. Who are your new stakeholders? What does a quarter-to-annual planning horizon actually look like in this organization?
  2. First 60 days: Identify your Hero Syndrome triggers. When do you feel the pull to jump in directly instead of coaching?
  3. First 90 days: Run your first Cascading Context Map. Even if company strategy is unclear, make your best translation and share it with your team
  4. Ongoing: When friction appears, name which transition zone it lives in. Diagnosis before prescription

Running a Cascading Context Map

Use when your team is unclear on what organizational strategy means for their work.

## Context Cascade

**Company Priority:** [What leadership said — in their words]
**Business Unit Translation:** [How your BU contributes to that priority]
**Product Portfolio Translation:** [How your products contribute to that]
**Team Accountabilities:** [What each team owns specifically]
**Why this matters:** [The so-what for your team — what changes, what stays the same]

One page is better than ten. The goal is clarity, not comprehensiveness.


Examples

See examples/sample.md for a full worked scenario with a completed Cascading Context Map and anti-pattern contrast.

Good: Director Creates Clarity from a Vague Company Priority

Situation: CEO announces at QBR: "We're doubling down on enterprise." Three PMs ask their Director: "What does that mean for our roadmaps?"

PM response (wrong altitude): "Let's add enterprise features to our sprint backlogs."

Director response (right altitude): Runs a Cascading Context Map. Translates: "Enterprise means larger deal sizes, longer sales cycles, and more integration requirements. For our portfolio: Product A owns the admin controls story, Product B owns the API documentation story, Product C owns the security certification story. Here's what changes in Q3 planning and what doesn't."

Why it works: Director didn't wait for more clarity. They created it from available signal.


Bad: Hero Syndrome in Action

Situation: A PM on the team is struggling with a difficult stakeholder relationship.

Director response (wrong): "Let me just talk to that stakeholder directly — I'll get it sorted out."

Director response (right): "Walk me through what you've tried. Let's figure out where it broke down and what you'll do differently."

Why it matters: The first response solves the problem and creates dependency. The second response grows the PM. Directors who rescue too often build teams that can't function without them.


Good: Shifting from Waiter to Operator

Situation: A high-performing PM insists on documenting requirements in a different format from the rest of the team because "my stakeholders prefer it."

Director response (wrong): "That's fine, she's our best PM — if it works for her team, let it go."

Director response (right): "Joe is crushing it individually. But when marketing tries to synthesize across all three PMs' work, they can't. Shared process isn't bureaucracy — it's what makes the system legible to everyone outside it."

Why it matters: Protecting high-performer exceptions creates invisible coordination costs. The Restaurant Operator's job is the system, not the star waiter.


Common Pitfalls

Pitfall 1: Altitude Theater

Symptom: Using strategy language ("portfolio," "ecosystem," "long-term vision") while still making sprint-level decisions

Consequence: You sound like a Director but function like a PM. Your team is confused about who's actually deciding and at what level.

Fix: If you're in the details, own it. If you're not, delegate it fully. Mixing altitude levels without signaling creates ambiguity that erodes team trust.


Pitfall 2: One-and-Done Context Cascade

Symptom: Running the Cascading Context Map once at annual planning, then never revisiting it

Consequence: Team aligns in Q1 and drifts as strategy evolves. By Q3, team work is decoupled from current priorities.

Fix: Revisit the cascade at major inflection points — quarterly planning, significant exec changes, pivots, or org restructuring.


Pitfall 3: Confusing Kindness with Leadership

Symptom: Shielding the team from hard decisions, over-explaining constraints you're holding, softening feedback into meaninglessness

Consequence: Team operates without accurate context; trust erodes when reality eventually lands without warning.

Fix: Be transparent about the "why" behind hard decisions. You don't need to share everything — but what you share should be honest and actionable.


Pitfall 4: Premature Director Thinking as a PM

Symptom: Spending PM years worried about portfolio strategy, organizational dynamics, and "thinking above your pay grade"

Consequence: You under-serve your current role. PMs who think like Directors often miss the customer-level signal their actual role requires.

Fix: Play your current role with full commitment. The transition will demand Director thinking soon enough — you'll be ready because you did your PM work well, not because you rehearsed the Director role prematurely.


References

Related Skills

  • skills/director-readiness-advisor/SKILL.md — Interactive advisor that uses this framework to diagnose and coach your specific transition situation

Source Material

External Frameworks

  • Marty Cagan, Empowered — Organizational dynamics and role clarity in product leadership
  • Julie Zhuo, The Making of a Manager — IC-to-manager transition with practical war stories
  • Michael Watkins, The First 90 Days — Structured approach to leadership transitions
诊断SaaS业务健康度,综合评估增长、留存、单位经济及资本效率。用于识别系统性问题、确定修复优先级,并为董事会会议或融资准备提供全面的健康评分卡。
准备业务审查报告 优先处理紧急业务修复 董事会会议或季度复盘前 融资准备阶段
skills/business-health-diagnostic/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill business-health-diagnostic -g -y
SKILL.md
Frontmatter
{
    "name": "business-health-diagnostic",
    "type": "interactive",
    "theme": "finance-metrics",
    "intent": "Diagnose overall SaaS business health by analyzing growth, retention, unit economics, and capital efficiency metrics together. Use this to identify problems early, prioritize actions by urgency, and deliver a comprehensive health scorecard for board meetings, quarterly reviews, or fundraising preparation.",
    "best_for": [
        "Getting a complete read on your SaaS business health across all dimensions",
        "Identifying which metrics are red flags vs. leading indicators",
        "Preparing for a board meeting or investor review"
    ],
    "scenarios": [
        "Our growth is strong but we're burning cash fast — I need to understand our unit economics before the board meeting",
        "I'm preparing for a Series A board meeting and need to assess our business health across growth, retention, and efficiency"
    ],
    "description": "Diagnose SaaS business health across growth, retention, efficiency, and capital. Use when preparing a business review or prioritizing urgent fixes.",
    "argument-hint": "[metrics or business context]",
    "estimated_time": "20-30 min"
}

Purpose

Diagnose overall SaaS business health by analyzing growth, retention, unit economics, and capital efficiency metrics together. Use this to identify problems early, prioritize actions by urgency, and deliver a comprehensive health scorecard for board meetings, quarterly reviews, or fundraising preparation.

This is not a single-metric check—it's a holistic diagnostic that connects revenue, retention, economics, and efficiency to reveal systemic issues and opportunities.

Input

Works best with: Whatever business metrics you have access to — growth rate, NRR/GRR, CAC payback, burn multiple, runway. Partial data is fine; the diagnostic flags what's missing. Also useful: The occasion (board meeting, quarterly review, fundraise prep) and what you already suspect is wrong.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The diagnostic opens by asking your company stage and which metric families you can pull.

Example invocation: Run a health check: $8M ARR, 60% YoY growth, NRR 96%, CAC payback 21 months, 14 months runway — board meeting in 3 weeks.

Key Concepts

The Business Health Framework

A SaaS business is healthy when four dimensions work together:

  1. Growth & Retention — Are you growing and keeping customers?

    • Revenue growth rate
    • NRR (Net Revenue Retention)
    • Churn rate
    • Quick Ratio
  2. Unit Economics — Is the business model profitable at the customer level?

    • CAC (Customer Acquisition Cost)
    • LTV (Lifetime Value)
    • LTV:CAC ratio
    • Payback period
    • Gross margin
  3. Capital Efficiency — Are you using cash efficiently?

    • Burn rate
    • Runway
    • Rule of 40
    • Magic Number
  4. Strategic Position — Are you positioned for sustainable success?

    • Market positioning (below, at, above market pricing)
    • Competitive moat (network effects, data, brand)
    • Revenue concentration risk
    • Operating leverage

Stage-Specific Benchmarks

Early Stage (Pre-$10M ARR):

  • Focus: Product-market fit, unit economics
  • Growth: >50% YoY
  • LTV:CAC: >3:1
  • Gross Margin: >70%
  • Runway: >12 months
  • Acceptable: Negative margins, high burn (if unit economics work)

Growth Stage ($10M-$50M ARR):

  • Focus: Scaling efficiently
  • Growth: >40% YoY
  • NRR: >100%
  • Rule of 40: >40
  • Magic Number: >0.75
  • Acceptable: Moderate burn if growth is strong

Scale Stage ($50M+ ARR):

  • Focus: Profitability, efficiency
  • Growth: >25% YoY
  • NRR: >110%
  • Rule of 40: >40
  • Profit Margin: >10%
  • Required: Positive or near-positive cash flow

Red Flag Categories

Critical (Fix immediately):

  • Runway <6 months
  • LTV:CAC <1.5:1
  • Churn accelerating cohort-over-cohort
  • NRR <90%
  • Magic Number <0.3

High Priority (Fix within quarter):

  • Rule of 40 <25
  • Payback >24 months
  • Quick Ratio <2
  • Gross margin <60%
  • Revenue concentration >50% in top 10 customers

Medium Priority (Address within 6 months):

  • NRR 90-100% (flat, not growing)
  • Magic Number 0.3-0.5
  • Operating leverage negative
  • Churn rate stable but high (>5% monthly)

Anti-Patterns (What This Is NOT)

  • Not a single metric: "Revenue is growing 50%, we're great!" (ignoring burn, churn, unit economics)
  • Not stage-agnostic: Early-stage burn is acceptable; scale-stage burn is a problem
  • Not static: Health is directional—are metrics improving or degrading?
  • Not just numbers: Context matters (competitive pressure, market changes, team capacity)

When to Use This Framework

Use this when:

  • Preparing for board meetings or investor updates
  • Quarterly business reviews (QBR)
  • Fundraising preparation (know your numbers)
  • Annual planning (identify improvement areas)
  • You suspect problems but can't pinpoint them
  • New PM/exec joining and needs health assessment

Don't use this when:

  • You're pre-revenue (focus on product-market fit first)
  • You're in pure research mode (not enough data)
  • You need tactical guidance (use specific skills: feature, channel, pricing)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 4 adaptive questions, then delivers a comprehensive diagnostic with prioritized recommendations.


Step 0: Gather Context

Agent asks:

"Let's diagnose your business health. I'll need metrics across four dimensions: growth, retention, unit economics, and capital efficiency.

Company context:

  • Stage: (Pre-$10M ARR, $10M-$50M ARR, $50M+ ARR)
  • Business model: (PLG, sales-led, hybrid)
  • Target market: (SMB, mid-market, enterprise, mixed)

Why this matters: Benchmarks vary by stage. Early-stage optimizes for growth; scale-stage optimizes for efficiency.

Please provide the following metrics. Use 'unknown' if you don't have a metric."


Step 1: Growth & Retention Metrics

Agent asks:

"Growth & Retention:

  1. Revenue:

    • Current MRR or ARR: $___
    • Revenue growth rate: ___% (MoM or YoY)
  2. Retention:

    • Monthly churn rate: ___%
    • NRR (Net Revenue Retention): ___%
    • Quick Ratio: ___ (or I can calculate it)
  3. Expansion:

    • Expansion revenue as % of total MRR: ___%
  4. Cohort trends:

    • Are recent cohorts retaining better or worse than older cohorts?
      1. Better (improving)
      2. Same (stable)
      3. Worse (degrading)
      4. Unknown"

Based on answers, agent evaluates:

  • Healthy growth: Growth >40% YoY (growth stage) or >25% (scale stage)
  • Healthy retention: NRR >100%, churn <5% monthly, Quick Ratio >2
  • 🚨 Growth problems: Growth <20% YoY
  • 🚨 Retention problems: NRR <100%, churn >5%, cohort degradation

Step 2: Unit Economics Metrics

Agent asks:

"Unit Economics:

  1. Acquisition:

    • CAC (Customer Acquisition Cost): $___
    • Blended or by channel? (If by channel, what's your best channel CAC?)
  2. Value:

    • LTV (Lifetime Value): $___
    • LTV:CAC ratio: ___ (or I can calculate it)
    • Payback period: ___ months (or I can calculate it)
  3. Margins:

    • Gross margin: ___%
    • Contribution margin (if known): ___%
  4. Trends:

    • Is CAC increasing, stable, or decreasing over time?
      1. Decreasing (improving efficiency)
      2. Stable
      3. Increasing (diminishing returns)
      4. Unknown"

Based on answers, agent evaluates:

  • Healthy economics: LTV:CAC >3:1, payback <12 months, gross margin >70%
  • ⚠️ Marginal economics: LTV:CAC 2-3:1, payback 12-18 months
  • 🚨 Poor economics: LTV:CAC <2:1, payback >24 months, gross margin <60%

Step 3: Capital Efficiency Metrics

Agent asks:

"Capital Efficiency:

  1. Cash:

    • Cash balance: $___
    • Monthly net burn rate: $___
    • Runway: ___ months (or I can calculate it)
  2. Efficiency ratios:

    • Rule of 40: ___ (Growth % + Profit Margin %) (or I can calculate it)
    • Magic Number: ___ (S&M efficiency) (or I can calculate it)
  3. Operating expenses:

    • S&M as % of revenue: ___%
    • R&D as % of revenue: ___%
    • Is OpEx growing faster than revenue?
      1. No (positive operating leverage)
      2. Yes (negative operating leverage)
      3. Unknown
  4. Profitability:

    • Profit margin: ___%
    • Path to profitability: (already profitable, 6-12 months, 12-24 months, >24 months, unknown)"

Based on answers, agent evaluates:

  • Healthy efficiency: Rule of 40 >40, magic number >0.75, runway >12 months
  • ⚠️ Acceptable efficiency: Rule of 40 25-40, magic number 0.5-0.75, runway 6-12 months
  • 🚨 Poor efficiency: Rule of 40 <25, magic number <0.5, runway <6 months

Step 4: Deliver Comprehensive Diagnostic

Agent synthesizes all metrics and delivers:

  1. Overall Health Score — Healthy / Moderate / Concerning / Critical
  2. Dimension Scores — Growth, Retention, Economics, Efficiency
  3. Red Flags — Critical, High Priority, Medium Priority
  4. Prioritized Recommendations — Top 3-5 actions with expected impact
  5. Stage-Appropriate Benchmarks — How you compare to peers

Diagnostic Pattern 1: Healthy Business

When:

  • Growth, retention, economics, and efficiency all meet stage-appropriate benchmarks
  • No critical red flags
  • Improving trends

Output:

"## ✅ Overall Health: Healthy

Your business shows strong fundamentals across all dimensions.


Health Scorecard

Dimension Score Status
Growth & Retention ✅ Healthy Growth ___% YoY, NRR ___%, Churn ___%
Unit Economics ✅ Healthy LTV:CAC ___:1, Payback ___ months
Capital Efficiency ✅ Healthy Rule of 40: ___, Runway ___ months
Overall Healthy Strong position for scaling

Key Strengths

  1. [Specific strength 1]

    • Metric: [e.g., NRR 120%]
    • Why it matters: [Expanding within base without new logos]
  2. [Specific strength 2]

    • Metric: [e.g., LTV:CAC 5:1]
    • Why it matters: [Sustainable unit economics support scaling]
  3. [Specific strength 3]

    • Metric: [e.g., Rule of 40 = 65]
    • Why it matters: [Excellent balance of growth and efficiency]

Opportunities for Optimization

Even healthy businesses can improve. Here are your top opportunities:

1. [Opportunity 1]

  • Current: [e.g., Magic Number 0.9]
  • Opportunity: [Could scale S&M spend 2x and maintain efficiency]
  • Impact: [+$___ MRR/month]

2. [Opportunity 2]

  • Current: [e.g., Expansion revenue 15% of total]
  • Opportunity: [Build upsell paths, target 25% expansion revenue]
  • Impact: [NRR 110% → 120%]

3. [Opportunity 3]

  • Current: [e.g., CAC $500, stable]
  • Opportunity: [Improve conversion, reduce CAC to $400]
  • Impact: [Faster payback, better LTV:CAC]

Recommended Actions (Next Quarter)

Priority 1: Scale what's working

  • [e.g., Double content marketing budget (best channel)]
  • Expected impact: [+___ customers/month, +$___ MRR]

Priority 2: Expand within base

  • [e.g., Launch premium tier for 20% of customers]
  • Expected impact: [NRR 110% → 115%]

Priority 3: Improve efficiency

  • [e.g., Optimize paid acquisition (reduce CAC 10%)]
  • Expected impact: [Payback 8mo → 7mo]

Monitor These Metrics

Weekly:

  • NRR (should stay >___%)
  • Churn rate (should stay <___%)
  • Quick Ratio (should stay >___)

Monthly:

  • Rule of 40 (should stay >___)
  • Magic Number (should stay >___)
  • LTV:CAC (should stay >___:1)

Quarterly:

  • Cohort retention trends
  • Revenue concentration risk
  • Operating leverage

Benchmarks (Your Stage: [Growth/Scale])

Metric Your Performance Benchmark Status
Growth Rate ___% >40% (growth) / >25% (scale)
NRR ___% >100%
LTV:CAC ___:1 >3:1
Rule of 40 ___ >40
Gross Margin ___% >70%

You're performing at or above benchmarks across the board."


Diagnostic Pattern 2: Moderate Health (Fixable Issues)

When:

  • Most metrics acceptable, but 1-2 dimensions have problems
  • Medium-priority red flags
  • Solvable with focus

Output:

"## ⚠️ Overall Health: Moderate (Fixable Issues)

Your business has good fundamentals but needs attention in [specific dimension].


Health Scorecard

Dimension Score Status
Growth & Retention [✅ / ⚠️ / 🚨] [Details]
Unit Economics [✅ / ⚠️ / 🚨] [Details]
Capital Efficiency [✅ / ⚠️ / 🚨] [Details]
Overall ⚠️ Moderate [Primary issue area] needs attention

Red Flags Identified

High Priority 🚨

  1. [Specific red flag]
    • Metric: [e.g., NRR 95%]
    • Threshold: [Should be >100%]
    • Impact: [Base is contracting, not expanding]
    • Fix by: [End of quarter]

Medium Priority ⚠️

  1. [Specific issue]
    • Metric: [e.g., Magic Number 0.6]
    • Threshold: [Should be >0.75]
    • Impact: [S&M spend moderately efficient, room for improvement]
    • Fix by: [6 months]

Root Cause Analysis

Primary Issue: [e.g., Retention & Expansion]

Symptoms:

  • NRR 95% (should be >100%)
  • Churn rate 5% monthly (should be <3%)
  • Expansion revenue only 10% of MRR (should be 20-30%)

Diagnosis: [e.g., Customers are churning before they expand. Onboarding is weak, no clear upsell paths.]

Impact:

  • Lost MRR: [Calculate churn impact]
  • Missed expansion: [Calculate expansion opportunity]
  • Total impact: [Combined revenue loss]

Prioritized Action Plan

Immediate (Next 30 days):

1. Fix [Primary Issue]

  • Action: [Specific step, e.g., "Launch onboarding improvement program"]
  • Owner: [PM, Customer Success]
  • Target: [Reduce churn 5% → 4%]
  • Impact: [Save $___K MRR/month]

Short-term (Next Quarter):

2. [Secondary Action]

  • Action: [e.g., "Build premium tier for upsell"]
  • Target: [NRR 95% → 105%]
  • Impact: [+$___K expansion MRR]

3. [Tertiary Action]

  • Action: [e.g., "Optimize S&M spend, improve magic number"]
  • Target: [Magic Number 0.6 → 0.8]
  • Impact: [More efficient growth]

What Success Looks Like (90 Days)

Target metrics:

  • NRR: 95% → 105% (+10pp)
  • Churn: 5% → 3.5% (-30%)
  • Magic Number: 0.6 → 0.8 (+33%)

Impact:

  • Monthly revenue saved from churn: +$___K
  • Expansion revenue: +$___K
  • More efficient S&M: [details]

If you hit these targets, you'll be in 'Healthy' territory.


Monitor Weekly

Must-track metrics:

  • Churn rate (track to ensure it's decreasing)
  • NRR (track to ensure it's improving)
  • Customer feedback (are improvements working?)

Leading indicators:

  • Onboarding completion rate
  • Time-to-value
  • Usage metrics (activation, engagement)

What Not to Do

Don't:

  • Scale acquisition until retention is fixed (you'll just churn faster)
  • Ignore expansion (it's easier than new acquisition)
  • Wait too long (retention problems compound)"

Diagnostic Pattern 3: Concerning Health (Urgent Action Required)

When:

  • Multiple critical red flags
  • 2+ dimensions problematic
  • Requires immediate intervention

Output:

"## 🚨 Overall Health: Concerning (Urgent Action Required)

Your business has multiple critical issues that need immediate attention.


Health Scorecard

Dimension Score Status
Growth & Retention 🚨 Concerning [Details]
Unit Economics 🚨 Concerning [Details]
Capital Efficiency 🚨 Critical [Details]
Overall 🚨 Concerning Multiple urgent issues

Critical Red Flags 🚨

1. [Critical Issue 1 - e.g., Runway]

  • Current: [6 months runway]
  • Threshold: [<6 months = crisis]
  • Impact: [Survival risk]
  • Action: [Raise capital OR cut burn immediately]
  • Timeline: [30 days]

2. [Critical Issue 2 - e.g., Unit Economics]

  • Current: [LTV:CAC 1.2:1]
  • Threshold: [<1.5:1 = unsustainable]
  • Impact: [Losing money on every customer]
  • Action: [Reduce CAC OR increase LTV]
  • Timeline: [60 days]

3. [Critical Issue 3 - e.g., Cohort Degradation]

  • Current: [Newer cohorts churning 2x faster than old]
  • Threshold: [Degrading PMF]
  • Impact: [Scaling makes problem worse]
  • Action: [Stop scaling, fix retention]
  • Timeline: [90 days]

Survival Plan (Next 90 Days)

Week 1-2: Triage

Immediate actions:

  1. Extend runway (if <6 months)

    • Option A: Raise bridge round ($___K)
    • Option B: Cut burn by ___%
    • Option C: Combination
    • Decision by: [Date]
  2. Stop scaling broken channels

    • Pause S&M spend on channels with LTV:CAC <2:1
    • Reallocate budget to [best-performing channel]
  3. Assemble crisis team

    • Daily standups on key metrics
    • Weekly progress reviews

Month 1: Stop the Bleeding

Priority 1: Fix Unit Economics

  • Current: LTV:CAC ___:1 (unsustainable)
  • Actions:
    1. Reduce CAC: [Specific tactics]
    2. Increase LTV: [Improve retention, add expansion]
  • Target: LTV:CAC >2:1 within 30 days

Priority 2: Improve Retention

  • Current: Churn ___% (too high)
  • Actions:
    1. Interview churned customers (identify top 3 reasons)
    2. Fix onboarding (reduce early churn)
    3. Proactive outreach to at-risk accounts
  • Target: Reduce churn by 20% within 30 days

Month 2-3: Stabilize

Milestone 1: Positive Unit Economics

  • LTV:CAC >2:1 ✅
  • Payback <18 months ✅
  • Gross margin >60% ✅

Milestone 2: Slowing Churn

  • Churn decreasing month-over-month
  • Cohort degradation stopped
  • NRR improving toward 100%

Milestone 3: Runway Extended

  • 12+ months runway (via fundraise or burn reduction)
  • Clear path to next milestone

What Success Looks Like (Day 90)

Metrics:

  • Runway: ___ months → 12+ months ✅
  • LTV:CAC: ___:1 → >2:1 ✅
  • Churn: ___% → reduced by 30% ✅
  • NRR: ___% → improving toward 100%

Position:

  • Out of crisis mode
  • Stable foundation to rebuild growth
  • Clear plan for next 6-12 months

What to Avoid

Don't:

  • Try to grow your way out of this (fix unit economics first)
  • Ignore the data (hope is not a strategy)
  • Scale before you fix retention (accelerates failure)
  • Wait until runway <3 months to fundraise (too late)

Do:

  • Focus ruthlessly on retention and unit economics
  • Cut costs to extend runway
  • Be honest with board/investors about problems
  • Move fast (you don't have time to waste)"

Diagnostic Pattern 4: Critical Health (Existential Crisis)

When:

  • Runway <3 months OR
  • Multiple critical failures (LTV:CAC <1:1, massive churn, no path to profitability)

Output:

"## 🚨🚨 Overall Health: Critical (Existential Crisis)

Your business is in survival mode. Immediate drastic action required.

[Similar structure to Pattern 3, but more urgent tone, shorter timelines, more drastic measures]

Immediate Actions (This Week):

  1. Emergency board meeting
  2. Fundraise immediately OR cut burn 50%+
  3. Stop all non-essential spend
  4. Fix top 1-2 critical issues (runway, unit economics)"

Examples

See examples/ folder. Mini examples below:

Example 1: Healthy Growth-Stage SaaS

Metrics:

  • ARR: $20M, Growth: 60% YoY
  • NRR: 115%, Churn: 2.5%
  • LTV:CAC: 4:1, Payback: 10 months
  • Rule of 40: 50, Runway: 18 months

Diagnosis: Healthy. Scale aggressively.


Example 2: Moderate Health (Retention Issue)

Metrics:

  • ARR: $15M, Growth: 40% YoY
  • NRR: 95%, Churn: 5%
  • LTV:CAC: 3.5:1, Payback: 12 months
  • Rule of 40: 38, Runway: 12 months

Diagnosis: Moderate. Fix retention before scaling further.


Example 3: Concerning (Multiple Issues)

Metrics:

  • ARR: $8M, Growth: 25% YoY (slowing)
  • NRR: 88%, Churn: 7% (increasing)
  • LTV:CAC: 1.8:1, Payback: 20 months
  • Rule of 40: 15, Runway: 8 months

Diagnosis: Concerning. Urgent action on retention and unit economics required.


Common Pitfalls

Pitfall 1: Celebrating Single Metrics

Symptom: "Revenue growing 50%!" (ignoring burn, churn, unit economics)

Consequence: Unsustainable growth. Scaling broken model.

Fix: Look at all four dimensions together.


Pitfall 2: Ignoring Stage-Specific Benchmarks

Symptom: "We're not profitable yet, is that bad?" (early-stage company)

Consequence: Misplaced worry. Early-stage should optimize for growth and unit economics, not profitability.

Fix: Use stage-appropriate benchmarks.


Pitfall 3: Focusing on Lagging Indicators Only

Symptom: "Churn is 5%, let's watch it"

Consequence: By the time lagging indicators (churn, NRR) show problems, it's late.

Fix: Track leading indicators (usage, engagement, onboarding completion).


Pitfall 4: Not Acting on Red Flags

Symptom: "NRR <100% for 3 quarters, but we'll fix it eventually"

Consequence: Problems compound. Becomes crisis.

Fix: Set clear timelines. If metric doesn't improve in X time, escalate.


Pitfall 5: Trying to Fix Everything at Once

Symptom: "Let's improve growth, retention, CAC, and efficiency simultaneously"

Consequence: Resources spread thin. Nothing improves.

Fix: Prioritize top 1-3 issues. Fix sequentially.


References

Related Skills

  • saas-revenue-growth-metrics — Detailed growth and retention metrics
  • saas-economics-efficiency-metrics — Detailed unit economics and capital efficiency
  • finance-metrics-quickref — Fast lookup for all metrics and benchmarks
  • feature-investment-advisor — Uses health diagnostic to inform feature priorities
  • acquisition-channel-advisor — Uses health diagnostic to inform channel priorities
  • finance-based-pricing-advisor — Uses health diagnostic to inform pricing decisions

External Frameworks

  • Bessemer Venture Partners: "SaaS Metrics 2.0" — Comprehensive benchmarks
  • David Skok: "SaaS Metrics" — Unit economics benchmarks
  • OpenView Partners: SaaS benchmarking reports
  • Battery Ventures: "State of SaaS" annual report

Provenance

  • Adapted from research/finance/Finance_QuickRef.md (Red flags table)
  • Decision frameworks from research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md
  • Benchmarks from research/finance/Finance for Product Managers.md
面向产品经理的深度商业情报研究工具,通过七种分析透镜解析公司、行业或竞品。输出结构化数据,支持生成竞争卡片、SWOT及市场定位等下游任务,提供四种智能入口以适配不同调研场景。
需要对公司、行业或竞争对手进行深度背景调查 为生成竞争卡片、SWOT分析或市场定位准备结构化数据
skills/company-intel/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill company-intel -g -y
SKILL.md
Frontmatter
{
    "name": "company-intel",
    "type": "workflow",
    "intent": "Act as a research engine that builds deep, structured understanding of companies, industries, and competitor sets through **seven analytical lenses** — financial landscape, market offer, product portfolio, competitive dynamics, rising trends, PM implications, and strategic signals (patents, hiring, leadership). Produces a stable, structured output that downstream skills consume to generate battlecards, SWOT analyses, positioning statements, PESTEL assessments, and market sizing. Supports four entry points: single company, industry\/sector, named competitor set, or company + \"discover my competitors\" (researches the company first, identifies likely competitors, confirms the list, then runs the full competitor set analysis).",
    "best_for": [
        "Building deep company or industry knowledge before a client engagement or workshop",
        "Generating structured research that feeds battlecards, SWOT, positioning, or PESTEL",
        "Running a competitive scan across 3-5 companies with cross-company comparison",
        "Refreshing intel quarterly on companies you track"
    ],
    "scenarios": [
        "Run company-intel on Parker Hannifin",
        "Give me intel on the clinical data management industry",
        "Compare Emerson, Honeywell, and Parker Hannifin",
        "Run company-intel on productside.com competitors",
        "Refresh my intel on Novo Nordisk — what's changed since last quarter?"
    ],
    "description": "Research a company, industry, or competitor set using web search and seven analytical lenses. Use when you need structured intel that feeds downstream PM skills.",
    "argument-hint": "[company, industry, or competitor set]"
}

Purpose

Research engine that builds deep, structured understanding of companies, industries, and competitor sets. Produces a stable output format that you can hand off to other skills and agents to generate battlecards, SWOT analyses, positioning statements, PESTEL assessments, market sizing, and workshop content.

This is not a generic encyclopedia lookup. Every section pushes toward commercial understanding, product implications, and actionable intelligence. The output is a research primitive — structured data other skills consume — not a final deliverable.

Input

Works best with: The research target: a company, an industry, or a set of competitors. Also useful: The downstream use (battlecard, SWOT, positioning, market sizing) so the research emphasizes the right lenses, plus any constraints on depth or recency.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workflow opens by asking for the target and what the intel will feed.

Example invocation: Research Figma and its top 3 competitors — output feeds a positioning workshop next week.

Key Concepts

Four Entry Points

The skill auto-detects entry point from the user's input. If ambiguous, ask one clarifying question: "Is this about a specific company, an industry, or a set of competitors?"

Single Company — User names a company (e.g., "Parker Hannifin," "Novo Nordisk"). Produce the full 11-section output for that company.

Industry/Sector — User names an industry, sector, or niche (e.g., "clinical data management," "embedded finance," "upstream oil and gas"). Establish broad industry context, narrow into the segment, and connect findings to PM implications. Use the same 11-section structure adapted for sector-level analysis.

Named Competitor Set — User names 2-5 companies (e.g., "Compare Emerson, Honeywell, and Parker Hannifin"). Produce individual 11-section outputs for each company, then add a Section 12: Cross-Company Comparison that synthesizes across the set.

Discover Competitors — User names a company plus the word "competitors" (e.g., "productside.com competitors" or "Parker Hannifin competitors"). The skill:

  1. Researches the named company first — enough to understand what it does, who it serves, and what market it plays in (a lightweight pass through Lenses 1-4)
  2. Identifies 3-5 likely competitors based on that research, citing why each is a competitor (direct, adjacent, substitute, or emerging disruptor)
  3. Presents the list for confirmation: "Based on my research, [Company]'s closest competitors appear to be [A, B, C, D, E]. Want me to run the full competitor set on these, or adjust the list first?"
  4. Once confirmed, proceeds with the Named Competitor Set flow — full 11-section output for each company plus Section 12 cross-company comparison

The user can also provide a URL instead of a company name (e.g., "productside.com"). The skill should resolve the URL to the company, research accordingly, and proceed.


Seven Research Lenses

These lenses structure all analysis. Apply every lens to every entry point.

Lens 1 — Financial Landscape and Business Outcomes How the entity makes money. Major revenue streams and cost drivers, margin pressures, growth levers, retention and expansion dynamics, capital intensity, seasonal or cyclical patterns, major risks to performance.

Lens 2 — Market Offer and Business Model How the entity creates and captures value. Target markets, buyers, users, influencers, administrators, and blockers. How segments differ. Multi-sided or multi-stakeholder dynamics.

Lens 3 — Product Portfolio and Product Outcomes Major offers, product families, services, platforms, channels. Bundled solutions, ecosystem plays. Digital versus human-assisted components. Legacy versus emerging offers. Distinction between business line, offer, product, feature set, service layer, and enabling platform.

Lens 4 — Competitive Dynamics Direct competitors, adjacent competitors, substitutes, emerging disruptors. Where differentiation is won or lost.

Lens 5 — Rising Trends and Strategic Concerns Market trends, regulatory forces, technology shifts (especially AI and automation), operational constraints, buyer expectation changes, threats from consolidation or commoditization.

Lens 6 — How Product Management Works Here Product-led vs sales-led vs service-led behavior. Centralized vs federated product structures. Platform vs solution orientation. Roadmap and innovation posture. Compliance or governance overhead. Discovery maturity, data maturity, experimentation maturity, AI maturity. Cross-functional friction. Label inferences clearly.

Lens 7 — Strategic Signals Three signal types — always check all three:

  • Patent activity: Recent filings and grants via patent databases. Technology domains, R&D clusters, gaps between patent activity and public product narrative.
  • Hiring signals: Roles open in volume, skills and tools in job descriptions, seniority being hired, language that reveals product culture (discovery, outcomes, AI-native, regulatory, experimentation).
  • Leadership changes: C-suite and product leadership arrivals or departures in the last 12-18 months. Origin of new leaders (platform companies, consulting, competitors). New CPO, CTO, or CDO roles created, eliminated, or restructured. Board-level changes.

Key Distinctions to Maintain

Always be disciplined about these — collapsing them produces shallow analysis:

  • market vs segment
  • buyer vs user
  • product vs service
  • business outcome vs product outcome vs output
  • strategy vs tactics
  • discovery vs delivery
  • platform vs application
  • signal vs assumption
  • revenue growth vs market share growth vs customer lifetime value improvement vs cost reduction

Tensions Worth Surfacing

Highlight conflicts and tradeoffs wherever they appear:

  • growth vs compliance
  • scale vs customization
  • digital self-service vs high-touch service
  • standardization vs domain-specific workflow
  • innovation vs legacy burden
  • AI ambition vs governance reality
  • customer value vs internal efficiency
  • short-term revenue vs long-term platform investment

Why This Works

  • Web-grounded: Uses live search, not training-data recall — output includes citations
  • PM-native: Every section connects to product management implications, not just business facts
  • Composable: Stable output format that downstream skills can parse and consume
  • Repeatable: Same input next quarter produces fresh intel — the delta is the story
  • Signal-driven: Strategic signals (patents, hiring, leadership) are often the most honest data available — they reveal what a company is actually doing, not what it says it's doing

Anti-Patterns

  • Not a Wikipedia summary: Push past "what they do" to "what this means for product decisions"
  • Not financial analysis: Focus is product strategy and commercial dynamics, not valuation or stock picks
  • Not a prompt generator: The output is actual research with citations, not prompts for a future session
  • Not a one-time exercise: Design for quarterly refresh — run it again, compare the delta

Research Expectations

Use web search actively. This skill requires live data gathering, not recall from training data. Search for and cite:

  • Investor relations materials, annual reports, earnings transcripts
  • Company product pages and official strategy pages
  • Regulatory disclosures and filings
  • Patent databases (Google Patents, USPTO)
  • Company careers pages and job aggregators (LinkedIn, Indeed, Glassdoor)
  • Executive appointment announcements and leadership change coverage
  • Industry analysts (Gartner, Forrester, IDC) and reputable news coverage

Cite sources. Every factual claim should include a source. Separate fact from inference. When you're inferring — especially on Lens 6 (PM culture) and Lens 7 (strategic signals) — label it clearly: "Inference based on [evidence]."

Recency matters. Prioritize sources from the last 12-24 months. Flag anything older.

Application

Step 1: Detect Entry Point

Determine from user input:

  • Single company → proceed to Step 2 with one entity
  • Industry/sector → proceed to Step 2, adapt sections for sector-level analysis
  • Named competitor set (2-5 companies listed) → proceed to Step 2 for each company, then Step 3
  • Discover competitors (one company + "competitors") → proceed to Step 1b, then Step 2 for each, then Step 3
  • URL provided (e.g., "productside.com") → resolve to company name, then detect entry point from any additional context

If ambiguous, ask one question: "Is this about a specific company, an industry, or a set of competitors?"

If the user provides additional context (e.g., "I'm preparing for a client engagement with them" or "we compete with them in the SMB segment"), use that context to weight which lenses get deeper treatment.


Step 1b: Discover Competitors (when entry point is "discover competitors")

  1. Research the named company using web search. Do a lightweight pass through Lenses 1-4 — enough to understand what the company does, who it serves, what market it plays in, and how it creates value.

  2. Identify 3-5 likely competitors based on that research. For each, state:

    • Company name
    • Why it's a competitor (direct, adjacent, substitute, or emerging disruptor)
    • One-sentence description of how it competes
  3. Present the list for confirmation:

    "Based on my research, [Company] is [brief description — what it does and who it serves].

    Its closest competitors appear to be:

    1. [Competitor A] — [relationship: direct/adjacent/substitute/disruptor]. [Why.]
    2. [Competitor B] — [relationship]. [Why.]
    3. [Competitor C] — [relationship]. [Why.]
    4. [Competitor D] — [relationship]. [Why.]
    5. [Competitor E] — [relationship]. [Why.]

    Want me to run the full competitor set analysis on these? You can also add, remove, or swap any before I proceed."

  4. Once confirmed, proceed to Step 2 for each company (including the original), then Step 3 (cross-company comparison).


Step 2: Research and Produce Output

Use web search to gather data across all seven lenses. Produce the following 11-section output:

## 1. What This Entity Is
[Business definition, founding, market position, scale. What makes it distinct.]

## 2. How It Makes Money
[Revenue streams, cost structure, margin dynamics, financial logic.
Seasonal or cyclical patterns. Growth levers and risks.]

## 3. Who It Serves
[Buyers, users, influencers, administrators, blockers.
Segment differences. Multi-stakeholder complexity.]

## 4. What It Sells or Delivers
[Core value propositions. Key offers in plain language.
How the offer creates value for the customer.]

## 5. Key Product Lines or Offers
[Mapped by product family, platform, service, channel.
Digital vs human-assisted. Legacy vs emerging.
Distinguish: business line, offer, product, feature set,
service layer, enabling platform.]

## 6. Business and Market Pressures
[Competitive forces, regulatory pressure, technology shifts,
operational constraints. Name the tensions.]

## 7. Competitors and Alternatives
[Direct competitors, adjacent competitors, substitutes,
emerging disruptors. Where differentiation is won or lost.]

## 8. Important Trends and Risks
[Macro forces, buyer expectation shifts, AI and automation impact,
consolidation or commoditization threats.]

## 9. Strategic Signals
[Patent activity: recent filings, technology domains, R&D bets.
Hiring signals: volume roles, skills language, seniority patterns.
Leadership changes: arrivals, departures, origins, new roles created.
Include sources for each signal.]

## 10. What This Means for Product Management
[PM implications: org dynamics, discovery maturity, delivery model,
cross-functional friction, AI readiness. Product-led vs sales-led.
Likely PM challenges. Domain-specific skills PMs would need.
Label inferences.]

## 11. Sources and Confidence
[List all sources used, organized by section.
Flag assumptions and inferences explicitly.
Note any sections where data was thin or unavailable.]

Quality checks for every section:

  • Does it push past description to implication?
  • Does it name specific tensions, not just facts?
  • Are sources cited?
  • Is inference labeled?

Step 3: Cross-Company Comparison (Competitor Set Only)

When the entry point is a competitor set, produce individual Section 1-11 outputs for each company, then add:

## 12. Cross-Company Comparison

### Where They're Betting Differently
[Patent clusters, hiring patterns, leadership hires that diverge.
Which companies are investing in AI, which in services,
which in platform plays.]

### Where They're Converging
[Same platform moves, same market pivots, same talent profiles.
When everyone zigs together, that's table stakes — not differentiation.]

### Gaps and White Space
[What none of them are covering. Segments underserved.
Capabilities nobody is building. Buyer needs unaddressed.]

### Tensions That Play Out Differently
[e.g., Company A chose scale over customization;
Company B chose the opposite. Who's winning, and for whom?]

### PM Implications Across the Set
[What a PM at each company would face differently.
Which org is better set up for discovery?
Which is most constrained by legacy?]

Step 4: Handoff Menu

After producing the output, offer the user a handoff menu. Each option names what gets built and which skill or agent consumes the research:

"Your research is ready. What do you want to build from it?

  1. Competitive battlecard — I'll structure a head-to-head comparison for your sales or strategy team
  2. SWOT analysis — I'll run strengths, weaknesses, opportunities, and threats using the research as input
  3. Positioning statement — Use positioning-statement skill with this company/market context loaded
  4. PESTEL assessment — Use pestel-analysis skill with the trends and pressures from Sections 6 and 8
  5. Market sizing (TAM/SAM/SOM) — Use tam-sam-som-calculator skill with the market and segment data from Sections 2-3
  6. Research prompts for deeper investigation — Generate 3-5 targeted research prompts per lens for a follow-up session
  7. PM briefing memo — Condense the 11 sections into a 1-page executive summary for a PM audience
  8. Workshop discussion guide — Extract teachable tensions and case study angles for training use

Select a number, combine them (e.g., '1 and 4'), or describe what you need."


Rerun Pattern

When the user reruns the skill on a previously researched entity:

  • Focus web search on recent developments (last 90 days)
  • Lead the output with a "What's Changed" summary before the full 11 sections
  • In Section 9 (Strategic Signals), highlight delta from prior run: new hires, new patents, leadership moves
  • Flag sections where nothing material changed: "No significant change since [prior date]"

The user does not need to say "refresh" — if the agent has prior output in context, it should default to delta-first reporting.

Examples

Example: Single Company — Parker Hannifin

Trigger: "Run company-intel on Parker Hannifin"

Entry point: Single Company

Section 1 excerpt: Parker Hannifin is a Fortune 250 diversified industrial manufacturer headquartered in Cleveland, Ohio, specializing in motion and control technologies. Founded in 1917, it operates across two segments: Diversified Industrial (~85% of revenue) and Aerospace Systems (~15%). The 2023 acquisition of Meggitt for $8.8B significantly expanded its aerospace portfolio.

Section 9 excerpt:

  • Patents: Clustering in electro-hydraulic controls and hydrogen fuel cell components. R&D investment in electrification outpacing public product announcements — signals a bet on industrial decarbonization. (Source: Google Patents, 2024-2025 filings)
  • Hiring: Volume hiring for "digital twin" engineers and IoT platform architects in the Diversified Industrial segment. Job descriptions reference AWS IoT and Azure Digital Twins. (Source: LinkedIn, Indeed — June 2026)
  • Leadership: New VP of Digital Transformation hired from Rockwell Automation (2025). New Group President for Engineered Materials from Honeywell (2024). Pattern: importing talent from platform-oriented industrials. (Source: company press releases)

Section 10 excerpt: PMs at Parker face the classic industrial tension: long product lifecycles (10-20 years) vs. pressure to digitize and create recurring-revenue service layers. Product management is historically engineering-led, not customer-led. Discovery is constrained by the fact that customers (OEMs, utilities, defense contractors) have long procurement cycles and low tolerance for experimentation. The hiring signals suggest a push toward platform thinking, but the org structure (segment-based P&Ls) creates incentives to optimize locally rather than build horizontal platforms. Inference: the digital twin hiring is likely ahead of organizational readiness to consume it.


Example: Competitor Set — Industrial Motion Control

Trigger: "Compare Parker Hannifin, Emerson Electric, and Honeywell on company-intel"

Entry point: Competitor Set (3 companies)

Section 12 excerpt (Cross-Company Comparison):

Where They're Betting Differently:

  • Parker is investing heavily in electrification and hydrogen (patent evidence). Emerson is betting on software-defined automation (Aspen Technology acquisition). Honeywell is splitting into three companies and doubling down on aerospace autonomy.

Gaps and White Space:

  • None of the three have a credible PLG motion for their digital products — all rely on enterprise sales. A startup that cracks self-serve industrial IoT tooling could undercut all three on adoption speed.

PM Implications Across the Set:

  • Parker PM = engineer-first, platform-curious but segment-siloed
  • Emerson PM = software-led post-AspenTech, navigating legacy OT culture
  • Honeywell PM = post-split identity crisis, aerospace PMs and industrial PMs now in different companies

Anti-Pattern Example

Weak: "Parker Hannifin makes industrial equipment and has strong financials."

Strong: Identifies the tension between Parker's motion-and-control platform business (recurring revenue, long service cycles) and its push into intelligent manufacturing and IIoT — and explains why that tension creates specific PM challenges around build-vs-partner decisions, aftermarket monetization, and the pace of digital product adoption in asset-intensive industries.

Common Pitfalls

Pitfall 1: Surface-Level Description Without Implications

Symptom: Summary reads like a Wikipedia article or press release. Consequence: No actionable intelligence. Downstream skills get nothing useful. Fix: Push every section toward "what does this mean for product decisions?" If a fact doesn't connect to a tension, tradeoff, or PM implication, it's not pulling its weight.

Pitfall 2: Skipping Strategic Signals

Symptom: Analysis draws only from press releases and About pages. Sections 1-8 are solid; Section 9 is empty or generic. Consequence: You're seeing what the company says it's doing, not what it's actually doing. Patents, hiring, and leadership changes are often the most honest signals available. Fix: Always search patents, hiring, and leadership as a required step — even if the results are thin. "No significant patent activity found" is a signal too.

Pitfall 3: Confusing Outputs With Outcomes

Symptom: Listing features or products without explaining what results they produce for customers or the business. Consequence: Section 5 becomes a product catalog instead of strategic intelligence. Fix: For every offer, answer: what problem does it solve, for whom, what outcome does it improve, and what behavioral change does it create?

Pitfall 4: No Citations

Symptom: "The CEO said the company is focused on AI." No source, no date, no context. Consequence: Unverifiable claims. Downstream consumers can't trust the research. Fix: Cite source and date. "CEO Jane Doe stated X in Q1 2026 earnings call (Source: Seeking Alpha transcript, Feb 2026)."

Pitfall 5: Treating All Industries as Identical

Symptom: Generic PM frameworks applied without domain calibration. "They should do more discovery" without acknowledging that discovery in defense contracting looks nothing like discovery in consumer SaaS. Consequence: Section 10 is useless to anyone who actually works in the domain. Fix: Identify what makes PM different in this specific domain — regulatory overhead, buyer/user separation, capital intensity, sales cycle length, service dependency.

Pitfall 6: One-Time Exercise, Never Refreshed

Symptom: Intel gathered once, never updated. Decisions made on 18-month-old hiring signals. Consequence: Stale intelligence is worse than no intelligence — it creates false confidence. Fix: Set a rerun cadence (quarterly for active competitors, annually for industry context). When rerunning, lead with "What's Changed."

Downstream Composition Guide

This section is for other skill authors and agent builders who want to consume company-intel output.

What This Skill Produces

A structured markdown document with 11 numbered sections (12 for competitor sets). Each section has a stable heading and defined content type:

Section Content Type Downstream Use
1. What This Entity Is Entity definition, scale, market position Context setting for any downstream skill
2. How It Makes Money Revenue, costs, margins, financial logic business-health-diagnostic, feature-investment-advisor
3. Who It Serves Buyers, users, segments, stakeholder map proto-persona, jobs-to-be-done, positioning-statement
4. What It Sells or Delivers Value propositions, core offers positioning-statement, battlecards
5. Key Product Lines Product families, platforms, services Competitive analysis, portfolio mapping
6. Business and Market Pressures Competitive, regulatory, technology forces pestel-analysis, derisk-measurement-advisor
7. Competitors and Alternatives Direct, adjacent, substitutes, disruptors Battlecards, competitive positioning
8. Important Trends and Risks Macro forces, AI impact, consolidation pestel-analysis, derisk-measurement-advisor
9. Strategic Signals Patents, hiring, leadership changes Competitive intelligence, trend analysis
10. What This Means for PM Org dynamics, discovery maturity, PM challenges Workshop content, coaching, engagement prep
11. Sources and Confidence Citations, assumptions, data quality flags Quality assurance for all downstream use
12. Cross-Company Comparison Divergence, convergence, gaps, tensions Battlecards, SWOT, competitive strategy

How to Reference This Skill

In your skill's References section:

- **[company-intel](../company-intel/SKILL.md)** (Workflow) — Run first to generate structured company/industry research; this skill consumes Sections [X, Y, Z] as input

Passing Output to Downstream Skills

When handing off to a downstream skill, pass the relevant sections explicitly:

  • Battlecard → Sections 4, 5, 7, 9, 12
  • SWOT → Sections 2, 6, 7, 8, 9
  • Positioning → Sections 3, 4, 7
  • PESTEL → Sections 6, 8, 9
  • TAM/SAM/SOM → Sections 2, 3, 5
  • Business health → Sections 2, 5, 8
  • PM briefing → Sections 1, 5, 9, 10
  • Workshop guide → Sections 6, 9, 10 (tensions and PM implications)

References

Related Skills

Research Sources

  • Company investor relations pages — Annual reports, earnings transcripts, forward-looking statements
  • Patent databases — Google Patents, USPTO
  • Job aggregators — LinkedIn, Indeed, Glassdoor (hiring signals)
  • Industry analysts — Gartner, Forrester, IDC
  • Regulatory filings — SEC (US), Companies House (UK), relevant sector regulators
  • News coverage — Reuters, Bloomberg, industry-specific publications

Provenance

  • Adapted from Dean Peters' company-profile-executive-insights-research prompt and TAM-SAM-SOM prompt generator in the product-manager-prompts repo
  • Incorporates the Seven Research Lenses framework developed for Productside enterprise PM training
创建包含高管洞察、产品战略及组织背景的公司研究简报。适用于面试准备、竞争分析、合作评估或市场进入决策,聚焦产品管理视角的战略情报收集,而非表面信息或财务分析。
准备面试 进行竞争分析 评估合作伙伴关系 制定市场进入策略
skills/company-research/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill company-research -g -y
SKILL.md
Frontmatter
{
    "name": "company-research",
    "type": "component",
    "intent": "Create a comprehensive company profile that extracts executive insights, product strategy, transformation initiatives, and organizational dynamics from publicly available sources. Use this to understand competitive landscape, evaluate partnership opportunities, benchmark best practices, prepare for interviews, or inform market entry decisions by understanding how successful companies think about product management and strategy.",
    "description": "Create a company research brief with executive quotes, product strategy, and org context. Use when preparing for interviews, competitive analysis, partnerships, or market-entry work.",
    "argument-hint": "[company name] [purpose]"
}

Purpose

Create a comprehensive company profile that extracts executive insights, product strategy, transformation initiatives, and organizational dynamics from publicly available sources. Use this to understand competitive landscape, evaluate partnership opportunities, benchmark best practices, prepare for interviews, or inform market entry decisions by understanding how successful companies think about product management and strategy.

This is not surface-level research—it's strategic intelligence gathering focused on product management perspectives and executive vision.

Input

Works best with: The company to profile. Also useful: Why you're researching it (interview prep, competitive analysis, partnership, market entry) — this changes what the brief emphasizes.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the company and the purpose before drafting the brief.

Example invocation: Build a company research brief on Datadog — I interview with their platform PM team Friday.

Key Concepts

The Executive Insights Framework

This framework synthesizes company intelligence across multiple dimensions:

Core Components:

  1. Company Overview: Basic info, history, industry context
  2. Executive Quotes: Strategic vision from CEO, COO, VP Product, Group PM
  3. Product Insights: Strategy, recent launches, innovation focus
  4. Transformation Strategies: Digital, AI, Agile transformations
  5. Organizational Impact: How PM influences strategy, cross-functional collaboration
  6. Future Roadmap: Upcoming initiatives and anticipated challenges
  7. Product-Led Growth (PLG): PLG strategies, data-driven decisions

Why This Works

  • Executive perspective: Captures leadership thinking, not just marketing copy
  • Product-centric: Focuses on PM-relevant insights (strategy, process, culture)
  • Multi-source: Synthesizes interviews, earnings calls, blog posts, case studies
  • Strategic intelligence: Informs competitive positioning, partnership evaluation, or interview prep

Anti-Patterns (What This Is NOT)

  • Not financial analysis: Focus is product strategy, not valuation or stock performance
  • Not SWOT analysis: This documents their perspective, not strengths/weaknesses assessment
  • Not surface scraping: Go deeper than "About Us" pages—find executive interviews, product blogs, earnings transcripts

When to Use This

  • Competitive analysis (understanding how competitors approach PM)
  • Partnership evaluation (assessing cultural fit and strategic direction)
  • Interview preparation (understanding company culture, product philosophy)
  • Benchmarking best practices (learning from successful companies)
  • Market entry decisions (understanding how incumbents operate)

When NOT to Use This

  • For internal analysis (this is external research)
  • When primary sources are unavailable (executives haven't spoken publicly)
  • As a substitute for customer research (this is company perspective, not customer perspective)

Application

Use template.md for the full fill-in structure.

Step 1: Define Research Scope

Clarify what you're researching and why:

## Research Objective
- **Company Name:** [e.g., "Stripe"]
- **Research Purpose:** [e.g., "Understand payment platform product strategy for competitive positioning"]
- **Key Questions:**
  - [Question 1: e.g., "How does Stripe think about platform extensibility?"]
  - [Question 2: e.g., "What's their approach to developer experience?"]
  - [Question 3: e.g., "How do they prioritize roadmap vs. custom enterprise requests?"]

Step 2: Gather Company Overview

Document basic company information:

### Company Overview

**Basic Information:**
- **Name:** [Official company name]
- **Headquarters:** [Location]
- **Industry:** [Primary industries, e.g., "Fintech, Payment Processing, Developer Tools"]
- **Founded:** [Year]
- **Size:** [Employees, revenue if public, funding if private]

**Brief History:**
- [Key milestones that shaped current market position]
- [Example: "2010: Founded by Patrick and John Collison. 2011: Launched 7-line integration. 2018: Launched Stripe Atlas. 2021: $95B valuation."]

Sources to check:

  • Company website (About, Press, Blog)
  • LinkedIn company page
  • Crunchbase / PitchBook (for funding/valuation)
  • Wikipedia (for history)

Step 3: Extract Executive Quotes on Strategic Vision

Find recent quotes from key executives:

### Executive Quotes on Strategic Vision

**Quote from the CEO:**
- "[Recent quote discussing long-term vision and market approach]"
- **Source:** [Link to interview, earnings call, blog post, conference talk]
- **Date:** [When the quote was made]
- **Context:** [Brief explanation of what prompted this quote]

**Quote from the COO:**
- "[Recent quote focusing on operational strategies and challenges]"
- **Source:** [Link]
- **Date:** [When]

**Quote from the VP of Product Management:**
- "[Recent quote detailing product strategy and innovation focus]"
- **Source:** [Link]
- **Date:** [When]

**Quote from the Group Product Manager:**
- "[Recent quote discussing specific product initiatives and customer engagement]"
- **Source:** [Link]
- **Date:** [When]

Sources to check:

  • Earnings call transcripts (if public)
  • Podcast interviews (e.g., Lenny's Podcast, Masters of Scale, How I Built This)
  • Conference talks (YouTube, company blog)
  • Blog posts by executives
  • LinkedIn posts
  • Industry publications (TechCrunch, The Verge, etc.)

Quality checks:

  • Recent: Prioritize quotes from the last 12-24 months
  • Substantive: Look for strategy/philosophy, not generic PR statements
  • Attributed: Always cite source and date

Step 4: Document Product Insights

Synthesize product strategy and recent launches:

### Detailed Product Insights

**Product Strategy Overview:**
- [Describe overall product strategy, emphasizing integration of market needs with technological capabilities]
- [Example: "Stripe's product strategy centers on developer experience: reduce integration complexity, provide powerful primitives, enable rapid experimentation"]

**Recent Product Launches and Innovations:**
1. **[Product/Feature 1]** - [Description and market impact]
   - [Example: "Stripe Tax (2021): Automated sales tax calculation. Removed compliance barrier for global expansion."]
2. **[Product/Feature 2]** - [Description and impact]
3. **[Product/Feature 3]** - [Description and impact]

**Product Philosophy:**
- [Key principles that guide product decisions]
- [Example: "Start with developer needs, not enterprise sales. Build for 10x scale before you need it. Default to public APIs."]

Sources to check:

  • Product blog or changelog
  • Product Hunt launches
  • Release notes
  • Product team blog posts or case studies

Step 5: Identify Transformation Strategies

Document how the company is evolving:

### Transformation Strategies and Initiatives

**Digital Transformation:**
- [Describe approach to digital transformation, emphasizing integration of cutting-edge technology with existing processes]
- [Example: "Migrated from monolith to microservices architecture (2019-2022). Enabled 10x faster feature deployment."]

**AI Transformation:**
- [Explain how AI is incorporated into core processes, product offerings, and market positioning]
- [Example: "Launched Radar for fraud detection (ML-powered). Reduced false positives by 40%, processing $640B annually."]

**Agile Transformation:**
- [Detail adoption of Agile methodologies, highlighting improvements in collaboration, project management, product delivery]
- [Example: "Adopted Shape Up methodology (6-week cycles, no sprints). Improved focus, reduced meeting overhead."]

Sources to check:

  • Engineering blog
  • Case studies or white papers
  • Conference talks by engineering/product leaders
  • LinkedIn posts about process changes

Step 6: Understand Organizational Impact of Product Management

Document how PM functions within the organization:

### Organizational Impact of Product Management

**Role of Product Management in Strategic Decisions:**
- [Discuss how PM influences strategic decisions]
- [Example: "PMs own P&L for their product area. Directly influence company roadmap through quarterly planning process. CEO reviews roadmap with PM leads, not just VPs."]

**Cross-Functional Collaboration:**
- [Outline collaboration between PM and other departments]
- [Example: "PMs co-located with engineering (not in separate 'product' org). Weekly design reviews with Design VP. Monthly GTM sync with Sales/Marketing."]

**PM Career Paths:**
- [If available, describe how PMs grow and advance]
- [Example: "IC track: PM → Senior PM → Staff PM → Principal PM. Manager track: PM → Group PM → Director → VP."]

Sources to check:

  • PM job postings (describe role, responsibilities, team structure)
  • LinkedIn profiles (track PM career progression)
  • PM blog posts or interviews
  • Glassdoor reviews (internal culture insights)

Step 7: Analyze Future Roadmap and Challenges

Identify where the company is headed:

### Future Product Roadmap and Challenges

**Upcoming Product Initiatives:**
- [Detail planned initiatives and alignment with strategic goals]
- [Example: "Expanding into embedded finance (Stripe Capital, Stripe Treasury). Goal: Become financial infrastructure for the internet, not just payments."]

**Anticipated Market Challenges:**
- [Identify potential challenges and PM team plans to address them]
- [Example: "Challenge: Increasing competition from Square, PayPal. Response: Double down on developer experience, global expansion (70+ countries)."]

**Competitive Threats:**
- [Document acknowledged or observed competitive pressures]

Sources to check:

  • Earnings calls (forward-looking statements)
  • Analyst reports
  • Industry news (funding rounds by competitors, market shifts)

Step 8: Document Product-Led Growth Insights

If applicable, capture PLG strategies:

### Product-Led Growth Insights

**Implementation of PLG Strategies:**
- [Describe how the company employs PLG to enhance customer acquisition, retention, expansion]
- [Example: "Self-serve onboarding: 7-line code integration. No sales calls required for <$1M ARR. 90% of customers start with free tier."]

**Data-Driven Product Decisions:**
- [Explain role of data analytics in shaping product decisions and driving growth]
- [Example: "Instrumented every API call. PMs have real-time dashboards. Feature adoption tracked within 24 hours of launch."]

Sources to check:

  • Product analytics blog posts
  • Growth team blog posts
  • Case studies on activation, retention, expansion

Step 9: Synthesize Key Takeaways

Summarize the most important insights:

### Key Takeaways

**Strategic Principles:**
1. **[Principle 1]** - [What you learned about their approach]
2. **[Principle 2]** - [What you learned]
3. **[Principle 3]** - [What you learned]

**Product Management Lessons:**
1. **[Lesson 1]** - [Applicable insight for your context]
2. **[Lesson 2]** - [Applicable insight]
3. **[Lesson 3]** - [Applicable insight]

**Questions for Further Research:**
- [Unanswered question 1]
- [Unanswered question 2]

Examples

See examples/sample.md for a full company research example.

Mini example excerpt:

**Company Name:** Stripe
**Research Purpose:** Understand payment platform product strategy
**Key Questions:** Developer experience? Platform extensibility?

Common Pitfalls

Pitfall 1: Surface-Level Research

Symptom: "Stripe is a payments company. They process payments."

Consequence: No strategic insights.

Fix: Go deeper—find executive interviews, engineering blogs, product philosophy posts.


Pitfall 2: No Source Citations

Symptom: "The CEO said the company is focused on innovation"

Consequence: Unverifiable, low credibility.

Fix: Always cite source and date: "The CEO said X (Source: Lenny's Podcast, Episode 185, Sept 2023)."


Pitfall 3: Mixing Opinion with Facts

Symptom: "Stripe's product strategy is great because they focus on developers"

Consequence: Analysis, not research.

Fix: Document what they do, not whether it's "good." Save analysis for "Key Takeaways."


Pitfall 4: Outdated Information

Symptom: Using 5-year-old quotes or strategies

Consequence: Irrelevant insights (company strategies evolve).

Fix: Prioritize sources from the last 12-24 months.


Pitfall 5: Ignoring Negative Signals

Symptom: Only documenting successes, ignoring challenges or failures

Consequence: Incomplete picture.

Fix: Include "Anticipated Market Challenges" and competitive threats.


References

Related Skills

  • skills/positioning-statement/SKILL.md — Use company research to understand competitive positioning
  • skills/pestel-analysis/SKILL.md — Company research informs market context
  • skills/proto-persona/SKILL.md — Executive quotes may reveal target personas

External Frameworks

  • Competitive intelligence frameworks
  • Strategic analysis methodologies

Dean's Work

  • Executive Insights Company Profile Template

Provenance

  • Adapted from prompts/company-profile-executive-insights-research.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: company-research.md Suggested placement: /skills/components/ Dependencies: References skills/positioning-statement/SKILL.md, skills/pestel-analysis/SKILL.md

诊断AI工作流中的上下文堆积问题,区分无效的信息堆砌与有结构的上下文工程。指导用户优化信息架构,通过边界设定和检索策略提升模型注意力效率,解决流程臃肿、脆弱及难以控制的问题。
AI工作流感觉臃肿或脆弱 需要诊断上下文堆积与工程化的区别 希望优化AI工作流的信息架构
skills/context-engineering-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill context-engineering-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "context-engineering-advisor",
    "type": "interactive",
    "theme": "ai-agents",
    "intent": "Guide product managers through diagnosing whether they're doing **context stuffing** (jamming volume without intent) or **context engineering** (shaping structure for attention). Use this to identify context boundaries, fix \"Context Hoarding Disorder,\" and implement tactical practices like bounded domains, episodic retrieval, and the Research→Plan→Reset→Implement cycle.",
    "best_for": [
        "Diagnosing context stuffing vs. context engineering in your AI workflows",
        "Building better memory and retrieval architecture for AI agents",
        "Improving AI output quality through structured context design"
    ],
    "scenarios": [
        "My AI outputs are mediocre even though I'm giving it lots of information — diagnose what's wrong",
        "I want to architect context properly for a multi-step AI workflow in my product team"
    ],
    "description": "Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably.",
    "argument-hint": "[AI workflow to diagnose]",
    "estimated_time": "15-20 min"
}

Purpose

Guide product managers through diagnosing whether they're doing context stuffing (jamming volume without intent) or context engineering (shaping structure for attention). Use this to identify context boundaries, fix "Context Hoarding Disorder," and implement tactical practices like bounded domains, episodic retrieval, and the Research→Plan→Reset→Implement cycle.

Key Distinction: Context stuffing assumes volume = quality ("paste the entire PRD"). Context engineering treats AI attention as a scarce resource and allocates it deliberately.

This is not about prompt writing—it's about designing the information architecture that grounds AI in reality without overwhelming it with noise.

Input

Works best with: A description of the AI workflow, agent, or prompt setup that feels bloated, brittle, or hard to steer. Also useful: What you've already stuffed into context (docs, transcripts, schemas) and where outputs go wrong.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking what you're feeding the model today and what breaks.

Example invocation: Diagnose my setup: our support-triage agent gets the full 40-page policy manual per ticket and still misroutes edge cases.

Key Concepts

The Paradigm Shift: Parametric → Contextual Intelligence

The Fundamental Problem:

  • LLMs have parametric knowledge (encoded during training) = static, outdated, non-attributable
  • When asked about proprietary data, real-time info, or user preferences → forced to hallucinate or admit ignorance
  • Context engineering bridges the gap between static training and dynamic reality

PM's Role Shift: From feature builder → architect of informational ecosystems that ground AI in reality


Context Stuffing vs. Context Engineering

Dimension Context Stuffing Context Engineering
Mindset Volume = quality Structure = quality
Approach "Add everything just in case" "What decision am I making?"
Persistence Persist all context Retrieve with intent
Agent Chains Share everything between agents Bounded context per agent
Failure Response Retry until it works Fix the structure
Economic Model Context as storage Context as attention (scarce resource)

Critical Metaphor: Context stuffing is like bringing your entire file cabinet to a meeting. Context engineering is bringing only the 3 documents relevant to today's decision.


The Anti-Pattern: Context Stuffing

Five Markers of Context Stuffing:

  1. Reflexively expanding context windows — "Just add more tokens!"
  2. Persisting everything "just in case" — No clear retention criteria
  3. Chaining agents without boundaries — Agent A passes everything to Agent B to Agent C
  4. Adding evaluations to mask inconsistency — "We'll just retry until it's right"
  5. Normalized retries — "It works if you run it 3 times" becomes acceptable

Why It Fails:

  • Reasoning Noise: Thousands of irrelevant files compete for attention, degrading multi-hop logic
  • Context Rot: Dead ends, past errors, irrelevant data accumulate → goal drift
  • Lost in the Middle: Models prioritize beginning (primacy) and end (recency), ignore middle
  • Economic Waste: Every query becomes expensive without accuracy gains
  • Quantitative Degradation: Accuracy drops below 20% when context exceeds ~32k tokens

The Hidden Costs:

  • Escalating token consumption
  • Diluted attention across irrelevant material
  • Reduced output confidence
  • Cascading retries that waste time and money

Real Context Engineering: Core Principles

Five Foundational Principles:

  1. Context without shape becomes noise
  2. Structure > Volume
  3. Retrieve with intent, not completeness
  4. Small working contexts (like short-term memory)
  5. Context Compaction: Maximize density of relevant information per token

Quantitative Framework:

Efficiency = (Accuracy × Coherence) / (Tokens × Latency)

Key Finding: Using RAG with 25% of available tokens preserves 95% accuracy while significantly reducing latency and cost.


The 5 Diagnostic Questions (Detect Context Hoarding Disorder)

Ask these to identify context stuffing:

  1. What specific decision does this support? — If you can't answer, you don't need it
  2. Can retrieval replace persistence? — Just-in-time beats always-available
  3. Who owns the context boundary? — If no one, it'll grow forever
  4. What fails if we exclude this? — If nothing breaks, delete it
  5. Are we fixing structure or avoiding it? — Stuffing context often masks bad information architecture

Memory Architecture: Two-Layer System

Short-Term (Conversational) Memory:

  • Immediate interaction history for follow-up questions
  • Challenge: Space management → older parts summarized or truncated
  • Lifespan: Single session

Long-Term (Persistent) Memory:

  • User preferences, key facts across sessions → deep personalization
  • Implemented via vector database (semantic retrieval)
  • Two types:
    • Declarative Memory: Facts ("I'm vegan")
    • Procedural Memory: Behavioral patterns ("I debug by checking logs first")
  • Lifespan: Persistent across sessions

LLM-Powered ETL: Models generate their own memories by identifying signals, consolidating with existing data, updating database automatically.


The Research → Plan → Reset → Implement Cycle

The Context Rot Solution:

  1. Research: Agent gathers data → large, chaotic context window (noise + dead ends)
  2. Plan: Agent synthesizes into high-density SPEC.md or PLAN.md (Source of Truth)
  3. Reset: Clear entire context window (prevents context rot)
  4. Implement: Fresh session using only the high-density plan as context

Why This Works: Context rot is eliminated; agent starts clean with compressed, high-signal context.


Anti-Patterns (What This Is NOT)

  • Not about choosing AI tools — Claude vs. ChatGPT doesn't matter; architecture matters
  • Not about writing better prompts — This is systems design, not copywriting
  • Not about adding more tokens — "Infinite context" narratives are marketing, not engineering reality
  • Not about replacing human judgment — Context engineering amplifies judgment, doesn't eliminate it

When to Use This Skill

Use this when:

  • You're pasting entire PRDs/codebases into AI and getting vague responses
  • AI outputs are inconsistent ("works sometimes, not others")
  • You're burning tokens without seeing accuracy improvements
  • You suspect you're "context stuffing" but don't know how to fix it
  • You need to design context architecture for an AI product feature

Don't use this when:

  • You're just getting started with AI (start with basic prompts first)
  • You're looking for tool recommendations (this is about architecture, not tooling)
  • Your AI usage is working well (if it ain't broke, don't fix it)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill uses adaptive questioning to diagnose context stuffing, identify boundaries, and provide tactical implementation guidance.


Step 0: Gather Context

Agent asks:

Before we diagnose your context practices, let's gather information:

Current AI Usage:

  • What AI tools/systems do you use? (ChatGPT, Claude, custom agents, etc.)
  • What PM tasks do you use AI for? (PRD writing, user research synthesis, discovery, etc.)
  • How do you provide context? (paste docs, reference files, use projects/memory)

Symptoms:

  • Are AI outputs inconsistent? (works sometimes, not others)
  • Are you retrying prompts multiple times to get good results?
  • Are responses vague or hedged despite providing "all the context"?
  • Are token costs escalating without accuracy improvements?

System Architecture (if applicable):

  • Do you have custom AI agents or workflows?
  • How is context shared between agents?
  • Do you use RAG, vector databases, or memory systems?

You can describe briefly or paste examples.


Step 1: Diagnose Context Stuffing Symptoms

Agent asks:

Let's assess whether you're experiencing context stuffing. Which of these symptoms do you recognize?

Select all that apply:

  1. "I paste entire documents into AI" — Full PRDs, complete user interview transcripts, entire codebases
  2. "AI gives vague, hedged responses despite having 'all the context'" — Responses like "it depends," "consider these options," non-committal
  3. "I have to retry prompts 3+ times to get usable output" — Inconsistency is normalized
  4. "Token costs are escalating but accuracy isn't improving" — Spending more, getting same or worse results
  5. "I keep adding more context hoping it'll help" — Reflexive expansion without strategy
  6. "My agents pass everything to each other" — Agent A → Agent B → Agent C with full context chain
  7. "I don't have clear criteria for what to include/exclude" — No context boundary definitions
  8. "None of these—my AI usage is working well" — Skip to advanced optimization

User response: [Select symptoms]

Agent analyzes:

Based on your selections:

  • 0-1 symptoms: Healthy context practices; proceed to optimization
  • 2-3 symptoms: Early context stuffing; address before it scales
  • 4+ symptoms: Active Context Hoarding Disorder; immediate intervention needed

Agent proceeds to diagnostic questions.


Step 2: Diagnostic Question 1 — What Specific Decision Does This Support?

Agent asks:

Let's start with the most critical question: For each piece of context you're including, what specific decision does it support?

Example Context Analysis:

Imagine you're asking AI to "help with discovery planning." You're providing:

  • Entire PRD (20 pages)
  • 50 user interview transcripts (full)
  • Competitive analysis doc (15 pages)
  • Team meeting notes from last 3 months

Question: What decision are you making right now?

Offer 3 scenarios:

  1. "I'm deciding which user segment to interview first"

    • Context needed: User segments from PRD (2 paragraphs), prior interview themes (1 page synthesis), not full transcripts
    • Context NOT needed: Meeting notes, full competitive analysis, full PRD
  2. "I'm deciding which discovery questions to ask in interviews"

    • Context needed: Research objectives (from PRD), past interview insights (synthesis), Jobs-to-be-Done framework
    • Context NOT needed: Full competitive analysis, full meeting notes
  3. "I'm not sure what decision I'm making—I just want AI to 'understand my product'"

    • Problem: No specific decision = context stuffing trap
    • Fix: Define the decision first, then select context

Agent recommends:

Best Practice: Before adding context, complete this sentence:

"I need this context because I'm deciding [specific decision], and without [specific information], I can't make that decision."

If you can't complete that sentence, you don't need the context.

User response: [Describe their decision + context]

Agent validates: Does the context directly support the stated decision? If not, recommend trimming.


Step 3: Diagnostic Question 2 — Can Retrieval Replace Persistence?

Agent asks:

Second question: Is this information you always need, or something you can retrieve just-in-time?

The Distinction:

Always-Needed (Persist):

  • Core product constraints (technical, regulatory, strategic)
  • User preferences that apply to every interaction
  • Critical definitions (operational glossary)
  • Non-negotiable rules

Episodic (Retrieve on-demand):

  • Project-specific details (this epic, this sprint)
  • Historical data (past PRDs, old interview transcripts)
  • Contextual facts (competitive analysis, market research)
  • Temporary decisions

Key Insight: Just-in-time retrieval beats always-available. Don't persist what you can retrieve.

Offer 3 options:

  1. "Most of my context is always-needed (core constraints, user prefs)"

    • Assessment: Good instinct; verify with Question 4 (what fails if excluded?)
    • Recommendation: Build constraints registry and operational glossary (persist these)
  2. "Most of my context is episodic (project details, historical data)"

    • Assessment: Perfect candidate for RAG or retrieval
    • Recommendation: Implement semantic search; retrieve only relevant chunks for each query
  3. "I'm not sure which is which—I persist everything to be safe"

    • Assessment: Classic Context Hoarding Disorder symptom
    • Fix: Apply Question 4 test to each piece of context

Agent recommends:

Rule of Thumb:

  • Persist: Information referenced in 80%+ of interactions
  • Retrieve: Information referenced in <20% of interactions
  • Gray zone (20-80%): Depends on retrieval latency vs. context window cost

User response: [Categorize their context]

Agent provides: Specific recommendations on what to persist vs. retrieve.


Step 4: Diagnostic Question 3 — Who Owns the Context Boundary?

Agent asks:

Third question: Who is responsible for defining what belongs in vs. out of your AI's context?

The Ownership Problem:

If no one owns the context boundary, it will grow indefinitely. Every PM will add "just one more thing," and six months later, you're stuffing 100k tokens per query.

Offer 3 options:

  1. "I own the boundary (solo PM or small team)"

    • Assessment: Good—you can make fast decisions
    • Recommendation: Document your boundary criteria (use Questions 1-5 as framework)
  2. "My team shares ownership (collaborative boundary definition)"

    • Assessment: Can work if formalized
    • Recommendation: Create a "Context Manifest" doc: what's always included, what's retrieved, what's excluded (and why)
  3. "No one owns it—it's ad-hoc / implicit"

    • Assessment: Critical risk; boundary will expand uncontrollably
    • Fix: Assign explicit ownership; schedule quarterly context audits

Agent recommends:

Best Practice: Create a Context Manifest

# Context Manifest: [Product/Feature Name]

## Always Persisted (Core Context)
- Product constraints (technical, regulatory)
- User preferences (role, permissions, preferences)
- Operational glossary (20 key terms)

## Retrieved On-Demand (Episodic Context)
- Historical PRDs (retrieve via semantic search)
- User interview transcripts (retrieve relevant quotes)
- Competitive analysis (retrieve when explicitly needed)

## Excluded (Out of Scope)
- Meeting notes older than 30 days (no longer relevant)
- Full codebase (use code search instead)
- Marketing materials (not decision-relevant)

## Boundary Owner: [Name]
## Last Reviewed: [Date]
## Next Review: [Date + 90 days]

User response: [Describe current ownership model]

Agent provides: Recommendation on formalizing ownership + template for Context Manifest.


Step 5: Diagnostic Question 4 — What Fails if We Exclude This?

Agent asks:

Fourth question: For each piece of context, what specific failure mode occurs if you exclude it?

This is the falsification test. If you can't identify a concrete failure, you don't need the context.

Offer 3 scenarios:

  1. "If I exclude product constraints, AI will recommend infeasible solutions"

    • Failure Mode: Clear and concrete
    • Assessment: Valid reason to persist constraints
  2. "If I exclude historical PRDs, AI won't understand our product evolution"

    • Failure Mode: Vague and hypothetical
    • Assessment: Historical context rarely needed for current decisions
    • Fix: Retrieve PRDs only when explicitly referencing past decisions
  3. "If I exclude this, I'm not sure anything would break—I just include it to be thorough"

    • Failure Mode: None identified
    • Assessment: Context stuffing; delete immediately

Agent recommends:

The Falsification Protocol:

For each context element, complete this statement:

"If I exclude [context element], then [specific failure] will occur in [specific scenario]."

Examples:

  • ✅ Good: "If I exclude GDPR constraints, AI will recommend features that violate EU privacy law."
  • ❌ Bad: "If I exclude this PRD, AI might not fully understand the product." (Vague)

User response: [Apply falsification test to their context]

Agent provides: List of context elements to delete (no concrete failure identified).


Step 6: Diagnostic Question 5 — Are We Fixing Structure or Avoiding It?

Agent asks:

Fifth question: Is adding more context solving a problem, or masking a deeper structural issue?

The Root Cause Question:

Context stuffing often hides bad information architecture. Instead of fixing messy, ambiguous documents, teams add more documents hoping AI will "figure it out."

Offer 3 options:

  1. "I'm adding context because our docs are poorly structured/ambiguous"

    • Assessment: You're masking a structural problem
    • Fix: Clean up the docs first (remove ambiguity, add constraints, define terms)
    • Example: Instead of pasting 5 conflicting PRDs, reconcile them into 1 Source of Truth
  2. "I'm adding context because we don't have a shared operational glossary"

    • Assessment: You're compensating for missing foundations
    • Fix: Build the glossary (20-30 key terms); AI can reference it reliably
    • Example: Define "active user," "churn," "engagement" unambiguously
  3. "I'm adding context because our constraints aren't documented"

    • Assessment: You're avoiding constraint engineering
    • Fix: Create constraints registry (technical, regulatory, strategic)
    • Example: Document "We won't build mobile apps" vs. explaining it in every prompt

Agent recommends:

The Structural Health Test:

If you're adding context to compensate for:

  • Ambiguous documentation → Fix the docs, don't add more
  • Undefined terms → Build operational glossary
  • Undocumented constraints → Create constraints registry
  • Conflicting information → Reconcile into Source of Truth

User response: [Identify structural issues]

Agent provides: Prioritized list of structural fixes before adding more context.


Step 7: Define Memory Architecture

Agent asks:

Based on your context needs, let's design a two-layer memory architecture.

Your Context Profile (from previous steps):

  • Always-needed context: [Summary from Q2]
  • Episodic context: [Summary from Q2]
  • Boundary owner: [From Q3]
  • Validated essentials: [From Q4]
  • Structural fixes needed: [From Q5]

Recommended Architecture:

Short-Term (Conversational) Memory:

  • What it stores: Immediate interaction history for follow-up questions
  • Lifespan: Single session
  • Management: Summarize or truncate older parts to avoid crowding
  • Your specific needs: [Agent customizes based on user's workflow]

Long-Term (Persistent) Memory:

  • What it stores: User preferences, core constraints, operational glossary
  • Lifespan: Persistent across sessions
  • Implementation: Vector database (semantic retrieval)
  • Two types:
    • Declarative Memory: Facts (e.g., "We follow HIPAA regulations")
    • Procedural Memory: Behavioral patterns (e.g., "Always validate feasibility before usability")
  • Your specific needs: [Agent customizes]

Retrieval Strategy (Episodic Context):

  • What it retrieves: Historical PRDs, user interviews, competitive analysis
  • Method: Semantic search triggered by query intent
  • Optimization: Contextual Retrieval (Anthropic) — prepend explanatory context to each chunk before embedding
  • Your specific needs: [Agent customizes]

Agent offers:

Would you like me to:

  1. Generate a Context Architecture Blueprint for your specific use case?
  2. Provide implementation guidance (tools, techniques, best practices)?
  3. Design a retrieval strategy for your episodic context?

User response: [Selection]


Step 8: Implement Research → Plan → Reset → Implement Cycle

Agent asks:

Now let's implement the Research → Plan → Reset → Implement cycle to prevent context rot.

The Problem: As agents research, context windows grow chaotic—filled with dead ends, errors, and noise. This dilutes attention and causes goal drift.

The Solution: Compress research into a high-density plan, then clear the context window before implementing.

The Four-Phase Cycle:

Phase 1: Research (Chaotic Context Allowed)

  • Agent gathers data from multiple sources
  • Context window grows large and messy (this is expected)
  • Dead ends, failed hypotheses, and noise accumulate
  • Goal: Comprehensive information gathering

Phase 2: Plan (Synthesis)

  • Agent synthesizes research into a high-density SPEC.md or PLAN.md
  • This becomes the Source of Truth for implementation
  • Key elements:
    • Decision made
    • Evidence supporting decision
    • Constraints applied
    • Next steps (sequenced)
  • Format: Structured, concise, unambiguous

Phase 3: Reset (Clear Context Window)

  • Critical step: Clear the entire context window
  • Delete all research artifacts, dead ends, errors
  • This prevents context rot from poisoning implementation

Phase 4: Implement (Fresh Session with Plan Only)

  • Start a new session with only the high-density plan as context
  • Agent has clean, focused attention on execution
  • No noise from research phase

Agent offers 3 options:

  1. "I want a template for the PLAN.md format"

    • Agent provides structured template for high-density plans
  2. "I want to see an example of this cycle in action"

    • Agent walks through concrete PM use case (e.g., discovery planning)
  3. "I'm ready to implement this in my workflow"

    • Agent provides step-by-step implementation guide

User response: [Selection]

Agent provides: Tailored guidance based on selection.


Step 9: Action Plan & Next Steps

Agent synthesizes:

Based on your context engineering assessment, here's your action plan:

Immediate Fixes (This Week):

  1. [Delete context with no falsifiable failure mode from Q4]
  2. [Apply Research→Plan→Reset→Implement to your next AI task]
  3. [Document context boundary in Context Manifest]

Foundation Building (Next 2 Weeks):

  1. [Build constraints registry with 20+ entries]
  2. [Create operational glossary with 20-30 key terms]
  3. [Implement two-layer memory architecture]

Long-Term Optimization (Next Month):

  1. [Set up semantic retrieval for episodic context]
  2. [Assign context boundary owner + quarterly audit schedule]
  3. [Implement Contextual Retrieval (Anthropic) for RAG]

Success Metrics:

  • Token usage down 50%+ (less context stuffing)
  • Output consistency up (less retry/regeneration)
  • Response quality up (sharper, less hedged answers)
  • Context window stable (no unbounded growth)

Agent offers:

Would you like me to:

  1. Generate specific implementation docs (Context Manifest, PLAN.md template, etc.)?
  2. Provide advanced techniques (Contextual Retrieval, LLM-powered ETL)?
  3. Review your current context setup (provide feedback on specific prompts/workflows)?

Examples

Example 1: Solo PM Context Stuffing → Engineering

Context:

  • Solo PM at early-stage startup
  • Using Claude Projects for PRD writing
  • Pasting entire PRDs (20 pages) + all user interviews (50 transcripts) every time
  • Getting vague, inconsistent responses

Assessment:

  • Symptoms: Hedged responses, normalized retries (4+ symptoms)
  • Q1 (Decision): "I just want AI to understand my product" (no specific decision)
  • Q2 (Persist/Retrieve): Persisting everything (no retrieval strategy)
  • Q3 (Ownership): No formal owner (solo PM, ad-hoc)
  • Q4 (Failure): Can't identify concrete failures for most context
  • Q5 (Structure): Avoiding constraint documentation

Diagnosis: Active Context Hoarding Disorder

Intervention:

  1. Immediate: Delete all context that fails Q4 test → keeps 20% of original
  2. Week 1: Build constraints registry (10 technical constraints, 5 strategic)
  3. Week 2: Create operational glossary (25 terms)
  4. Week 3: Implement Research→Plan→Reset→Implement for next PRD

Outcome: Token usage down 70%, output quality up significantly, responses crisp and actionable.


Example 2: Growth-Stage Team with Agent Chains

Context:

  • Product team with 5 PMs
  • Custom AI agents for discovery synthesis
  • Agent A (research) → Agent B (synthesis) → Agent C (recommendations)
  • Each agent passes full context to next → context window explodes to 100k+ tokens

Assessment:

  • Symptoms: Escalating token costs, inconsistent outputs (3 symptoms)
  • Q1 (Decision): Each agent has clear decision, but passes unnecessary context
  • Q2 (Persist/Retrieve): Mixing persistent and episodic without strategy
  • Q3 (Ownership): No explicit owner; each PM adds context
  • Q4 (Failure): Agents pass "just in case" context with no falsifiable failure
  • Q5 (Structure): Missing Context Manifest

Diagnosis: Agent orchestration without boundaries

Intervention:

  1. Immediate: Define bounded context per agent (Agent A outputs only 2-page synthesis to Agent B, not full research)
  2. Week 1: Assign context boundary owner (Lead PM)
  3. Week 2: Create Context Manifest (what persists, what's retrieved, what's excluded)
  4. Week 3: Implement Research→Plan→Reset→Implement between Agent B and Agent C

Outcome: Token usage down 60%, agent chain reliability up, costs reduced by 50%.


Example 3: Enterprise with RAG but No Context Engineering

Context:

  • Large enterprise with vector database RAG system
  • "Stuff the whole knowledge base" approach (10,000+ documents)
  • Retrieval returns 50+ chunks per query → floods context window
  • Accuracy declining as knowledge base grows

Assessment:

  • Symptoms: Vague responses despite "complete knowledge," normalized retries (2 symptoms)
  • Q1 (Decision): Decisions clear, but retrieval has no intent (returns everything)
  • Q2 (Persist/Retrieve): Good instinct to retrieve, but no filtering
  • Q3 (Ownership): Engineering owns RAG, Product doesn't own context boundaries
  • Q4 (Failure): Can't identify why 50 chunks needed vs. 5
  • Q5 (Structure): Knowledge base has no structure (flat documents, no metadata)

Diagnosis: Retrieval without intent (RAG as context stuffing)

Intervention:

  1. Immediate: Limit retrieval to top 5 chunks per query (down from 50)
  2. Week 1: Implement Contextual Retrieval (Anthropic) — prepend explanatory context to each chunk during indexing
  3. Week 2: Add metadata to documents (category, recency, authority)
  4. Week 3: Product team defines retrieval intent per query type (discovery = customer insights, feasibility = technical constraints)

Outcome: Accuracy up 35% (from Anthropic benchmark), latency down 60%, token usage down 80%.


Common Pitfalls

1. "Infinite Context" Marketing vs. Engineering Reality

Failure Mode: Believing "1 million token context windows" means you should use all of them.

Consequence: Reasoning Noise degrades performance; accuracy drops below 20% past ~32k tokens.

Fix: Context windows are not free. Treat tokens as scarce; optimize for density, not volume.


2. Retrying Instead of Restructuring

Failure Mode: "It works if I run it 3 times" → normalizing retries instead of fixing structure.

Consequence: Wastes time and money; masks deeper context rot issues.

Fix: If retries are common, your context structure is broken. Apply Q5 (fix structure, don't add volume).


3. No Context Boundary Owner

Failure Mode: Ad-hoc, implicit context decisions → unbounded growth.

Consequence: Six months later, every query stuffs 100k tokens per interaction.

Fix: Assign explicit ownership; create Context Manifest; schedule quarterly audits.


4. Mixing Always-Needed with Episodic

Failure Mode: Persisting historical data that should be retrieved on-demand.

Consequence: Context window crowded with irrelevant information; attention diluted.

Fix: Apply Q2 test: persist only what's needed in 80%+ of interactions; retrieve the rest.


5. Skipping the Reset Phase

Failure Mode: Never clearing context window during Research→Plan→Implement cycle.

Consequence: Context rot accumulates; goal drift; dead ends poison implementation.

Fix: Mandatory Reset phase after Plan; start implementation with only high-density plan as context.


References

Related Skills

  • ai-shaped-readiness-advisor (Interactive) — Context Design is Competency #1 of AI-shaped work
  • problem-statement (Component) — Evidence-based framing requires context engineering
  • epic-hypothesis (Component) — Testable hypotheses depend on clear constraints (part of context)
  • pol-probe-advisor (Interactive) — Validation experiments benefit from context engineering (define what AI needs to know)

External Frameworks

  • Dean PetersContext Stuffing Is Not Context Engineering (Dean Peters' Substack, 2026)
  • Teresa TorresContinuous Discovery Habits (Context Engineering as one of 5 new AI PM disciplines)
  • Marty CaganEmpowered (Feasibility risk in AI era includes understanding "physics of AI")
  • AnthropicContextual Retrieval whitepaper (35% failure rate reduction)
  • Google — Context engineering whitepaper on LLM-powered memory systems

Technical References

  • RAG (Retrieval-Augmented Generation) — Standard technique for episodic context retrieval
  • Vector Databases — Semantic search for long-term memory (Pinecone, Weaviate, Chroma)
  • Contextual Retrieval (Anthropic) — Prepend explanatory context to chunks before embedding
  • LLM-as-Judge — Automated evaluation of context quality
创建全面的客户旅程地图,可视化从认知到忠诚各阶段的互动、情感及指标。用于诊断体验断裂、对齐跨职能团队并识别痛点,以系统性提升客户体验和达成业务目标。
诊断破碎的客户体验 对齐团队关于完整客户流程的认知 识别全渠道接触点的痛点 跨部门协作优化客户旅程
skills/customer-journey-map/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill customer-journey-map -g -y
SKILL.md
Frontmatter
{
    "name": "customer-journey-map",
    "type": "component",
    "theme": "workshops-facilitation",
    "intent": "Create a comprehensive customer journey map that visualizes how customers interact with your brand across all stages—from awareness to loyalty—documenting their actions, touchpoints, emotions, KPIs, business goals, and teams involved at each stage. Use this to identify pain points, align cross-functional teams, and systematically improve the customer experience to achieve business objectives.",
    "best_for": [
        "Mapping the full customer experience across all touchpoints",
        "Aligning cross-functional teams on the end-to-end customer journey",
        "Identifying pain points and opportunities by stage with measurable KPIs"
    ],
    "scenarios": [
        "I need to map the customer journey for our B2B SaaS onboarding experience from signup to first value",
        "Create a journey map for a PM leader evaluating our skills repo — from discovery through loyalty"
    ],
    "description": "Create a customer journey map across stages, touchpoints, actions, emotions, and metrics. Use when diagnosing a broken experience or aligning a team on the full customer flow.",
    "argument-hint": "[persona] [scenario]",
    "estimated_time": "20-30 min"
}

Purpose

Create a comprehensive customer journey map that visualizes how customers interact with your brand across all stages—from awareness to loyalty—documenting their actions, touchpoints, emotions, KPIs, business goals, and teams involved at each stage. Use this to identify pain points, align cross-functional teams, and systematically improve the customer experience to achieve business objectives.

This is not a user flow diagram—it's a strategic artifact that combines customer empathy with business metrics to drive actionable improvements.

Input

Works best with: The customer (persona or segment) and the scenario or goal the journey covers. Also useful: Known stages, touchpoints, pain points, supporting research, and the business objective behind the map.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for persona and scenario first — a journey map without a specific actor and goal turns into a generic funnel diagram.

Example invocation: Map the journey for a mid-market ops manager going from free trial to paid rollout across their team.

Key Concepts

The Customer Journey Mapping Framework

Adapted from NNGroup's framework and Carnegie Mellon's PM curriculum, a customer journey map documents:

Horizontal structure (stages):

  • Awareness: Customer first learns about your brand
  • Consideration: Customer evaluates your offering
  • Decision: Customer makes a purchase
  • Service: Customer uses the product/service post-purchase
  • Loyalty: Customer becomes a repeat buyer and advocate

Vertical structure (for each stage):

  • Customer Actions: What customers do
  • Touchpoints: Where/how they interact with your brand
  • Customer Experience: Emotions and thoughts
  • KPIs: Metrics to measure success
  • Business Goals: What you're trying to achieve
  • Teams Involved: Who owns this stage

Why This Works

  • Empathy-driven: Centers on customer emotions, not just actions
  • Cross-functional alignment: Shows which teams affect which stages
  • Metric-focused: Ties customer experience to measurable outcomes
  • Gap identification: Makes pain points and opportunities visible
  • Actionable: Clear KPIs and goals enable prioritization

Anti-Patterns (What This Is NOT)

  • Not a user story map: Journey maps are broader (all touchpoints, not just product use)
  • Not a service blueprint: Less detailed on internal processes, more focused on customer experience
  • Not static: Journey maps evolve as customer behavior changes

When to Use This

  • Understanding customer experience across all touchpoints (not just product)
  • Aligning cross-functional teams (marketing, sales, product, support)
  • Identifying pain points and prioritizing improvements
  • Onboarding new team members to customer perspective
  • Auditing the end-to-end customer experience

When NOT to Use This

  • For deep product-specific workflows (use story mapping instead)
  • Before defining personas (need to know who you're mapping)
  • As a one-time exercise (journey maps require ongoing updates)

Application

Use template.md for the full fill-in structure.

Step 1: Prepare Prerequisites

Before mapping, ensure you have:

  1. Key stakeholders: Marketing, sales, product, customer service representatives
  2. Buyer personas: Detailed personas with demographics, psychographics, goals, challenges (reference skills/proto-persona/SKILL.md)
  3. Defined stages: Main stages of your buying process (typically: Awareness, Consideration, Decision, Service, Loyalty)
  4. Touchpoint inventory: All places customers interact with your brand (website, social, email, store, support, etc.)

If missing: Run discovery interviews, persona definition work, or touchpoint audits first.


Step 2: Set Clear Objectives

Define what you want to achieve:

## Objectives
- [Goal 1: e.g., "Identify top 3 pain points causing drop-off between Awareness and Consideration"]
- [Goal 2: e.g., "Align marketing and sales on customer motivations at each stage"]
- [Goal 3: e.g., "Understand emotional journey to inform messaging strategy"]

Quality checks:

  • Specific: Not "understand customers" but "identify drop-off causes in Consideration stage"
  • Actionable: Results should inform decisions, not just document observations

Step 3: Choose a Buyer Persona

Select one persona to focus on (create separate maps for each persona):

## Persona
- [Persona name and brief description]
- [Example: "Manager Mike: 35-42, Director of Product at mid-sized B2B SaaS, struggles with data-driven prioritization, values time savings over feature depth"]

Why one persona per map: Different personas have different journeys. Mixing them creates confusion.


Step 4: Map Each Stage

For each stage (Awareness, Consideration, Decision, Service, Loyalty), document:

Customer Actions

What customers do at this stage:

### Stage: [Stage Name, e.g., Awareness]

**Customer Actions:**
- [Action 1: e.g., "See LinkedIn ad about product management tools"]
- [Action 2: e.g., "Hear about tool from PM peer at conference"]
- [Action 3: e.g., "Google 'best product roadmap software'"]

Quality checks:

  • Observable: You can see or measure this action
  • Specific: Not "research products" but "Google 'best roadmap software' and read comparison articles"

Touchpoints

Where/how customers interact with your brand:

**Touchpoints:**
- [Touchpoint 1: e.g., "LinkedIn Ads"]
- [Touchpoint 2: e.g., "Word-of-mouth at PM conferences"]
- [Touchpoint 3: e.g., "Google organic search results"]
- [Touchpoint 4: e.g., "Review sites (G2, Capterra)"]

Quality checks:

  • Comprehensive: Include both digital and physical touchpoints
  • Specific: Not "social media" but "LinkedIn Ads," "Twitter mentions," etc.

Customer Experience

Emotions and thoughts customers have:

**Customer Experience:**
- [Emotion 1: e.g., "Curious but skeptical—'Is this actually better than spreadsheets?'"]
- [Emotion 2: e.g., "Overwhelmed by options—'Too many tools, how do I choose?'"]
- [Emotion 3: e.g., "Hopeful but cautious—'Could this save me time?'"]

Quality checks:

  • Authentic: Use customer quotes from research when possible
  • Emotional: Capture feelings, not just thoughts
  • Specific: Not "interested" but "curious but skeptical—worried about setup time"

KPIs

Key performance indicators for this stage:

**KPIs:**
- [KPI 1: e.g., "Brand awareness (measured via surveys)"]
- [KPI 2: e.g., "LinkedIn ad impressions: 100k/month"]
- [KPI 3: e.g., "Organic search traffic: 5k visitors/month"]
- [KPI 4: e.g., "G2 review views: 2k/month"]

Quality checks:

  • Measurable: Can you track this?
  • Stage-appropriate: Awareness KPIs differ from Decision KPIs

Business Goals

What you're trying to achieve at this stage:

**Business Goals:**
- [Goal 1: e.g., "Increase brand awareness among PMs at B2B SaaS companies"]
- [Goal 2: e.g., "Generate 500 qualified leads/month"]
- [Goal 3: e.g., "Position as top 3 roadmap tool in G2 rankings"]

Quality checks:

  • Outcome-focused: Not "run ads" but "increase brand awareness"
  • Aligned with stage: Don't expect conversions at Awareness stage

Teams Involved

Who owns this stage:

**Teams Involved:**
- [Team 1: e.g., "Marketing (ad campaigns, SEO)"]
- [Team 2: e.g., "Content (blog posts, comparison guides)"]
- [Team 3: e.g., "Customer Success (case studies, testimonials)"]

Quality checks:

  • Cross-functional: Multiple teams usually touch each stage
  • Specific roles: Not just "marketing" but "marketing (ad campaigns, SEO)"

Step 5: Visualize the Map

Create a table or visual diagram:

Stage Awareness Consideration Decision Service Loyalty
Customer Actions See ad, hear from peers, Google search Compare features, read reviews, request demo Free trial signup, test with real data, evaluate ROI Onboard team, build first roadmap, integrate with Jira Use daily, recommend to peers, share wins on LinkedIn
Touchpoints LinkedIn Ads, conferences, Google, review sites Website, demo calls, sales emails Product (free trial), onboarding emails Product, support chat, knowledge base Product, community forums, customer success check-ins
Customer Experience Curious but skeptical Excited but overwhelmed by options Anxious about setup time, hopeful about time savings Relieved if easy, frustrated if complex Satisfied and confident, proud of wins
KPIs Impressions: 100k/month, traffic: 5k/month Demo requests: 100/month, trial signups: 50/month Conversion rate: 20%, time-to-value: <2 hours Activation rate: 70%, support ticket volume Retention rate: 85%, NPS: 50, referral rate: 15%
Business Goals Increase brand awareness, generate 500 leads/month Improve lead quality, reduce sales cycle to 30 days Increase trial-to-paid conversion, optimize onboarding Reduce churn, improve activation, minimize support costs Increase LTV, generate referrals, upsell premium features
Teams Involved Marketing, Content Marketing, Sales, Product Sales, Product, Onboarding Product, Support, Customer Success Product, Customer Success, Marketing

Step 6: Analyze and Prioritize

Review the map and ask:

  1. Where are the biggest pain points? (Look for negative emotions + high drop-off rates)
  2. Which stages have the weakest KPIs? (Prioritize low-performing stages)
  3. Are teams aligned? (Do teams understand their role in each stage?)
  4. What opportunities exist? (Where can small improvements create big impact?)

Prioritization criteria:

  • Impact: How much would fixing this improve the customer experience?
  • Feasibility: How easy is this to fix?
  • Alignment: Does this support business goals?

Step 7: Test and Refine

  • Update regularly: Customer behavior changes—revisit the map quarterly
  • Validate with data: Use analytics, surveys, and customer interviews to confirm assumptions
  • Track improvements: After making changes, measure impact on KPIs

Examples

See examples/sample.md for a full customer journey map example. See examples/meta-product-manager-skills.md for a meta dogfooding example mapping this repository's own customer journey.

Mini example excerpt:

| **Stage** | **Awareness** | **Consideration** | **Decision** |
| **Customer Actions** | Sees LinkedIn ad | Compares on G2 | Starts free trial |
| **Customer Experience** | Curious but skeptical | Overwhelmed | Anxious about setup |

Common Pitfalls

Pitfall 1: Generic Emotions

Symptom: "Customer feels happy" or "Customer is satisfied"

Consequence: No insight into why they feel that way or what to improve.

Fix: Be specific: "Relieved that setup took 30 minutes, not 3 hours as feared."


Pitfall 2: Missing Touchpoints

Symptom: Only documenting digital touchpoints (website, app)

Consequence: Miss offline interactions (conferences, word-of-mouth, support calls).

Fix: Include all touchpoints: physical, digital, human, and automated.


Pitfall 3: Internal Perspective

Symptom: Mapping what you want customers to do, not what they actually do

Consequence: Journey map reflects wishful thinking, not reality.

Fix: Validate with customer research, analytics, and support tickets.


Pitfall 4: No KPIs or Goals

Symptom: Journey map has actions and emotions but no metrics or business objectives

Consequence: No way to measure success or prioritize improvements.

Fix: Add KPIs and business goals for each stage. Make them measurable.


Pitfall 5: One-and-Done Exercise

Symptom: Journey map created once, never updated

Consequence: Map becomes outdated as customer behavior evolves.

Fix: Review quarterly. Update based on new data, product changes, or market shifts.


References

Related Skills

  • skills/proto-persona/SKILL.md — Defines the persona for the journey map
  • skills/jobs-to-be-done/SKILL.md — Informs customer actions and goals
  • skills/problem-statement/SKILL.md — Identifies pain points at each stage
  • skills/user-story-mapping/SKILL.md — Complementary (story mapping focuses on product usage, journey mapping covers all touchpoints)

External Frameworks

  • NNGroup, Customer Journey Mapping (2016) — Foundational framework
  • Carnegie Mellon University, Product Management Curriculum — Academic approach
  • Chris Risdon & Patrick Quattlebaum, Orchestrating Experiences (2018) — Journey mapping for service design

Dean's Work

  • Customer Journey Mapping Prompt Template (adapted from NNGroup and CMU frameworks)

Provenance

  • Adapted from prompts/customer-journey-mapping-prompt-template.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: customer-journey-map.md Suggested placement: /skills/components/ Dependencies: References skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md, skills/problem-statement/SKILL.md

引导产品经理通过自适应问答创建用户旅程地图,识别痛点与机会。适用于映射角色、场景及各阶段行为情绪,帮助团队对齐认知,聚焦真实用户问题而非表面功能。
需要绘制用户旅程地图 分析特定角色在特定场景下的体验痛点 进行产品发现与团队对齐
skills/customer-journey-mapping-workshop/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill customer-journey-mapping-workshop -g -y
SKILL.md
Frontmatter
{
    "name": "customer-journey-mapping-workshop",
    "type": "interactive",
    "intent": "Guide product managers through creating a customer journey map by asking adaptive questions about the actor (persona), scenario\/goal, journey phases, actions\/emotions, and opportunities for improvement. Use this to visualize the end-to-end customer experience, identify pain points, and create a shared mental model across teams—avoiding surface-level feature lists and ensuring discovery work focuses on real customer problems, not assumed solutions.",
    "best_for": [
        "Running a workshop to map an end-to-end customer experience",
        "Finding pain points across a user's journey",
        "Aligning teams on the stages, emotions, and breakdowns in an experience"
    ],
    "scenarios": [
        "Help me run a journey mapping workshop for new customer onboarding",
        "Map the experience of a buyer from trial signup to first value",
        "Facilitate a workshop on the support journey for churn-risk customers"
    ],
    "description": "Run a customer journey mapping workshop with adaptive questions and outputs. Use when you need to map stages, actions, emotions, pain points, and opportunities for a persona and scenario.",
    "argument-hint": "[persona] [scenario]"
}

Purpose

Guide product managers through creating a customer journey map by asking adaptive questions about the actor (persona), scenario/goal, journey phases, actions/emotions, and opportunities for improvement. Use this to visualize the end-to-end customer experience, identify pain points, and create a shared mental model across teams—avoiding surface-level feature lists and ensuring discovery work focuses on real customer problems, not assumed solutions.

This is not a feature roadmap—it's a discovery and alignment tool that uncovers where the experience breaks down and where improvements will have the greatest impact.

Input

Works best with: The persona (actor) and the scenario or goal to map. Also useful: Journey phases you already know, research artifacts, and where you suspect the experience breaks.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workshop opens with the actor question (Q1) and proceeds one question at a time per the facilitation protocol.

Example invocation: Run a journey mapping workshop: persona is a first-time landlord, scenario is listing and leasing their first property through our app.

Key Concepts

What is a Customer Journey Map?

A journey map (NNGroup) visualizes "the process that a person goes through in order to accomplish a goal." It compiles user actions into a timeline, enriched with thoughts and emotions to create a narrative, then condenses and polishes into a visual artifact.

Five Key Components (NNGroup Framework)

  1. Actor — A specific persona or user whose perspective anchors the map
  2. Scenario + Expectations — The situational context and associated goals
  3. Journey Phases — High-level stages organizing the experience (e.g., discover, try, buy, use, seek support)
  4. Actions, Mindsets, and Emotions — User behaviors, thoughts, and emotional responses throughout phases
  5. Opportunities — Insights identifying where experience can improve

Journey Map Structure

Actor: [Persona Name]
Scenario: [Goal/Context]

Phase 1: Discover → Phase 2: Try → Phase 3: Buy → Phase 4: Use → Phase 5: Support
   ↓                  ↓                ↓               ↓               ↓
Actions:           Actions:         Actions:        Actions:        Actions:
Thoughts:          Thoughts:        Thoughts:       Thoughts:       Thoughts:
Emotions: 😊😐😞    Emotions:        Emotions:       Emotions:       Emotions:
   ↓                  ↓                ↓               ↓               ↓
Opportunities:     Opportunities:   Opportunities:  Opportunities:  Opportunities:

Why This Works

  • Forces conversation: Teams align on shared understanding of customer experience
  • Reveals pain points: Emotions + actions highlight where experience breaks down
  • Prioritizes improvements: Opportunities ranked by impact guide roadmap decisions
  • Human-centered: Focuses on customer perspective, not internal processes

Anti-Patterns (What This Is NOT)

  • Not a service blueprint: Journey maps focus on customer perspective; service blueprints map internal operations
  • Not a user story map: Journey maps support discovery; user story maps facilitate implementation planning
  • Not an experience map: Journey maps target specific users and products; experience maps explore broader human behaviors

When to Use This

  • Starting customer discovery (understanding current experience)
  • Identifying pain points for retention/engagement initiatives
  • Aligning cross-functional teams on customer perspective
  • Prioritizing which problems to solve first

When NOT to Use This

  • When you already understand the customer journey deeply
  • For technical refactoring (no customer-facing journey)
  • As a substitute for user research (maps require research input)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 5 adaptive questions, offering 3-4 enumerated options at each step.

Interaction pattern: Pair with skills/workshop-facilitation/SKILL.md when you want a one-step-at-a-time flow with numbered recommendations at decision points and quick-select options for regular questions. If the user asks for a single-shot output, skip the multi-turn facilitation.


Step 0: Gather Context (Before Questions)

Agent suggests:

Before we create your journey map, let's gather context:

Customer Research:

  • User interviews, discovery notes, support tickets
  • Churn reasons, exit surveys, NPS feedback
  • Analytics data (drop-off points, feature usage)
  • Personas or proto-personas

Product Context:

  • Website copy, product descriptions, positioning
  • Competitor journey maps or reviews (G2, Capterra)
  • Existing journey documentation (if any)

You can paste this content directly, or describe the customer experience briefly.


Question 1: Identify Actor (Persona)

Agent asks: "Who is the actor for this journey map? (Which persona or user segment?)"

Offer 4 enumerated options:

  1. Primary persona — "Your main target customer (e.g., 'small business owner')" (Most common starting point)
  2. Secondary persona — "A secondary user segment with different needs (e.g., 'enterprise admin' vs. 'end user')" (Use if primary persona already mapped)
  3. High-churn persona — "User segment with highest churn rate (e.g., 'trial users who don't convert')" (Good for retention initiatives)
  4. Newly discovered persona — "Emerging user segment from recent research (e.g., 'remote teams' post-COVID)" (Good for market expansion)

Or describe your specific persona.

Adaptation: Use personas from context (proto-personas, JTBD research, etc.)

User response: [Selection or custom]


Question 2: Define Scenario + Goal

Agent asks: "What's the scenario and goal for this journey? (What is the actor trying to accomplish?)"

Offer 4 enumerated options:

  1. First-time use — "New user onboarding, from discovery to activation" (Common for SaaS, apps)
  2. Core workflow — "Recurring task the user does regularly (e.g., 'create invoice,' 'run report')" (Common for established products)
  3. Problem resolution — "User encounters issue and seeks help (e.g., 'forgot password,' 'billing question')" (Good for support/retention)
  4. Upgrade/expansion — "Free user considering paid plan, or existing customer expanding usage" (Good for growth initiatives)

Or describe your specific scenario.

User response: [Selection or custom]

Agent extracts:

  • Actor: [Persona from Q1]
  • Scenario: [Context from Q2]
  • Goal: [What actor is trying to accomplish]

Question 3: Identify Journey Phases

Agent says: "Let's break the journey into high-level phases (typically 4-6 phases from start to end)."

Agent generates 4-6 journey phases based on scenario (Q2).

Example (if Scenario = "First-time use"):

Journey Phases (left to right):

1. Discover — User learns about product
2. Evaluate — User researches, compares alternatives
3. Try — User signs up, starts onboarding
4. Activate — User reaches "aha moment," experiences value
5. Use — User integrates product into workflow
6. Expand — User considers upgrading or inviting team

Agent asks: "Do these phases capture the full journey? Should we add, remove, or rename phases?"

User response: [Approve or modify]


Question 4: Map Actions, Thoughts, Emotions per Phase

Agent says: "Now let's map what the actor does, thinks, and feels in each phase."

Agent generates 3-5 actions, thoughts, and emotions per phase based on context (Step 0) and scenario (Q2).

Example (for Phase 3: "Try — User signs up, starts onboarding"):

Phase 3: Try (Onboarding)

Actions:
- Signs up with email
- Receives welcome email
- Logs in for the first time
- Sees empty dashboard
- Searches for "getting started" guide

Thoughts:
- "This looks promising, but I'm not sure where to start"
- "Do I need to watch a tutorial video?"
- "What's the first step?"

Emotions:
- Curious but uncertain 🤔
- Slightly frustrated (no clear next step) 😕
- Hopeful it will get easier 🙂

Pain Points:
- No onboarding checklist or guided tour
- Empty state doesn't suggest next action
- Too many options in navigation (overwhelming)

Agent repeats for all journey phases, showing full map.

Agent asks: "Does this capture the customer experience accurately? Should we adjust actions, thoughts, or emotions?"

User response: [Approve or modify]


Question 5: Identify Opportunities (Pain Points to Address)

Agent says: "Based on the journey map, let's identify opportunities for improvement—ranked by impact."

Agent generates 5-7 opportunities (pain points with highest emotional intensity or drop-off rates).

Example:

# Opportunities (Ranked by Impact)

## 1. Onboarding lacks guided first steps (Phase 3: Try)
**Pain Point:** Users see empty dashboard, don't know what to do first
**Evidence:** 60% of signups don't complete first action within 24 hours
**Opportunity:** Add interactive onboarding checklist ("Create your first project," "Invite a teammate")
**Impact:** HIGH — Directly affects activation rate

---

## 2. Pricing page is confusing (Phase 2: Evaluate)
**Pain Point:** Users don't understand which plan fits their needs
**Evidence:** High bounce rate on pricing page (70% leave without signing up)
**Opportunity:** Add plan comparison tool or "Which plan is right for me?" quiz
**Impact:** HIGH — Directly affects trial conversion

---

## 3. Support is hard to find (Phase 5: Use)
**Pain Point:** Users encounter issues, struggle to find help
**Evidence:** Support tickets often say "I couldn't find an answer in docs"
**Opportunity:** Add in-app help widget, contextual tooltips
**Impact:** MEDIUM — Affects retention, but fewer users hit this phase

---

## 4. Email confirmations lack context (Phase 1: Discover)
**Pain Point:** Marketing emails don't explain value clearly
**Evidence:** Low click-through rate on email campaigns (5% vs. industry avg 15%)
**Opportunity:** Rewrite emails with customer language, clear CTAs
**Impact:** MEDIUM — Affects top-of-funnel awareness

---

## 5. Upgrade prompts feel pushy (Phase 6: Expand)
**Pain Point:** Users perceive upgrade prompts as sales-y, not helpful
**Evidence:** Negative sentiment in NPS comments ("too many upgrade popups")
**Opportunity:** Show upgrade value contextually (when user hits free plan limit)
**Impact:** LOW — Affects smaller user subset

Agent asks: "Do these opportunities align with your priorities? Which should we focus on first?"

User response: [Selection or custom]


Output: Customer Journey Map + Opportunity List

After completing the flow, the agent outputs:

# Customer Journey Map: [Scenario from Q2]

**Actor:** [Persona from Q1]
**Scenario:** [Context from Q2]
**Goal:** [What actor is trying to accomplish]
**Date:** [Today's date]

---

## Journey Phases

[Phase 1] → [Phase 2] → [Phase 3] → [Phase 4] → [Phase 5] → [Phase 6]

---

## Full Journey Map

### Phase 1: [Name]

**Actions:**
- [Action 1]
- [Action 2]
- [Action 3]

**Thoughts:**
- "[Quote 1]"
- "[Quote 2]"

**Emotions:**
- [Emotion 1] 😊
- [Emotion 2] 😐

**Pain Points:**
- [Pain point 1]
- [Pain point 2]

---

### Phase 2: [Name]

[...repeat structure for all phases...]

---

## Opportunities (Prioritized)

### Opportunity 1: [Name] (HIGH IMPACT)
**Phase:** [Journey phase]
**Pain Point:** [Description]
**Evidence:** [Data/research]
**Proposed Solution:** [How to address]
**Impact:** HIGH — [Rationale]

---

### Opportunity 2: [Name] (HIGH IMPACT)
**Phase:** [Journey phase]
**Pain Point:** [Description]
**Evidence:** [Data/research]
**Proposed Solution:** [How to address]
**Impact:** HIGH — [Rationale]

---

[...continue for all opportunities...]

---

## Next Steps

1. **Validate opportunities:** Use `discovery-interview-prep.md` to test hypotheses with customers
2. **Prioritize fixes:** Use `prioritization-advisor.md` to choose which opportunities to tackle first
3. **Create problem statements:** Use `problem-statement.md` to frame top opportunities
4. **Build experiments:** Use `opportunity-solution-tree.md` to design solutions and POCs

---

**Ready to start addressing opportunities? Let me know if you'd like to refine the map or dive into a specific pain point.**

Examples

Example 1: Good Journey Map (SaaS Onboarding)

Q1 Response: "Primary persona — Small business owner"

Q2 Response: "First-time use — New user onboarding, from discovery to activation"

Q3 - Phases Generated:

Discover → Evaluate → Try → Activate → Use → Expand

Q4 - Phase 3 (Try) Mapped:

Actions:
- Signs up via Google SSO
- Receives welcome email
- Logs in, sees empty dashboard
- Clicks "Help" button, watches 5-min tutorial
- Attempts to create first project, gets stuck on form

Thoughts:
- "This looks easy enough"
- "Wait, what's a 'workspace' vs. 'project'?"
- "Do I need to fill out all these fields?"

Emotions:
- Excited initially 😊
- Confused by terminology 😕
- Frustrated by unclear form 😞

Pain Points:
- No guided onboarding checklist
- Terminology not explained (workspace vs. project)
- Form has too many required fields upfront

Q5 - Opportunities Identified:

  1. Add onboarding checklist (HIGH — affects activation)
  2. Simplify terminology (MEDIUM — affects understanding)
  3. Reduce required form fields (MEDIUM — affects completion rate)

Why this works:

  • Emotions + actions reveal pain points clearly
  • Opportunities tied to specific phases
  • Evidence from research (drop-off data, support tickets)

Example 2: Bad Journey Map (Too Generic)

Phase: "Use Product"

Actions:

  • Uses product
  • Does tasks

Thoughts:

  • "This is good"

Emotions:

  • Happy 😊

Why this fails:

  • No specificity (what tasks? which features?)
  • No pain points identified (everything is "good")
  • Can't extract actionable opportunities

Fix:

  • Get specific: "User creates invoice → sends to client → tracks payment status"
  • Include real customer quotes: "I wish I could bulk-send invoices"
  • Show emotional highs AND lows (not just happy)

Common Pitfalls

Pitfall 1: Mapping Internal Process, Not Customer Experience

Symptom: Journey phases = "Lead generated → Qualified → Demo scheduled → Deal closed"

Consequence: Focuses on sales process, not customer perspective

Fix: Map from customer POV: "Discovers problem → Researches solutions → Tries product → Adopts"


Pitfall 2: No Emotions or Pain Points

Symptom: Journey map lists actions only, no thoughts/emotions

Consequence: Misses the point—can't identify where experience breaks down

Fix: Add customer quotes, emotional states (frustrated, delighted, confused)


Pitfall 3: Too Many Personas in One Map

Symptom: Trying to map "all users" in a single journey

Consequence: Loses focus, becomes generic

Fix: One map per persona. If multiple personas, create separate maps.


Pitfall 4: Opportunities Aren't Prioritized

Symptom: List 20 opportunities with no ranking

Consequence: Team paralyzed, doesn't know where to start

Fix: Rank by impact (HIGH/MEDIUM/LOW) based on evidence and emotional intensity


Pitfall 5: Map Created in Isolation

Symptom: PM creates journey map alone, doesn't involve team

Consequence: No shared mental model, map doesn't drive decisions

Fix: Facilitate workshop with cross-functional team (PM, design, engineering, support)


References

Related Skills

  • customer-journey-map.md — Component skill with journey map template
  • proto-persona.md — Defines actor for journey mapping
  • problem-statement.md — Converts opportunities into problem statements
  • discovery-interview-prep.md — Gathers research input for mapping
  • opportunity-solution-tree.md — Designs solutions for journey opportunities

External Frameworks

  • Nielsen Norman Group, "Journey Mapping 101" (2016) — Definitive guide to journey mapping
  • Adaptive Path, "Guide to Experience Mapping" (2013) — Experience vs. journey maps

Dean's Work

  • [If Dean has journey mapping resources, link here]

Skill type: Interactive Suggested filename: customer-journey-mapping-workshop.md Suggested placement: /skills/interactive/ Dependencies: Uses customer-journey-map.md, proto-persona.md, problem-statement.md, jobs-to-be-done.md

指导产品经理通过内部DUFV和外部PESTEL维度识别产品或AI创意的风险,确定需测量、测试或跟踪的关键指标,并输出优先行动的风险登记册。
需要对产品或AI创意进行压力测试 需要识别关键风险指标并制定行动计划 评估创意的可行性与市场适应性
skills/derisk-measurement-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill derisk-measurement-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "derisk-measurement-advisor",
    "type": "interactive",
    "intent": "Guide product managers through a structured risk scan across **10 dimensions** — 4 internal (Desirability, Usability, Feasibility, Viability) and 6 external (Political, Economic, Social, Technological, Environmental, Legal) — to identify the most important things to measure, test, or track before committing to a product or AI idea. Each surfaced risk gets triaged into **act on immediately** or **start tracking**, producing a prioritized risk register with concrete next steps.",
    "best_for": [
        "Stress-testing an AI or product idea before putting it on the roadmap",
        "Identifying the cheapest tests to run before committing teams and budget",
        "Scanning for external forces that could blindside your product plans",
        "Building a risk register with clear act-now vs. watch-and-track priorities"
    ],
    "scenarios": [
        "I have an AI product idea. What should I measure before we commit?",
        "Help me figure out what risks to act on now vs. track over time",
        "We're about to put this on the roadmap. What could go wrong internally and externally?",
        "Is this idea worth the squeeze? What should we test first?"
    ],
    "description": "Identify what to measure, test, or track to de-risk a product or AI idea. Use when stress-testing an idea across internal (DUFV) and external (PESTEL) dimensions.",
    "argument-hint": "[product or AI idea]",
    "estimated_time": "15-20 min"
}

Purpose

Guide product managers through identifying the most important things to measure, test, or track across 10 risk dimensions — 4 internal and 6 external — then triage each into act on immediately or start tracking. The output is a prioritized risk register that tells you what to do first, not just what could go wrong.

This is not a generic risk list. It's a guided scan tied to your specific product, customer, and market context. The question it answers: is the orange worth the squeeze?

Input

Works best with: The product or AI idea you want to stress-test. Also useful: Its stage (concept, prototype, in-market), what you've already validated, and any dimensions you already know are risky.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking for the idea in a sentence or two, then scans the 10 risk dimensions against it.

Example invocation: De-risk this: an AI agent that auto-drafts insurance claim responses for adjusters — prototype stage, no compliance review yet.

Key Concepts

Two Lenses, One Question

Every product idea carries two kinds of risk. Most PMs check one and ignore the other.

Internal risks ask whether the product itself will work:

  • Product Outcome Metrics (Desirability + Usability) = "What's in it for the customer/user?"
  • Business Outcome Metrics (Feasibility + Viability) = "What's in it for our business/organization?"

External risks ask whether the world will let it work:

  • PESTEL forces (Political, Economic, Social, Technological, Environmental, Legal) = "What could blindside us?"

The single triage question that applies to both sides: Do I act on this now, or start tracking it?


The Internal Risk Framework (DUFV)

Adapted from Marty Cagan's four product risks, split into two measurement categories:

Category Dimension Core Question
Product Outcome Metrics Desirability Will customers value it enough to buy it?
Product Outcome Metrics Usability Will customers figure out how to use it?
Business Outcome Metrics Feasibility Can we build it? Can we sustain it at scale?
Business Outcome Metrics Viability Will it work as a viable business?

Product Outcome Metrics answer: What's in it for the customer/user? They measure whether the product is solving meaningful problems and delivering value to its intended users.

Business Outcome Metrics answer: What's in it for our business/organization? They measure how effectively and reliably the product supports a seamless customer experience while remaining feasible to deliver.

The connection to positioning: Product Outcome Metrics validate your Problem Positioning Statement (the customer promise). Business Outcome Metrics validate your Problem Framing Statement (the business case).


The External Risk Framework (PESTEL)

Six categories of forces outside your organization that can reshape, delay, or kill your product plans:

Category What It Covers Example Risk
Political Government policies, trade regulations, political priorities New AI safety rules for state contractors
Economic Market conditions, funding, inequality, supply chains VC AI funding dries up — focus shifts to profitability
Social Demographics, sentiment, digital literacy, cultural shifts AI accused of bias — can you prove fairness?
Technological Platform dependencies, standards, competing tech New AI model outdates yours — time for rapid innovation?
Environmental Energy consumption, sustainability, carbon footprint AI criticized for carbon footprint — how to go green?
Legal Data privacy, compliance, IP, evolving regulations AI deepfakes lawsuit crossfire — can you protect your product?

Key insight from the classroom: Market conditions don't just change — they potentially change us, our business, and our products. PESTEL helps PMs categorize and respond to that change, not just observe it.


The Act/Watch Triage

Every surfaced risk gets one of two labels:

  • Act on immediately: This risk is present, material, and requires a response now — run a test, change a plan, mitigate a gap.
  • Start tracking: This risk is real but not yet urgent — monitor it, set a trigger threshold, revisit on a cadence.

The triage applies equally to internal and external risks. A desirability gap you can't answer is an "act now" just as much as a regulatory deadline. A demographic trend you see coming is a "watch" just like a feasibility concern you've already partially mitigated.

Anti-pattern: Labeling everything "act now." If every risk is urgent, none of them are prioritized. Force yourself to split roughly 40/60 act/watch.


When to Use This Skill

Use this when:

  • You have a product or AI idea and need to decide whether to commit
  • You're about to put something on the roadmap and want a structured risk check
  • You've been focused on internal risks and haven't scanned external forces (or vice versa)
  • Leadership asks "what could go wrong?" and you want a better answer than "nothing, we're good"

Don't use this when:

  • You don't have a specific product idea yet (use problem-framing-canvas first)
  • You need a deep PESTEL analysis with data and citations (use pestel-analysis component skill)
  • You've already validated the idea and need to pick a validation method (use pol-probe-advisor)
  • The idea is already in production and you're optimizing, not de-risking

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/4 and Risk Scan Qx/6)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill uses adaptive questioning to scan your product idea across 10 risk dimensions (4 internal + 6 external), triage each surfaced risk into act/watch, and produce a prioritized risk register.


Session Start: Heads-Up + Entry Mode (Mandatory)

Agent opening prompt:

"Quick heads-up before we start: this usually takes about 15-20 minutes. We'll cover 4 context questions, then scan 10 risk dimensions — 4 internal (will customers want it, can they use it, can we build it, does the business work) and 6 external (political, economic, social, technological, environmental, legal). For each risk that surfaces, we'll triage it: act now or track.

How do you want to do this?

  1. Guided mode: I'll walk through each dimension one at a time.
  2. Context dump: Paste what you know about the idea and I'll skip what's covered.
  3. Best guess mode: Give me the idea in a sentence and I'll make reasonable assumptions, labeled."

Step 0: Gather Context

Agent asks the following questions, one per turn:

Context Q1/4: "What's the product or AI idea you're evaluating? Describe it in 1-2 sentences — what it does and who it's for."

Context Q2/4: "What stage is this idea at?"

  1. Concept — we're still exploring whether to pursue it
  2. Prototype — we have something testable but uncommitted
  3. Building — we've committed and are developing it
  4. Scaling — it's live and we're growing it

Context Q3/4: "What's your primary concern right now?"

  1. Will anyone actually want this? (demand/desirability risk)
  2. Can users figure out how to use it? (usability risk)
  3. Can we actually build and sustain this? (technical/feasibility risk)
  4. Will this work as a business? (viability/business model risk)
  5. Something external could disrupt our plans (regulatory, market, competitive)

Context Q4/4: "Who is the customer — the person who would use or buy this product? Give me a job title or role, not a company name."

After Q4, agent summarizes:

"Here's what I'm working with:

  • Idea: [summary]
  • Stage: [stage]
  • Primary concern: [concern]
  • Customer: [role]

Let's scan for risks. We'll start with internal risks (Product Outcome Metrics and Business Outcome Metrics), then move to external forces (PESTEL)."


Step 1: Internal Risk Scan — Product Outcome Metrics (Desirability + Usability)

Agent introduces:

"First, let's check Product Outcome Metrics — what's in it for the customer? These measure whether the product will be valuable and usable for your customer. I'll present tests and metrics for two dimensions. For each, tell me which 2 are most critical for your product."


Risk Scan Q1/10 — Desirability: "Which of these tests or metrics matter most for validating that [customer role] will actually want [product idea]? Pick 2."

  1. Use landing pages to gauge initial interest
  2. Test engagement with explainer videos or ads
  3. Analyze signup rates from ad campaigns
  4. Observe feedback from storyboard demos
  5. Measure session times during user interactions
  6. Track feature adoption rates over time
  7. Other (describe your own)

For each selection, agent asks: "Is this something you need to act on immediately (run the test, close the gap) or start tracking (monitor over time)?"


Risk Scan Q2/10 — Usability: "Which of these matter most for validating that [customer role] can actually use [product idea] without friction? Pick 2."

  1. Watch how users interact with wireframes
  2. Use Wizard of Oz tests for usability insights
  3. Observe clarity issues from paper model feedback
  4. Track rage clicks to identify frustration points
  5. Measure drop-offs in task completion workflows
  6. Analyze time-to-complete tasks for friction points
  7. Other (describe your own)

For each selection, agent asks: "Act on immediately or start tracking?"


Step 2: Internal Risk Scan — Business Outcome Metrics (Feasibility + Viability)

Agent introduces:

"Now let's check Business Outcome Metrics — what's in it for our business? These measure whether the business and technology can support this product."


Risk Scan Q3/10 — Feasibility: "Which of these matter most for confirming you can actually build and sustain [product idea]? Pick 2."

  1. Measure system uptime and stability
  2. Simulate user loads to ensure scalability
  3. Track resource use and efficiency during testing
  4. Monitor failure rates across environments
  5. Evaluate costs via analogous systems
  6. Test integration readiness with critical dependencies
  7. Other (describe your own)

For each selection, agent asks: "Act on immediately or start tracking?"


Risk Scan Q4/10 — Viability: "Which of these matter most for confirming [product idea] will work as a business? Pick 2."

  1. Examine analogous data from similar products
  2. Analyze adjacent products for comparable insights
  3. Estimate break-even points using simulation models
  4. Test price sensitivity through customer research
  5. Assess scalability of revenue vs. cost structures
  6. Run trend analysis to evaluate long-term market potential
  7. Other (describe your own)

For each selection, agent asks: "Act on immediately or start tracking?"


Step 3: External Risk Scan — PESTEL

Agent introduces:

"Now let's scan for external forces — things outside your organization that could reshape, delay, or kill your plans. I'll walk through 6 categories. For each, I'll suggest risks relevant to your product and industry. Tell me which ones matter, and whether to act or watch."


Risk Scan Q5/10 — Political: "Given [product idea] and [customer role], which political forces could affect your plans?"

Starter prompts (agent adapts to context):

  • Regulatory compliance requirements (existing or pending)
  • Changing political priorities that affect your industry
  • Regional policy mandates or jurisdictional differences
  • Export restrictions or trade policy shifts

"Which of these (or others) are relevant? For each, act on immediately or start tracking?"


Risk Scan Q6/10 — Economic: "What economic forces could affect [product idea]?"

Starter prompts:

  • Economic inequality affecting your customer segment's budget
  • Supply chain disruptions impacting delivery or cost
  • Funding environment changes (VC, enterprise budgets)
  • Skills shortages in your hiring market

"Which are relevant? Act or watch?"


Risk Scan Q7/10 — Social: "What social or cultural shifts could affect adoption of [product idea]?"

Starter prompts:

  • Shifting social sentiment toward AI or your product category
  • Digital literacy gaps in your target customer population
  • Demographic shifts in your target market
  • Urbanization or remote-work trends affecting how customers work

"Which are relevant? Act or watch?"


Risk Scan Q8/10 — Technological: "What technology shifts could affect [product idea]?"

Starter prompts:

  • Platform dependencies (APIs, cloud providers, AI model providers)
  • Evolving industry standards that your product must meet
  • Competing technology that could leapfrog your approach
  • Spectrum allocations or infrastructure changes (if applicable)

"Which are relevant? Act or watch?"


Risk Scan Q9/10 — Environmental: "What environmental factors could affect [product idea]?"

Starter prompts:

  • Energy consumption concerns (especially for AI/compute-heavy products)
  • Sustainability requirements from customers or regulators
  • Carbon footprint scrutiny from public or investors
  • Resource scarcity affecting infrastructure or supply

"Which are relevant? For many products this category has low impact — if so, say 'minimal' and we'll move on. Act or watch for anything relevant?"


Risk Scan Q10/10 — Legal: "What legal risks could affect [product idea]?"

Starter prompts:

  • Data privacy regulations (GDPR, state privacy laws, sector-specific rules)
  • AI-specific liability or transparency requirements
  • IP protection challenges (patents, trade secrets, open-source licensing)
  • Employment or contractor classification laws (if product affects work)

"Which are relevant? Act or watch?"


Step 4: Synthesize — Risk Register

Agent compiles all selections into a risk register:

"Here's your de-risking plan for [product idea]:

Act on Immediately

# Dimension Risk / Test Recommended First Step
1 [e.g., Desirability] [e.g., Gauge initial interest via landing page] [e.g., Launch a 1-week landing page test with email capture]
2 [e.g., Legal] [e.g., Data privacy compliance for EU customers] [e.g., Map GDPR requirements to your data architecture this week]
...

Start Tracking

# Dimension Risk / Signal What to Watch Review Cadence
1 [e.g., Economic] [e.g., VC funding contraction in AI] [e.g., Quarterly VC reports, competitor funding rounds] Quarterly
2 [e.g., Social] [e.g., Shifting sentiment toward AI in healthcare] [e.g., Industry surveys, media sentiment, customer interviews] Monthly
...

Summary

  • Total risks surfaced: [N]
  • Act on immediately: [N] — these are your next steps before committing further
  • Start tracking: [N] — set calendar reminders for these review cadences
  • Biggest gap: [the dimension with the most unresolved act-now items]"

Agent then offers:

"What would you like to do next?

  1. Dig deeper on an act-now item — I'll help you design the specific test or measurement
  2. Run a full PESTEL analysis — use the pestel-analysis skill for a deep external-forces dive
  3. Pick a validation method — use the pol-probe-advisor to choose the cheapest test for your top risk
  4. Export this register — I'll format it as a Markdown document you can share with your team"

Examples

Example: AI-Powered Clinical Trial Matching Tool

Context:

  • Idea: AI tool that matches patients to clinical trials based on EHR data
  • Stage: Concept
  • Primary concern: External regulatory risk
  • Customer: Clinical operations lead

Internal Risk Scan Results:

Product Outcome Metrics:

  • Desirability: Observe feedback from storyboard demos (ACT) + Track feature adoption rates (WATCH)
  • Usability: Measure drop-offs in task completion workflows (WATCH) + Analyze time-to-complete for friction (WATCH)

Business Outcome Metrics:

  • Feasibility: Test integration readiness with EHR dependencies (ACT) + Monitor failure rates across environments (WATCH)
  • Viability: Examine analogous data from similar products (ACT) + Assess scalability of revenue vs. cost (WATCH)

External Risk Scan Results:

  • Political: FDA digital health guidance evolving (WATCH — quarterly)
  • Economic: Hospital IT budget pressure post-pandemic (ACT — validate willingness to pay now)
  • Social: Clinician trust in AI-driven patient matching (ACT — run trust interviews)
  • Technological: EHR platform API stability and access policies (ACT — test integration this sprint)
  • Environmental: Minimal impact
  • Legal: HIPAA compliance for AI processing of PHI (ACT — legal review before prototype)

Risk Register Output:

Act on immediately (5 items):

  1. Desirability — storyboard demos with 5 clinical ops leads
  2. Feasibility — EHR integration spike (test API access and data format)
  3. Viability — analogous product benchmarking (what do similar tools charge?)
  4. Economic — validate budget authority with 3 hospital IT buyers
  5. Legal — HIPAA compliance review for AI processing of PHI

Start tracking (5 items):

  1. Desirability — feature adoption rates (post-launch metric)
  2. Usability — task completion drop-offs and time-to-complete (post-prototype)
  3. Feasibility — failure rates across environments (post-build)
  4. Viability — revenue vs. cost scalability (post-pilot)
  5. Political — FDA digital health guidance (quarterly review)

Biggest gap: Legal/compliance — HIPAA review must happen before any prototype touches real patient data.


Common Pitfalls

1. Generic Risk Lists

Failure Mode: "Desirability is a risk. Feasibility is a risk. Regulation is a risk." No specifics, no connection to the actual product.

Consequence: Risk register that applies to every product — and therefore helps none.

Fix: Every risk must name the specific test or signal for this product and this customer. "Gauge initial interest" is generic. "Run a 1-week landing page targeting clinical ops leads with EHR integration messaging" is specific.


2. All Act, No Watch

Failure Mode: Every risk is labeled "act on immediately" because everything feels urgent when you're looking at it.

Consequence: No prioritization. Team tries to address 15 risks simultaneously and makes progress on none.

Fix: Force a split. If you have 10 risks, no more than 4-5 should be "act now." The rest are real risks — they just aren't today's problem. Set a review cadence and move on.


3. Internal-Only or External-Only

Failure Mode: PM runs a thorough DUFV scan but never checks PESTEL (or vice versa). "We validated demand and feasibility — ship it!" Then a regulation kills the product 6 months later.

Consequence: Blind spots in exactly the dimensions you didn't scan.

Fix: This skill exists precisely to prevent this. Both lenses, every time. If an external category has low impact (common for Environmental in SaaS), say "minimal" and move on — but don't skip the question.


4. Analysis Without Next Steps

Failure Mode: Beautiful risk register, no recommended first step. Sits in a Google Doc. Nobody acts on it.

Consequence: Risk theater — the appearance of diligence without the substance.

Fix: Every "act now" item must have a concrete next step: who does what, by when, and how you'll know the risk is addressed. "Run a test" is not a next step. "Launch a 1-week landing page with email capture targeting [customer role], measure signup rate, and decide go/no-go by [date]" is.


References

Related Skills

  • pestel-analysis (Component) — Deep-dive PESTEL template with data-driven analysis across all 6 categories; use after this skill surfaces external risks worth investigating further
  • pol-probe-advisor (Interactive) — Choose the cheapest validation method for your highest-priority act-now risk
  • pol-probe (Component) — Document a Proof of Life probe for a specific risk
  • recommendation-canvas (Component) — Structure a go/no-go recommendation using risk register findings
  • problem-framing-canvas (Interactive) — Frame the problem before scanning for risks

External Frameworks

  • Marty CaganInspired (2018): The four product risks (Value, Usability, Feasibility, Viability) as the foundation for product discovery
  • Francis Joseph AguilarScanning the Business Environment (1967): Origin of PEST analysis, extended to PESTEL

Dean's Work

  • Productside AI Product Management course, Unit 07: "De-Risking Your AI Bets — Unpacking Unknowns and Assumptions"
  • PESTel Risk Planning activity (external risks with act/watch triage)
  • Measuring What Matters activity (internal risks with DUFV quadrant selection)
指导产品经理向总监转型的教练技能,涵盖准备、面试、入职及调整四阶段。基于Altitude & Horizon框架,提供针对性实战建议而非通用清单,结合情境诊断与结构化对话流程解决领导力挑战。
PM准备晋升总监 正在面试总监职位 新任总监遇到适应困难 担任总监后需要重新校准管理风格
skills/director-readiness-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill director-readiness-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "director-readiness-advisor",
    "type": "interactive",
    "theme": "career-leadership",
    "intent": "Guide PMs and Directors through the specific challenges of the PM-to-Director transition using adaptive questions and targeted coaching. Diagnoses where you are in the journey and delivers practical, war-story-backed guidance calibrated to your situation — not generic leadership advice.",
    "best_for": [
        "Preparing to make the leap to Director over the next 3-12 months",
        "Navigating your first 6 months in a new Director role",
        "Diagnosing what isn't working 12+ months into the Director role"
    ],
    "scenarios": [
        "I'm a senior PM preparing for Director interviews next quarter",
        "I just got promoted to Director and I can't stop jumping into the tactical work",
        "I've been a Director for 18 months and my exec relationships aren't working"
    ],
    "description": "Guide the PM-to-Director transition across preparing, interviewing, landing, and recalibrating. Use when leadership scope is changing and you need practical coaching.",
    "argument-hint": "[where you are: preparing | interviewing | landed | recalibrating]",
    "estimated_time": "10-15 min"
}

Purpose

Guide PMs and Directors through the specific challenges of the PM-to-Director transition using adaptive questions and targeted coaching. Diagnoses where you are in the journey and delivers practical, war-story-backed guidance calibrated to your situation — not generic leadership advice.

This is not a readiness checklist. It's a coaching conversation that names what's actually hard, why it's hard, and what to do about it.

Input

Works best with: Where you are in the PM-to-Director journey: preparing for the jump, interviewing, newly landed, or recalibrating after a rough start. Also useful: Your org context (team size, who you'd report to) and the specific friction you're feeling.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking which of the four situations describes you, then branches.

Example invocation: I'm 60 days into a Director role and my old peers now report to me — it's awkward and I'm still doing PM work. Coach me.

Key Concepts

The Four Transition Situations

The PM → Director transition looks different depending on where you are:

  1. Preparing to make the leap — Still a PM, actively developing toward the role
  2. Interviewing for Director roles — In an active internal or external search
  3. Newly landed — Recently promoted or hired as Director (first 6 months)
  4. Recalibrating — Been a Director for a while; something isn't working

Each situation has distinct coaching priorities. The biggest mistake is applying "newly landed" advice to someone who's been in the role for two years, or "preparing" advice to someone mid-interview process.

The Underlying Model

This skill draws directly on the Altitude & Horizon Framework — see skills/altitude-horizon-framework/SKILL.md for the full mental model. Core concepts used here:

  • Altitude (scope) and Horizon (time) as the two axes that shift
  • The Waiter vs. Restaurant Operator distinction
  • Four transition zones: Thinking Altitude, Persona Shift, Hero Syndrome Recovery, Direction Creation
  • Named failure modes: Hero Syndrome, Allergic to Process, People-Pleaser Leadership, Instant Gratification Trap

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • Session heads-up + entry mode (Guided, Context dump, Best guess)
  • One-question turns with plain-language prompts
  • Progress labels (e.g., Context Q1/3)
  • Interruption handling and pause/resume behavior
  • Numbered recommendations at decision points
  • Quick-select numbered response options (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.


Application

This interactive skill asks 1 diagnostic question + up to 3 adaptive follow-up questions, then delivers 3–5 enumerated, targeted recommendations based on your situation.


Step 0: Session Start

Agent says:

Before we start, you can choose how to run this session:

  1. Guided — I'll ask questions one at a time and build recommendations from your answers (recommended for most situations)
  2. Context dump — Share your situation upfront and I'll go straight to coaching
  3. Best guess — Tell me nothing; I'll give you the highest-value advice for the most common transition situation (newly landed Director, 0–3 months in)

Question 1: Where Are You?

Agent asks (Q1/3):

"Where are you in the PM-to-Director journey?"

  1. Preparing to make the leap — Still in a PM role, actively building toward Director
  2. Interviewing for Director roles — In an active internal promotion or external job search
  3. Newly landed — Recently promoted or hired as Director (roughly first 6 months)
  4. Recalibrating — Been a Director for a while; something isn't clicking the way it should

Or describe your situation directly.


Branch 1: Preparing to Make the Leap

Question 1B (Q2/3):

Agent asks:

"What's the gap you most want to close before making the move?"

  1. Thinking altitude — I still default to solving customer problems directly instead of designing systems
  2. Stakeholder navigation — I struggle with organizational politics, executive dynamics, or cross-functional influence
  3. Strategic narrative — I can't yet connect my work to company strategy convincingly in conversations with leadership
  4. Direction creation — I wait for clarity from above rather than creating it for my team

Or describe your main development area.

Question 1C (Q3/3):

Agent asks:

"What's your runway — how close are you to making the move?"

  1. 6+ months out — Building deliberately; no immediate pressure
  2. 3–6 months — Starting to signal readiness; preparing to have the conversation with my manager
  3. Actively applying — In motion now, interviewing or expecting to be soon

Or describe your timeline.

Branch 1 Recommendations:

Agent delivers (based on 1B + 1C):

Example output for 1B = Strategic narrative + 1C = 3–6 months:

"Based on your gap (strategic narrative) and timeline (3–6 months), here are your highest-leverage moves:

  1. Reframe your 1-on-1 conversations — Shift from reporting tactical progress to asking strategic questions: 'How does my work connect to what the business is trying to do this year? What's the organizational context I'm not seeing?' This builds strategic thinking muscle and signals readiness to your manager simultaneously.

  2. Build your cascade habit now — Pick one company priority from the last QBR or all-hands and write a one-page translation: how does your team's work connect? Share it informally with your manager. You don't need permission to practice this skill.

  3. Audit your Hero Syndrome — Track the next two weeks: how often do you jump in to solve problems that others could solve with your coaching instead? The ratio of rescuing to developing is a leading indicator of Director readiness.

  4. Don't over-index on Director thinking — The most common mistake while still a PM: spending too much energy on altitude/horizon thinking at the expense of serving your current role. Play your PM role fully. Director readiness will show in the quality of your work, not in performing above your level.

Choose a number to go deeper on any of these, or ask about something specific."


Branch 2: Interviewing for Director Roles

Question 2B (Q2/3):

Agent asks:

"What's your interview context?"

  1. Internal promotion — Being considered within my current company
  2. External search — Interviewing at new companies
  3. Both — Running an internal and external process simultaneously

Question 2C (Q3/3):

Agent asks:

"What do you most want to work on for interview prep?"

  1. Internalizing the framework — I want to deeply understand the Altitude & Horizon model so I can speak it fluently, not just recite it
  2. Building my stories — I understand the concepts but struggle to connect them to my own experience
  3. Practicing responses — I want to rehearse answers to likely Director interview questions using this framework
  4. Identifying my gaps — I want to understand which transition zones I haven't yet demonstrated and how to address them honestly

Or describe what you most need.

Branch 2 Recommendations:

Agent delivers (based on 2B + 2C):

Example output for 2B = External + 2C = Practicing responses:

"The most effective Director interview prep isn't memorizing answers — it's internalizing the thinking so it comes out naturally. These two skills are your prep tools:

  1. Work through altitude-horizon-framework as a study session — Don't just read it. After each section, pause and answer: 'Where have I operated at this altitude or horizon in my own work? What's my story here?' The Four Transition Zones and Named Failure Modes map almost directly to common Director interview questions.

  2. Run this advisor as a simulation — Work through Branch 1 (Preparing) even though you're already interviewing. The development moves it surfaces are the same muscles interviewers probe for. If you can't do the exercise, you haven't yet built the answer.

  3. Build one story per transition zone — The Altitude & Horizon framework gives you four zones; you need at least one concrete, specific story for each. Use the zone names as the structure: 'Here's a time I had to shift my thinking altitude... here's what triggered the persona shift... here's when I had to create direction rather than wait for it.' Interviewers recognize this kind of self-awareness immediately.

  4. Reframe your PM wins in Director language — You almost certainly have the experience; it's framed wrong. Don't open with 'I shipped X.' Open with: 'The strategic question my team was facing was [X]. Here's how I thought about the portfolio tradeoff.' Use the feature or outcome as evidence, not as the headline.

  5. Prepare for the gap question honestly — If you haven't managed direct reports, haven't held budget, or haven't operated at portfolio level, don't avoid it. The strongest answer is: 'Here's the gap, here's how I've been developing toward it, and here's what I'd focus on learning in the first 90 days.' Honesty with a plan lands significantly better than avoidance.

Choose a number to go deeper, or describe what you want to practice."


Branch 3: Newly Landed

Question 3B (Q2/3):

Agent asks:

"What's your most pressing challenge right now?"

  1. Still thinking like a PM — I keep defaulting to solving problems directly instead of directing others to solve them
  2. Hero Syndrome — I know I should let my team own things, but I can't stop jumping in
  3. Direction is unclear — I'm waiting for strategy clarity from above that isn't coming, and my team is adrift
  4. Stakeholder shift — I'm still relating to the wrong people — too much time with engineers, not enough with peers and executives

Or describe what's most pressing.

Question 3C (Q3/3):

Agent asks:

"What's your team situation?"

  1. Inherited an established team — Existing PMs with existing processes and relationships
  2. Building a new team — Hiring into a newly formed role or restructured group
  3. Mixed — Some experienced team members, some new, some in transition

Branch 3 Recommendations:

Agent delivers (based on 3B + 3C):

Example output for 3B = Direction is unclear + 3C = Inherited team:

"An inherited team without clear direction is the most common Director failure mode in the first 90 days. Here's what to do:

  1. Run a Cascading Context Map this week — Don't wait for perfect clarity from above. Take the most recent company priority you heard (QBR, all-hands, your manager's stated objectives) and translate it down: what does it mean for your business unit, your portfolio, your team's specific accountabilities? One page. Share it. Revise it when you learn more.

  2. Reframe your 1-on-1s immediately — Most inherited teams will use 1-on-1s to brief you on feature status and tactical priorities. Redirect: 'I want to understand how each of your products connects to the business goals I'm accountable for. Help me see the through-line.' This establishes altitude from day one.

  3. Name the ambiguity explicitly to your team — Don't pretend you have clarity you don't have. 'I'm still building my picture of where leadership wants us to go. Here's my best current translation. I'll update it in two weeks.' Teams would rather have honest partial context than silence.

  4. Resist the urge to reorganize before you understand — With an inherited team, the instinct is to reorganize processes and structures to reflect how you think. Wait 60–90 days. Understand what's working and why before you change it. The monkeys in the room aren't always wrong — some of them built the place.

Choose a number to go deeper, or describe what's most blocking you."


Branch 4: Recalibrating

Question 4B (Q2/3):

Agent asks:

"What's the core friction? Where does the role feel most broken right now?"

  1. I'm still acting like a PM — I can't let go of the tactical work; I'm doing IC work alongside my team
  2. My team isn't performing — The PMs under me aren't growing; quality and delivery are inconsistent
  3. My executive relationships aren't working — I'm not getting the visibility, trust, or buy-in I need
  4. I don't have portfolio clarity — My product portfolio lacks coherent strategy; I'm managing a collection of roadmaps, not a system

Or describe what's not working.

Question 4C (Q3/3):

Agent asks:

"How long have you been in this Director role?"

  1. Under 1 year — Still in the transition period
  2. 1–2 years — Past the transition; this feels like a persistent pattern
  3. 2+ years — Established in the role; this has become a structural issue

Branch 4 Recommendations:

Agent delivers (based on 4B + 4C):

Example output for 4B = Still acting like a PM + 4C = 1–2 years:

"A Director who is still doing IC work after 12+ months isn't transitioning — they've settled into an unsustainable hybrid role. Here's the diagnosis and the fix:

  1. Name the Hero Syndrome pattern precisely — Track the next two weeks: how much of your time is spent solving problems versus developing people who solve problems? Most Directors in this pattern are at 60–70% IC work. The target is closer to 20%.

  2. Identify what's keeping you in it — There are usually three causes: (a) you trust your own judgment more than your team's, (b) the team hasn't been developed enough to own things without you, (c) you're getting reward signals (praise, visibility) that reinforce the IC behavior. Which one is it?

  3. Create a deliberate handoff for your top 3 IC activities — List the three things you do most often that a PM should own. For each: write down what 'done well' looks like, have a conversation with the PM about owning it, and then don't rescue when they struggle. Coaching through failure is the work.

  4. Change the reward loop — The pat-on-the-back you got as a PM doesn't come as a Director. Director success is quieter and more delayed. Find the new signal: a PM who ships a difficult stakeholder conversation alone, a team that creates its own context cascade, a portfolio decision you made that held up under pressure. Start noticing those wins.

  5. If this pattern is entrenched at 1–2 years, consider whether the role is the right fit — Some people are happier and more effective as senior ICs or Principal PMs. That's not failure — it's self-knowledge. The IC path is legitimate; the mismatch is staying in a Director role while operating as a PM.

Choose a number to go deeper, or tell me what you want to work on next."


Examples

See examples/conversation-flow.md for a full end-to-end interaction, including context intake, branch selection, and final recommendations.

Example: Newly Landed Director, Unclear Direction

Q1: "3 — Newly landed" Q2: "3 — Direction is unclear" Q3: "1 — Inherited an established team"

Agent output: Cascading Context Map instructions, advice on reframing 1-on-1s, naming ambiguity explicitly, and resisting premature reorganization. Links to altitude-horizon-framework for the full cascade template.


Example: PM Preparing, Strategic Narrative Gap

Q1: "1 — Preparing to make the leap" Q2: "3 — Strategic narrative" Q3: "2 — 3–6 months"

Agent output: 1-on-1 reframe tactics, cascade habit-building exercise, Hero Syndrome audit, and warning against over-indexing on Director thinking while still in PM role.


Common Pitfalls

Pitfall 1: Treating Preparation Like a Checklist

Symptom: Asking "what do I need to do to get promoted?" and working through items like tasks

Consequence: You optimize for appearances of readiness rather than building the actual muscles. Interviewers and managers can tell the difference.

Fix: Use this advisor to identify the one or two specific behavior changes that matter most for your situation, not a comprehensive development program.


Pitfall 2: Misidentifying Your Situation

Symptom: Selecting "preparing" when you're actually in an active interview process, or selecting "newly landed" when you've been in the role 18 months

Consequence: You get coaching calibrated to the wrong situation.

Fix: Be honest about where you actually are, not where you'd like to be.


Pitfall 3: Looking for Permission

Symptom: Asking this advisor whether you're "ready" for the transition

Consequence: There's no readiness test. The transition is a decision, not a graduation.

Fix: Use this skill to identify what will be hardest for you specifically and how to address it — not to get a pass/fail verdict.


References

Related Skills

  • skills/altitude-horizon-framework/SKILL.md — The mental model this skill coaches on; includes the Cascading Context Map template
  • skills/workshop-facilitation/SKILL.md — Facilitation protocol for this interactive skill

Future Skills

  • director-to-vp-cpo-advisor (planned) — Coaches the next transition: Director to VP or CPO of Product

Source Material

External Frameworks

  • Marty Cagan, Empowered — Organizational dynamics and role clarity
  • Julie Zhuo, The Making of a Manager — IC-to-manager transition
  • Michael Watkins, The First 90 Days — Structured approach to leadership transitions
指导产品经理规划客户探索访谈,通过交互式问答明确研究目标、细分人群及约束条件,推荐适配的方法论并生成包含问题框架和成功标准的定制访谈计划,避免确认偏误。
准备客户探索访谈 验证产品问题或假设 调查用户流失原因 新产品创意前期调研
skills/discovery-interview-prep/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill discovery-interview-prep -g -y
SKILL.md
Frontmatter
{
    "name": "discovery-interview-prep",
    "type": "interactive",
    "theme": "discovery-research",
    "intent": "Guide product managers through preparing for customer discovery interviews by asking adaptive questions about research goals, customer segments, constraints, and methodologies. Use this to design effective interview plans, craft targeted questions, avoid common biases, and maximize learning from limited customer access—ensuring discovery interviews yield actionable insights rather than confirmation bias or surface-level feedback.",
    "best_for": [
        "Designing a customer discovery interview plan",
        "Choosing the right interview methodology for your goals and constraints",
        "Preparing for research with limited customer access"
    ],
    "scenarios": [
        "I need to interview 5 enterprise customers about why they churned in the last 90 days",
        "I'm validating a new product idea with a 2-week deadline and cold outreach only",
        "I want to understand why users aren't activating on our core feature"
    ],
    "description": "Plan customer discovery interviews with the right goal, segment, constraints, and method. Use when preparing interviews for problem validation, churn research, or new product ideas.",
    "argument-hint": "[research goal]",
    "estimated_time": "15-20 min"
}

Purpose

Guide product managers through preparing for customer discovery interviews by asking adaptive questions about research goals, customer segments, constraints, and methodologies. Use this to design effective interview plans, craft targeted questions, avoid common biases, and maximize learning from limited customer access—ensuring discovery interviews yield actionable insights rather than confirmation bias or surface-level feedback.

This is not a script generator—it's a strategic prep process that outputs a tailored interview plan with methodology, question framework, and success criteria.

Input

Works best with: Your research goal — what you need to learn from customers. Also useful: Customer segment, access constraints (how many interviews, by when), and any hypotheses you're carrying in.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill opens by asking your primary goal for the interviews, then narrows with follow-ups.

Example invocation: Prep interviews to understand why enterprise customers churn after 6 months — I can get 5 interviews in 2 weeks.

Key Concepts

The Discovery Interview Prep Flow

An interactive process that:

  1. Gathers product/problem context (marketing materials, assumptions)
  2. Defines research goals (what you're trying to learn)
  3. Identifies target customer segment and access constraints
  4. Recommends interview methodology (Jobs-to-be-Done, problem validation, switch interviews, etc.)
  5. Generates interview framework with questions, biases to avoid, and success metrics

Why This Works

  • Goal-driven: Aligns interview approach to what you need to learn
  • Adaptive: Adjusts methodology based on product stage (idea vs. existing product) and access constraints
  • Bias-aware: Highlights common pitfalls (leading questions, confirmation bias, solution-first thinking)
  • Actionable: Outputs interview guide ready to use

Anti-Patterns (What This Is NOT)

  • Not a user testing script: Discovery = learning problems; testing = validating solutions
  • Not a sales demo: Don't pitch—listen and learn
  • Not surveys at scale: Deep qualitative interviews (5-10 people), not broad surveys (100+ people)

When to Use This

  • Starting product discovery (validating problem space)
  • Repositioning an existing product (understanding new market)
  • Investigating churn or drop-off (retention interviews)
  • Evaluating feature ideas before building
  • Preparing for customer development sprints

When NOT to Use This

  • User testing a prototype (use usability testing frameworks instead)
  • Quantitative research at scale (use surveys, analytics)
  • When you already know the problem (move to solution validation)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 4 adaptive questions, offering 3-4 enumerated options at each step.


Step 0: Gather Context (Before Questions)

Agent suggests:

Before we design your interview plan, let's gather context:

For Your Own Product (Existing or Planned):

  • Problem hypothesis or product concept description
  • Target customer segment (if known)
  • Existing research (support tickets, churn data, user feedback)
  • Product website or positioning materials
  • Key assumptions you're trying to validate

For Investigating an Existing Problem:

  • Customer complaints, support tickets, or churn reasons
  • Hypotheses about why customers leave or struggle
  • Competitive alternatives customers switch to

If Exploring a New Problem Space:

  • Find similar products or adjacent solutions
  • Copy competitor materials, customer reviews (G2, Capterra), or community discussions (Reddit, forums)
  • We'll use these to frame hypotheses

You can paste this content directly, or we can proceed with a brief description.


Question 1: Research Goal

Agent asks: "What's the primary goal of these discovery interviews? (What do you need to learn?)"

Offer 4 enumerated options:

  1. Problem validation — "Confirm that a problem exists and is painful enough to solve" (for new product ideas)
  2. Jobs-to-be-Done discovery — "Understand what customers are trying to accomplish and why current solutions fail" (for product strategy)
  3. Retention/churn investigation — "Figure out why customers leave or don't activate" (for existing products with churn issues)
  4. Feature prioritization — "Validate which problems/features matter most to customers" (for roadmap planning)

Or describe your own research goal (be specific: what question are you trying to answer?).

User response: [Selection or custom]


Question 2: Target Customer Segment

Agent asks: "Who are you interviewing? (Be as specific as possible.)"

Offer 4 enumerated options (adapted based on Q1):

Example (if Q1 = Problem validation):

  1. People who experience the problem regularly — E.g., "Small business owners who manually process invoices weekly" (high pain frequency)
  2. People who've tried to solve it — E.g., "Users who've tried 2+ competing solutions and churned" (understand failures)
  3. People in the target segment (regardless of problem awareness) — E.g., "All freelancers, even if they don't realize invoicing is a problem" (uncover latent needs)
  4. People who've recently experienced the problem — E.g., "Customers who churned in the last 30 days" (fresh memory)

Or describe your specific target segment (role, company size, behaviors, demographics).

Adaptation tip: Use personas or customer segments from provided materials.

User response: [Selection or custom]


Question 3: Constraints

Agent asks: "What constraints are you working with for these interviews?"

Offer 4 enumerated options:

  1. Limited access — "Can only interview 5-10 customers, need results in 2 weeks" (common for startups or fast timelines)
  2. Existing customer base — "Have 100+ active customers, can recruit easily" (mature product advantage)
  3. Cold outreach required — "No existing customers; need to recruit from scratch via LinkedIn, ads, or communities" (new product challenge)
  4. Internal stakeholders only — "Can interview sales/support teams who talk to customers daily" (proxy research, less ideal but pragmatic)

Or describe your specific constraints (budget, time, access, team capacity).

User response: [Selection or custom]


Question 4: Interview Methodology

Agent asks: "Based on your goal ([Q1]), target segment ([Q2]), and constraints ([Q3]), here are recommended interview methodologies:"

Offer 3-4 enumerated options (context-aware based on Q1-Q3):

Example (if Q1 = Problem validation, Q2 = People who experience problem regularly, Q3 = Limited access):

  1. Problem validation interviews (Mom Test style) — Ask about past behavior, not hypotheticals. Focus on: "Tell me about the last time you [experienced the problem]. What did you try? What happened?" (Best for: Validating if problem is real and painful)

  2. Jobs-to-be-Done (JTBD) interviews — Focus on what customers are trying to accomplish, not what they want. Ask: "What were you trying to get done? What alternatives did you consider? What made you choose X?" (Best for: Understanding motivations and switching behavior)

  3. Switch interviews — Interview customers who recently switched from a competitor or alternative. Ask: "What prompted you to look for a new solution? What was the 'push' away from the old tool? What 'pulled' you to try ours?" (Best for: Understanding competitive positioning and unmet needs)

  4. Timeline/journey mapping interviews — Walk through their entire experience chronologically. Ask: "Walk me through the first time you encountered this problem. What happened next? How did you try to solve it?" (Best for: Uncovering full context and pain points)

Choose a number, combine approaches (e.g., '1 & 2'), or describe your own methodology.

Adaptation examples:

  • If Q1 = Retention/churn → Prioritize "Exit interviews" or "Switch interviews (away from your product)"
  • If Q1 = Feature prioritization → Prioritize "Opportunity solution tree interviews" or "Kano model interviews"
  • If Q3 = Internal stakeholders only → Add caveat: "Proxy research (talking to sales/support) is better than nothing, but validate with real customers ASAP"

User response: [Selection or custom]


Output: Generate Interview Plan

After collecting responses, the agent generates a tailored interview plan:

# Discovery Interview Plan

**Research Goal:** [From Q1]
**Target Segment:** [From Q2]
**Constraints:** [From Q3]
**Methodology:** [From Q4]

---

## Interview Framework

### Opening (5 minutes)
- **Build rapport:** "Thanks for taking the time. I'm [name], and I'm researching [problem space]. This isn't a sales call—I'm here to learn from your experience."
- **Set expectations:** "I'll ask about your experiences with [topic]. There are no right answers. Feel free to be honest—critical feedback is most helpful."
- **Get consent:** "Is it okay if I take notes / record this conversation?"

---

### Core Questions (30-40 minutes)

**Based on your methodology ([Q4]), here are suggested questions:**

#### [Methodology Name] Questions:

1. **[Question 1]** — [Rationale for asking this]
   - **Follow-up:** [Dig deeper with...]
   - **Avoid:** [Don't ask leading version like...]

2. **[Question 2]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

3. **[Question 3]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

4. **[Question 4]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

5. **[Question 5]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

**Example (if Methodology = Problem validation - Mom Test style):**

1. **"Tell me about the last time you [experienced this problem]."** — Gets specific, recent behavior (not hypothetical)
   - **Follow-up:** "What were you trying to accomplish? What made it hard? What did you try?"
   - **Avoid:** "Would you use a tool that solves this?" (leading, hypothetical)

2. **"How do you currently handle [this problem]?"** — Reveals workarounds, alternatives, pain intensity
   - **Follow-up:** "How much time/money does that take? What's frustrating about it?"
   - **Avoid:** "Don't you think that's inefficient?" (leading)

3. **"Can you walk me through what you did step-by-step?"** — Uncovers details, edge cases, context
   - **Follow-up:** "What happened next? Where did you get stuck?"
   - **Avoid:** "Was it hard?" (yes/no question, not useful)

4. **"Have you tried other solutions for this?"** — Reveals competitive landscape, unmet needs
   - **Follow-up:** "What did you like/dislike? Why did you stop using it?"
   - **Avoid:** "Would you pay for a better solution?" (hypothetical)

5. **"If you had a magic wand, what would change?"** — Opens space for ideal outcomes (but treat with skepticism—focus on past behavior, not wishes)
   - **Follow-up:** "Why does that matter to you? What would that enable?"
   - **Avoid:** Taking feature requests literally

---

### Closing (5 minutes)
- **Summarize:** "Just to recap, I heard that [key insights]. Did I get that right?"
- **Ask for referrals:** "Do you know anyone else who experiences this problem? Could you introduce me?"
- **Thank them:** "This was incredibly helpful. I really appreciate your time."

---

## Biases to Avoid

1. **Confirmation bias:** Don't ask "Don't you think X is a problem?" → Ask "Tell me about your experience with X."
2. **Leading questions:** Don't ask "Would you use this?" → Ask "What have you tried? Why did it work/fail?"
3. **Hypothetical questions:** Don't ask "If we built Y, would you pay?" → Ask "What do you currently pay for? Why?"
4. **Pitching disguised as research:** Don't say "We're building Z to solve X" → Say "I'm researching X. Tell me about your experience."
5. **Yes/no questions:** Don't ask "Is invoicing hard?" → Ask "Walk me through your invoicing process."

---

## Success Criteria

You'll know these interviews are successful if:

✅ **You hear specific stories, not generic complaints** — "Last Tuesday, I spent 3 hours..." vs. "Invoicing is annoying"
✅ **You uncover past behavior, not hypothetical wishes** — "I tried Zapier but quit after 2 weeks" vs. "I'd probably use automation"
✅ **You identify patterns across 3+ interviews** — Same pain points emerge independently
✅ **You're surprised by something** — If everything confirms your assumptions, you're asking leading questions
✅ **You can quote customers verbatim** — Actual language = authentic insights

---

## Interview Logistics

**Recruiting:**
- [Based on Q3 constraints, suggest recruitment channels]
- **Example (if Q3 = Limited access):** "Reach out to 20-30 people to get 5-10 interviews (33% response rate is typical)"
- **Example (if Q3 = Existing customers):** "Email 50 customers with $50 Amazon gift card incentive"

**Scheduling:**
- 45-60 minutes per interview (30-40 min conversation + buffer)
- Record if possible (with consent), or take detailed notes
- Schedule 2-3 per day max (you need time to synthesize)

**Synthesis:**
- After each interview, write key insights immediately (memory fades fast)
- After 5 interviews, look for patterns (common pains, jobs, workarounds)
- Use `problem-statement.md` to frame findings

---

**Ready to start recruiting and interviewing? Let me know if you'd like to refine any part of this plan.**

Examples

Example 1: Good Discovery Interview Prep (Problem Validation)

Step 0 - Context: User shares hypothesis: "Freelancers waste time chasing late payments manually."

Q1 Response: "Problem validation — Confirm that late payment follow-ups are painful enough to solve"

Q2 Response: "People who experience the problem regularly — Freelancers who invoice 5+ clients monthly"

Q3 Response: "Cold outreach required — No existing customers; need to recruit via LinkedIn, Reddit, freelancer communities"

Q4 Response: "Problem validation interviews (Mom Test style) — Focus on past behavior, not hypotheticals"

Generated Plan: Includes 5 Mom Test-style questions (last time you chased a late payment, how do you currently handle it, what have you tried, etc.), biases to avoid (leading questions, hypotheticals), and success criteria (specific stories, past behavior, patterns across 3+ interviews).

Why this works:

  • Goal is clear (validate if problem is real)
  • Segment is specific (freelancers with 5+ clients/month)
  • Methodology matches goal (Mom Test for validation)
  • Questions focus on past behavior, not wishes
  • Success criteria are measurable

Common Pitfalls

Pitfall 1: Asking What Customers Want

Symptom: "What features do you want us to build?"

Consequence: You get feature requests, not problems. Customers don't know solutions.

Fix: Ask about past behavior: "Tell me about the last time you struggled with X."


Pitfall 2: Pitching Instead of Listening

Symptom: Spending 20 minutes explaining your product idea

Consequence: Customer feels obligated to be nice. No honest feedback.

Fix: Don't mention your solution until the last 5 minutes (if at all). Focus on their problems.


Pitfall 3: Interviewing the Wrong People

Symptom: Interviewing friends, family, or people who don't experience the problem

Consequence: Polite feedback, not real insights.

Fix: Interview people who experience the problem regularly and recently.


Pitfall 4: Stopping at 1-2 Interviews

Symptom: "We talked to 2 people, they liked it, let's build!"

Consequence: Small sample = confirmation bias.

Fix: Interview 5-10 people minimum. Look for patterns, not one-off feedback.


Pitfall 5: Not Recording Insights

Symptom: Relying on memory after interviews

Consequence: Lose details, misremember quotes, can't spot patterns.

Fix: Record (with consent) or take detailed notes. Synthesize immediately after each interview.


References

Related Skills

  • problem-statement.md — Use interview insights to frame problem statement
  • proto-persona.md — Define interview target segment
  • jobs-to-be-done.md — JTBD methodology for interviews

External Frameworks

  • Rob Fitzpatrick, The Mom Test (2013) — How to ask good questions without biasing answers
  • Clayton Christensen, Jobs to Be Done — Interview methodology for understanding motivations
  • Teresa Torres, Continuous Discovery Habits (2021) — Opportunity solution tree interviews

Dean's Work

  • Problem Framing Canvas (synthesizes interview findings)

Skill type: Interactive Suggested filename: discovery-interview-prep.md Suggested placement: /skills/interactive/ Dependencies: Uses problem-statement.md, proto-persona.md, jobs-to-be-done.md

引导产品经理完成从问题假设到验证方案的完整发现周期。通过编排问题界定、访谈、综合分析和实验,系统化探索问题空间并验证假设,避免盲目开发,确保解决真实客户问题,支持持续迭代决策。
需要结构化路径探索新问题或功能领域 调查留存率或流失问题 在承诺路线图前验证战略举措 团队需要从假设到验证的端到端发现流程
skills/discovery-process/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill discovery-process -g -y
SKILL.md
Frontmatter
{
    "name": "discovery-process",
    "type": "workflow",
    "theme": "discovery-research",
    "intent": "Guide product managers through a complete discovery cycle—from initial problem hypothesis to validated solution—by orchestrating problem framing, customer interviews, synthesis, and experimentation skills into a structured process. Use this to systematically explore problem spaces, validate assumptions, and build confidence before committing to full development—avoiding \"build it and they will come\" syndrome and ensuring you're solving real customer problems.",
    "best_for": [
        "Running a full discovery cycle from hypothesis to validated solution",
        "Investigating a retention or churn problem systematically",
        "Setting up continuous discovery as an ongoing practice"
    ],
    "scenarios": [
        "I have a hypothesis that B2B customers struggle with onboarding and want to validate it before building anything",
        "Our activation rate dropped 15% this quarter and I need to run discovery to find out why"
    ],
    "description": "Run a full discovery cycle from problem hypothesis to validated solution. Use when a team needs a structured path through framing, interviews, synthesis, and experiments.",
    "argument-hint": "[problem hypothesis]",
    "estimated_time": "30-60 min"
}

Purpose

Guide product managers through a complete discovery cycle—from initial problem hypothesis to validated solution—by orchestrating problem framing, customer interviews, synthesis, and experimentation skills into a structured process. Use this to systematically explore problem spaces, validate assumptions, and build confidence before committing to full development—avoiding "build it and they will come" syndrome and ensuring you're solving real customer problems.

This is not a one-time research project—it's a continuous discovery practice that runs in parallel with delivery, typically 1-2 discovery cycles per quarter.

Input

Works best with: Your starting problem hypothesis — even a rough one. Also useful: Prior research, customer access, timeline, and what decision the discovery must inform.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workflow starts at problem framing and helps you construct the hypothesis first.

Example invocation: Run discovery on this hypothesis: SMB admins abandon onboarding because the data-import step requires IT help they don't have.

Key Concepts

What is the Discovery Process?

The discovery process (Teresa Torres, Marty Cagan) is a structured approach to exploring problem spaces and validating solutions before building. It consists of:

  1. Frame the Problem — Define what you're investigating and why
  2. Conduct Research — Gather qualitative and quantitative evidence
  3. Synthesize Insights — Identify patterns, pain points, and opportunities
  4. Generate Solutions — Explore multiple solution options
  5. Validate Solutions — Test assumptions through experiments
  6. Decide & Document — Commit to build, pivot, or kill

Why This Works

  • De-risks product decisions: Tests assumptions before expensive builds
  • Customer-centric: Grounds decisions in real customer problems, not internal opinions
  • Iterative: Builds confidence progressively through small experiments
  • Fast learning: Discovers "no-go" signals early, saves wasted effort

Anti-Patterns (What This Is NOT)

  • Not waterfall research: Discovery runs continuously, not once before dev
  • Not user testing: Discovery validates problems; testing validates solutions
  • Not a substitute for shipping: Discovery informs delivery, doesn't replace it

When to Use This

  • Exploring new product/feature areas
  • Investigating retention or churn problems
  • Validating strategic initiatives before roadmap commitment
  • Continuous discovery (weekly customer touchpoints)

When NOT to Use This

  • For well-understood problems (move to execution)
  • When stakeholders have already committed to a solution (address alignment first)
  • For tactical bug fixes or technical debt (no discovery needed)

Facilitation Source of Truth

When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.

Application

Use template.md for the full fill-in structure.

This workflow orchestrates 6 phases over 2-4 weeks, using multiple component and interactive skills.


Phase 1: Frame the Problem (Day 1-2)

Goal: Define what you're investigating, who's affected, and success criteria.

Activities

1. Run Problem Framing Canvas

  • Use: skills/problem-framing-canvas/SKILL.md (interactive - MITRE)
  • Participants: PM, design, engineering lead
  • Duration: 120 minutes
  • Output: Problem statement + "How Might We" question

2. Create Formal Problem Statement

  • Use: skills/problem-statement/SKILL.md (component)
  • Participants: PM
  • Duration: 30 minutes
  • Output: Structured problem statement with hypothesis

3. Define Proto-Personas (If Needed)

  • Use: skills/proto-persona/SKILL.md (component)
  • When: If target customer segment is unclear
  • Duration: 60 minutes
  • Output: Hypothesis-driven personas

4. Map Jobs-to-be-Done (If Needed)

  • Use: skills/jobs-to-be-done/SKILL.md (component)
  • When: If customer motivations are unclear
  • Duration: 60 minutes
  • Output: JTBD statements

Outputs from Phase 1

  • Problem hypothesis: "We believe [persona] struggles with [problem] because [root cause], leading to [consequence]."
  • Research questions: 3-5 questions to answer through discovery
  • Success criteria: What would validate/invalidate the problem?

Decision Point 1: Do we have enough context to start research?

If YES: Proceed to Phase 2 (Research Planning)

If NO: Gather existing data first:

  • Review support tickets, churn surveys, NPS feedback
  • Analyze product analytics (drop-off points, usage patterns)
  • Review competitor research, market trends
  • Time impact: +2-3 days

Phase 2: Research Planning (Day 3)

Goal: Design research approach, recruit participants, prepare interview guide.

Activities

1. Prep Discovery Interviews

  • Use: skills/discovery-interview-prep/SKILL.md (interactive)
  • Participants: PM, design
  • Duration: 90 minutes
  • Output: Interview plan with methodology, questions, biases to avoid

2. Recruit Participants

  • Target: 5-10 customers per discovery cycle (Teresa Torres: continuous discovery = 1 interview/week)
  • Segment: Focus on personas from Phase 1
  • Recruitment channels:
    • Existing customers (email, in-app prompts)
    • Churned customers (exit interviews)
    • Cold outreach (LinkedIn, communities)
  • Incentive: $50-100 gift card or product credit
  • Duration: 2-3 days (parallel with Phase 1)

3. Schedule Interviews

  • Format: 45-60 min per interview (30-40 min conversation + buffer)
  • Timeline: Spread across 1-2 weeks
  • Recording: Get consent, record for synthesis

Outputs from Phase 2

  • Interview guide: 5-7 open-ended questions (Mom Test style)
  • Participant roster: 5-10 scheduled interviews
  • Synthesis plan: How you'll capture and analyze insights

Phase 3: Conduct Research (Week 1-2)

Goal: Gather qualitative evidence through customer interviews.

Activities

1. Conduct Discovery Interviews

  • Methodology: From skills/discovery-interview-prep/SKILL.md (Problem validation, JTBD, switch interviews, etc.)
  • Participants: PM + optional observer (design, eng)
  • Duration: 5-10 interviews over 1-2 weeks
  • Focus areas:
    • Past behavior (not hypotheticals): "Tell me about the last time you [experienced this problem]"
    • Workarounds: "How do you currently handle this?"
    • Alternatives tried: "Have you tried other solutions? Why did you stop?"
    • Pain intensity: "How much time/money does this cost you?"

2. Take Structured Notes

  • Template:
    • Participant: [Name, role, company size]
    • Context: [When/where they experience problem]
    • Actions: [What they do, step-by-step]
    • Pain points: [Frustrations, blockers]
    • Workarounds: [Current solutions]
    • Quotes: [Verbatim customer language]
    • Insights: [Patterns, surprises]

3. Review Support Tickets & Analytics (Parallel)

  • Support tickets: Tag by theme (onboarding, feature confusion, bugs)
  • Analytics: Identify drop-off points, feature usage, cohort behavior
  • Surveys: Review NPS comments, exit surveys, feature requests

Outputs from Phase 3

  • Interview transcripts: Recorded sessions + detailed notes
  • Support ticket themes: Top 10 issues by frequency
  • Analytics insights: Quantitative data on behavior (e.g., "60% abandon onboarding at step 3")

Decision Point 2: Have we reached saturation?

Saturation = same pain points emerge across 3+ interviews, no new insights

If YES (saturated after 5-7 interviews): Proceed to Phase 4 (Synthesis)

If NO (still learning new things): Schedule 3-5 more interviews

  • Time impact: +1 week

Phase 4: Synthesize Insights (End of Week 2)

Goal: Identify patterns, prioritize pain points, map opportunities.

Activities

1. Affinity Mapping (Thematic Analysis)

  • Method:
    • Write each insight/quote on sticky note
    • Group by theme (e.g., "onboarding confusion," "pricing objections," "mobile access")
    • Count frequency (how many customers mentioned each theme)
  • Participants: PM, design, optional eng
  • Duration: 90-120 minutes
  • Output: Themed clusters with frequency counts

2. Create Customer Journey Map (Optional)

  • Use: skills/customer-journey-mapping-workshop/SKILL.md (interactive)
  • When: If pain points span multiple phases (discover, try, buy, use, support)
  • Duration: 90 minutes
  • Output: Journey map with opportunities ranked by impact

3. Prioritize Pain Points

  • Criteria:
    • Frequency: How many customers mentioned this?
    • Intensity: How painful is it? (time wasted, money lost, emotional frustration)
    • Strategic fit: Does solving this align with business goals?
  • Method: Score each pain point (1-5) on frequency, intensity, strategic fit
  • Output: Ranked list of top 3-5 pain points to address

4. Update Problem Statement

  • Use: skills/problem-statement/SKILL.md (component)
  • Refine based on research: Did initial hypothesis hold? Adjust if needed.
  • Output: Validated problem statement

Outputs from Phase 4

  • Affinity map: Themes with frequency counts
  • Top 3-5 pain points: Prioritized by frequency × intensity × strategic fit
  • Customer quotes: 3-5 verbatim quotes per pain point
  • Validated problem statement: Refined based on evidence

Phase 5: Generate & Validate Solutions (Week 3)

Goal: Explore solution options, design experiments, validate assumptions.

Activities

1. Generate Opportunity Solution Tree

  • Use: skills/opportunity-solution-tree/SKILL.md (interactive)
  • Input: Top 3 pain points from Phase 4
  • Participants: PM, design, engineering lead
  • Duration: 90 minutes
  • Output: 3 opportunities, 3 solutions per opportunity, POC recommendation

Alternative: Use Lean UX Canvas

  • Use: skills/lean-ux-canvas/SKILL.md (interactive)
  • When: Prefer hypothesis-driven approach over OST
  • Output: Hypotheses to test, minimal experiments

2. Design Experiments

  • For each solution: Define "What's the least work to learn the next most important thing?"
  • Experiment types:
    • Concierge test: Manually deliver solution to 10 customers, observe
    • Prototype test: Clickable mockup, usability test with 10 users
    • Landing page test: Fake door test (show feature, measure interest)
    • A/B test: Build minimal version, test with 50% of users
  • Success criteria: What metric/behavior validates hypothesis?

3. Run Experiments

  • Timeline: 1-2 weeks per experiment
  • Participants: PM + design (for prototypes), eng (for A/B tests)
  • Output: Quantitative and qualitative validation data

Outputs from Phase 5

  • Solution options: 3-9 solutions (3 per opportunity)
  • Experiment results: Did hypothesis validate or invalidate?
  • Customer feedback: Qualitative reactions to prototypes/concepts

Decision Point 3: Did experiments validate solution?

If YES (validated): Proceed to Phase 6 (Decide & Document)

If NO (invalidated):

  • Pivot to next solution option
  • Re-run experiments with adjusted approach
  • Time impact: +1-2 weeks

Phase 6: Decide & Document (End of Week 3-4)

Goal: Commit to build, document decision, communicate to stakeholders.

Activities

1. Make Go/No-Go Decision

  • Criteria:
    • Problem validated? (Phase 3-4)
    • Solution validated? (Phase 5)
    • Strategic fit? (aligns with business goals)
    • Feasible? (engineering capacity, technical complexity)
  • Decision:
    • GO: Move to roadmap, write epics/stories
    • PIVOT: Explore alternative solution
    • KILL: De-prioritize, not worth solving now

2. Define Epic Hypotheses (If GO)

  • Use: skills/epic-hypothesis/SKILL.md (component)
  • Participants: PM
  • Duration: 60 minutes per epic
  • Output: Epic hypothesis statement with success criteria

3. Write PRD (If GO)

  • Use: skills/prd-development/SKILL.md (workflow)
  • Participants: PM
  • Duration: 1-2 days
  • Output: Structured PRD with problem, solution, success metrics

4. Communicate Findings

  • Format: 30-min readout covering:
    • Problem validation (Phase 3-4 insights)
    • Solution validation (Phase 5 experiments)
    • Recommendation (GO/PIVOT/KILL)
  • Participants: Execs, product leadership, key stakeholders
  • Output: Alignment on next steps

Outputs from Phase 6

  • Decision: GO, PIVOT, or KILL
  • Epic hypotheses: (if GO) Testable epic statements
  • PRD: (if GO) Formal product requirements document
  • Stakeholder alignment: Exec buy-in on recommendation

Complete Workflow: End-to-End Summary

Week 1:
├─ Day 1-2: Frame the Problem
│  ├─ skills/problem-framing-canvas/SKILL.md (120 min)
│  ├─ skills/problem-statement/SKILL.md (30 min)
│  └─ [Optional] skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md
│
├─ Day 3: Research Planning
│  ├─ skills/discovery-interview-prep/SKILL.md (90 min)
│  ├─ Recruit participants (2-3 days)
│  └─ Schedule 5-10 interviews
│
└─ Day 4-5: Conduct Research (Start)
   └─ First 2-3 customer interviews

Week 2:
├─ Day 1-3: Conduct Research (Continue)
│  └─ Remaining customer interviews (3-7 more)
│
├─ Day 4-5: Synthesize Insights
│  ├─ Affinity mapping (120 min)
│  ├─ [Optional] skills/customer-journey-mapping-workshop/SKILL.md (90 min)
│  ├─ Prioritize pain points
│  └─ Update problem statement
│
└─ Decision: Reached saturation? (if NO, +1 week more interviews)

Week 3:
├─ Day 1-2: Generate & Validate Solutions
│  ├─ skills/opportunity-solution-tree/SKILL.md (90 min)
│  └─ Design experiments
│
├─ Day 3-5: Run Experiments
│  ├─ Concierge tests, prototypes, or A/B tests
│  └─ Gather validation data
│
└─ Decision: Validated? (if NO, pivot to next solution, +1-2 weeks)

Week 4:
└─ Decide & Document
   ├─ Make GO/NO-GO decision
   ├─ [If GO] skills/epic-hypothesis/SKILL.md (60 min per epic)
   ├─ [If GO] skills/prd-development/SKILL.md (1-2 days)
   └─ Communicate findings (30 min readout)

Total Time Investment:

  • Fast track: 3 weeks (5 interviews, 1 experiment)
  • Typical: 4 weeks (7-10 interviews, 1-2 experiments)
  • Thorough: 6-8 weeks (10+ interviews, multiple experiment rounds)

Examples

See examples/sample.md for a full discovery process example.

Mini example excerpt:

**Problem:** Onboarding drop-off due to jargon
**Insight:** 6/10 users quit at step 3
**Decision:** Go with guided checklist experiment

Common Pitfalls

Pitfall 1: Skipping Customer Interviews

Symptom: Rely only on analytics and support tickets, no qualitative research

Consequence: Miss "why" behind behavior, build wrong solutions

Fix: Always interview 5-10 customers per discovery cycle (even if you have data)


Pitfall 2: Asking Leading Questions

Symptom: "Would you use [feature X] if we built it?"

Consequence: Confirmation bias, customers say "yes" to be polite

Fix: Use Mom Test questions from skills/discovery-interview-prep/SKILL.md (focus on past behavior)


Pitfall 3: Not Reaching Saturation

Symptom: Interview 2-3 customers, declare discovery complete

Consequence: Small sample, not representative

Fix: Continue interviews until same patterns emerge across 3+ customers (typically 5-7 interviews minimum)


Pitfall 4: Analysis Paralysis

Symptom: Spend 6 weeks synthesizing insights, never move to solutions

Consequence: No delivery, team loses momentum

Fix: Time-box discovery to 3-4 weeks; after Phase 6, move to execution


Pitfall 5: Discovery as One-Time Activity

Symptom: Run discovery once before building, then stop

Consequence: Miss evolving customer needs, market changes

Fix: Continuous discovery (Teresa Torres): 1 customer interview per week, ongoing


References

Related Skills (Orchestrated by This Workflow)

Phase 1:

  • skills/problem-framing-canvas/SKILL.md (interactive)
  • skills/problem-statement/SKILL.md (component)
  • skills/proto-persona/SKILL.md (component, optional)
  • skills/jobs-to-be-done/SKILL.md (component, optional)

Phase 2:

  • skills/discovery-interview-prep/SKILL.md (interactive)

Phase 4:

  • skills/customer-journey-mapping-workshop/SKILL.md (interactive, optional)

Phase 5:

  • skills/opportunity-solution-tree/SKILL.md (interactive)
  • skills/lean-ux-canvas/SKILL.md (interactive, alternative)

Phase 6:

  • skills/epic-hypothesis/SKILL.md (component)
  • skills/prd-development/SKILL.md (workflow)

External Frameworks

  • Teresa Torres, Continuous Discovery Habits (2021) — Weekly customer touchpoints, OST framework
  • Rob Fitzpatrick, The Mom Test (2013) — How to ask good interview questions
  • Marty Cagan, Inspired (2017) — Product discovery principles

Dean's Work

  • Productside Blueprint — Strategic discovery process
  • [If Dean has discovery resources, link here]

Skill type: Workflow Suggested filename: discovery-process.md Suggested placement: /skills/workflows/ Dependencies: Orchestrates 10+ component and interactive skills across 6 phases

用于撰写清晰、富有同理心的产品或服务终止(EOL)公告。涵盖背景、原因、客户影响、迁移方案及时间表,旨在减少用户困惑与流失,维护信任并引导平滑过渡。
需要发布产品或功能下线通知 计划将客户从旧平台迁移至新平台 终止收购产品的服务 弃用技术栈或 API
skills/eol-message/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill eol-message -g -y
SKILL.md
Frontmatter
{
    "name": "eol-message",
    "type": "component",
    "intent": "Craft a clear, empathetic End-of-Life (EOL) message that communicates product or feature discontinuation, explains the rationale, addresses customer impact, provides transition support, and positions the replacement solution. Use this to maintain customer trust during difficult transitions and reduce churn by demonstrating care and offering a clear path forward.",
    "description": "Write a clear, empathetic EOL announcement with rationale, customer impact, and next steps. Use when retiring a product, feature, or plan without creating avoidable confusion.",
    "argument-hint": "[product or feature being retired]"
}

Purpose

Craft a clear, empathetic End-of-Life (EOL) message that communicates product or feature discontinuation, explains the rationale, addresses customer impact, provides transition support, and positions the replacement solution. Use this to maintain customer trust during difficult transitions and reduce churn by demonstrating care and offering a clear path forward.

This is not a generic sunset announcement—it's a customer-centric communication that acknowledges loss while framing the change as progress.

Input

Works best with: What's being retired (product, feature, or plan) and roughly when. Also useful: The rationale, affected customer segments, migration or replacement path, and support commitments.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the what/when/why before drafting — an EOL message without a stated rationale and next step reads as abandonment.

Example invocation: Draft an EOL message: retiring our legacy reporting module Dec 31, replaced by the new analytics dashboard; 400 accounts affected.

Key Concepts

The EOL Messaging Framework

An effective EOL message balances honesty about the change with empathy for customer impact. It includes:

  1. Company context: Who you are and your commitment to customers
  2. The announcement: What's being discontinued and what's replacing it
  3. The rationale: Why this decision benefits customers (not just the business)
  4. Current product context: What the product was and who it served
  5. Customer impact: How this affects users (acknowledge the disruption)
  6. Transition solution: What the replacement is and how it improves on the old
  7. Support measures: How you'll help customers migrate
  8. Timeline: Key dates and milestones
  9. Call to action: Next steps and contact info

Why This Works

  • Empathy-first: Acknowledges customer disruption before justifying the decision
  • Clarity: No ambiguity about what's changing and when
  • Support-focused: Shows you're not abandoning customers mid-transition
  • Future-oriented: Frames change as progress, not loss

Anti-Patterns (What This Is NOT)

  • Not a terse shutdown notice: "We're discontinuing Product X. Goodbye."
  • Not business-centric: Don't lead with "This reduces our costs"
  • Not vague: "Soon" is not a timeline
  • Not defensive: Don't blame customers ("low usage forced us to shut down")

When to Use This

  • Discontinuing a product, feature, or service
  • Migrating customers from legacy to new platform
  • Sunsetting an acquisition target's product
  • Deprecating a technology stack or API

When NOT to Use This

  • For minor feature tweaks (don't over-communicate small changes)
  • Before you have a transition plan (communicate after you know how you'll support customers)
  • If you're secretly hoping customers won't notice (be transparent)

Application

Use template.md for the full fill-in structure.

Step 1: Gather Context

Before drafting, ensure you have:

  • Product being discontinued: What specifically is ending?
  • Replacement solution: What's replacing it (if anything)?
  • Timeline: Key dates (announcement, feature freeze, shutdown, data export deadline)
  • Customer impact: How many users affected? What workflows disrupted?
  • Support plan: Migration support, training, discounts, data export tools
  • Rationale: Why is this happening? (Technology obsolescence, strategic shift, consolidation, etc.)

If missing context: Don't send the message until you have a complete transition plan. Customers will ask "What do I do now?"—you must have an answer.


Step 2: Draft the Product Transition Narrative

Company Context

Establish who you are and your commitment:

### Product Transition Narrative

**We are:** [Describe the company and its relationship to the product being phased out]
- [Key point about company's commitment to customers]
- [Key point about company's product evolution]
- [Key point about company's future vision]

Example:

**We are:** Acme Workflows, a workflow automation platform serving 50,000 small businesses
- We're committed to helping you save time and focus on what matters
- We continuously evolve our product based on your feedback and technological advances
- We're building toward a future where automation is accessible, powerful, and simple

The Announcement

Be clear and direct:

**Announcing:**
- [Single sentence that clearly states the EOL of the product and introduces its replacement]

Example:

  • "We are discontinuing Acme Workflows Classic on December 31, 2026, and migrating all customers to Acme Workflows Pro."

The Rationale (Customer-Benefit-Focused)

Explain why this benefits customers:

**Because:**
- [Reason 1: e.g., technological advancements]
- [Reason 2: e.g., improved performance]
- [Reason 3: e.g., better alignment with customer needs]

**Which means for you:**
- [Describe the impact and benefits from the customer's perspective]

Example:

**Because:**
- Acme Workflows Classic runs on outdated infrastructure that limits performance and scalability
- Acme Workflows Pro is built on modern technology that enables faster automation, better integrations, and real-time collaboration
- Consolidating to one platform allows us to invest 100% of our engineering resources in features you've requested

**Which means for you:**
- Faster automation execution (3x speed improvement)
- 50+ new integrations with tools you already use
- Access to new features like real-time collaboration and mobile app

Step 3: Provide Current Product Context

Acknowledge what's being lost:

### Current Product Context

**Our product** [name of the product being discontinued]
- **is a** [brief description of the product and its primary function]
- **that has served** [target customer/user] for [duration or timeframe]
- **by providing** [key benefits or solutions the product offered]

Example:

**Our product** Acme Workflows Classic
- **is a** workflow automation tool that helps small businesses eliminate repetitive tasks
- **that has served** over 20,000 customers for 8 years
- **by providing** reliable, straightforward automation without requiring technical expertise

Step 4: Acknowledge Customer Impact

Be honest about disruption:

### Customer Impact

**We understand that this may affect you by:**
- [Potential impact 1 on customer operations or processes]
- [Potential impact 2 on customer operations or processes]
- [Potential impact 3 on customer operations or processes (if applicable)]

Example:

**We understand that this may affect you by:**
- Requiring time to migrate workflows from Classic to Pro
- Learning new features and interface changes
- Updating integrations or API connections if you've customized workflows

Step 5: Present the Transition Solution

Use positioning statement format (reference skills/positioning-statement/SKILL.md):

### Transition Solution

**For** [target customer/user affected by the EOL]
- **that currently use** [name of the product being phased out]
- [name of the replacement product]
- **is a** [definition of the replacement product category]
- **that** [statement of benefit to the user, focusing on continuity and improvements]

### Differentiation and Continuity

- **Like** [product being phased out],
- [name of the replacement product]
- **provides** [how the replacement maintains key benefits of the old product]
- **while also offering** [new benefits or improvements]

Example:

### Transition Solution

**For** small business owners
- **that currently use** Acme Workflows Classic
- Acme Workflows Pro
- **is a** next-generation workflow automation platform
- **that** maintains all the simplicity and reliability you love while adding 3x faster performance, 50+ new integrations, and real-time collaboration

### Differentiation and Continuity

- **Like** Acme Workflows Classic,
- Acme Workflows Pro
- **provides** easy-to-build automations without coding, reliable execution, and straightforward pricing
- **while also offering** 3x faster workflows, mobile app access, real-time team collaboration, and integrations with tools like Slack, Asana, and Notion

Step 6: Outline Support Measures and Timeline

Support Measures

### Support and Next Steps

**To ensure a smooth transition, we will:**
- [Support measure 1, e.g., "Provide 1-on-1 migration assistance for all customers"]
- [Support measure 2, e.g., "Automatically migrate your workflows (with your approval)"]
- [Support measure 3, e.g., "Offer a 3-month discount on Acme Workflows Pro for existing customers"]

Timeline

### Timeline

- [Key date 1 and associated milestone, e.g., "March 1, 2026: Migration tool available"]
- [Key date 2 and associated milestone, e.g., "September 1, 2026: Acme Workflows Classic becomes read-only"]
- [Key date 3 and associated milestone, e.g., "December 31, 2026: Acme Workflows Classic fully discontinued, data export deadline"]

Quality checks:

  • Sufficient lead time: Customers need time to plan (6-12 months is typical)
  • Clear milestones: When does functionality freeze? When does shutdown happen?
  • Data export deadline: When do they lose access to their data?

Step 7: Provide Clear Next Steps

### Call to Action

- [Clear next steps for customers, e.g., "Log in to your account to start the migration wizard"]
- [Contact information for questions or assistance, e.g., "Contact our support team at support@acme.com or call 1-800-ACME-HELP"]

Examples

See examples/sample.md for a full EOL message example.

Mini example excerpt:

**Announcing:** We are discontinuing Acme Classic on Dec 31, 2026
**Because:** Legacy infrastructure limits performance
**Which means for you:** Faster automation + new integrations

Common Pitfalls

Pitfall 1: Business-Centric Rationale

Symptom: "We're discontinuing Product X to reduce costs and consolidate our portfolio."

Consequence: Customers feel like collateral damage in a business decision.

Fix: Frame rationale around customer benefits: "We're consolidating to Product Y so we can invest 100% of resources in features you've requested."


Pitfall 2: Vague Timeline

Symptom: "Product X will be discontinued soon."

Consequence: Customers can't plan. Anxiety and churn increase.

Fix: Provide specific dates: "March 1: Migration tool available. December 31: Full shutdown."


Pitfall 3: No Support Plan

Symptom: "You'll need to migrate to Product Y. Good luck!"

Consequence: Customers feel abandoned. High churn risk.

Fix: Offer migration support: "1-on-1 assistance, auto-migration tool, 3-month discount, training resources."


Pitfall 4: Ignoring Customer Impact

Symptom: Message jumps from announcement to "Here's the new product!"

Consequence: Customers feel their concerns aren't acknowledged.

Fix: Explicitly acknowledge impact: "We understand this requires time to migrate and learn new features."


Pitfall 5: Terse or Defensive Tone

Symptom: "Due to low usage, we're shutting down Product X."

Consequence: Sounds like you're blaming customers.

Fix: Be empathetic and forward-looking: "We're consolidating to focus on the future of automation."


References

Related Skills

  • skills/positioning-statement/SKILL.md — Informs the transition solution positioning
  • skills/problem-statement/SKILL.md — Helps frame the customer impact section
  • skills/proto-persona/SKILL.md — Defines affected customers

External Frameworks

  • Crisis communication best practices — Transparency, empathy, action
  • Customer success playbooks — Retention during product transitions

Dean's Work

  • EOL Messaging Template (created for product lifecycle management)

Provenance

  • Adapted from prompts/eol-for-a-product-message.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: eol-message.md Suggested placement: /skills/components/ Dependencies: References skills/positioning-statement/SKILL.md, skills/problem-statement/SKILL.md, skills/proto-persona/SKILL.md

指导产品经理使用Humanizing Work方法论,将大型Epic按9种模式顺序拆分为保持垂直价值流的User Story,避免水平切分,确保可估算与交付。
待办事项过大无法估算或安全交付 需要将大型需求拆解为独立用户故事
skills/epic-breakdown-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill epic-breakdown-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "epic-breakdown-advisor",
    "type": "interactive",
    "intent": "Guide product managers through breaking down epics into user stories using Richard Lawrence's complete Humanizing Work methodology—a systematic, flowchart-driven approach that applies 9 splitting patterns sequentially. Use this to identify which pattern applies, split while preserving user value, and evaluate splits based on what they reveal about low-value work you can eliminate. This ensures vertical slicing (end-to-end value) rather than horizontal slicing (technical layers).",
    "best_for": [
        "Splitting epics into smaller vertical slices",
        "Choosing the right story split pattern for a large backlog item",
        "Turning vague feature blobs into sprint-sized stories"
    ],
    "scenarios": [
        "Break this onboarding epic into smaller user stories",
        "Help me split a large reporting feature before sprint planning",
        "Which story-splitting pattern should I use for this admin workflow epic?"
    ],
    "description": "Break down epics into user stories with Humanizing Work split patterns. Use when a backlog item is too large to estimate, sequence, or deliver safely.",
    "argument-hint": "[epic to split]"
}

Purpose

Guide product managers through breaking down epics into user stories using Richard Lawrence's complete Humanizing Work methodology—a systematic, flowchart-driven approach that applies 9 splitting patterns sequentially. Use this to identify which pattern applies, split while preserving user value, and evaluate splits based on what they reveal about low-value work you can eliminate. This ensures vertical slicing (end-to-end value) rather than horizontal slicing (technical layers).

This is not arbitrary slicing—it's a proven, methodical process that starts with validation, walks through patterns in order, and evaluates results strategically.

Input

Works best with: The epic or large story you need to break down — paste it as written in your backlog. Also useful: Team context (sprint length, estimation ceiling) and what's blocking delivery (too big to estimate, sequence, or release).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking for the epic text, then walks the Humanizing Work pattern flowchart against it.

Example invocation: Break this down: 'As a finance admin, I can export any report to Excel, PDF, or CSV with custom date ranges and saved templates.'

Key Concepts

Core Principles: Vertical Slices Preserve Value

A user story is "a description of a change in system behavior from the perspective of a user." Splitting must maintain vertical slices—work that touches multiple architectural layers and delivers observable user value—not horizontal slices addressing single components (e.g., "front-end story" + "back-end story").

The Three-Step Process

  1. Pre-Split Validation: Check if story satisfies INVEST criteria (except "Small")
  2. Apply Splitting Patterns: Work through 9 patterns sequentially until one fits
  3. Evaluate Splits: Choose the split that reveals low-value work or produces equal-sized stories

The 9 Splitting Patterns (In Order)

  1. Workflow Steps — Thin end-to-end slices, not step-by-step
  2. Operations (CRUD) — Create, Read, Update, Delete as separate stories
  3. Business Rule Variations — Different rules = different stories
  4. Data Variations — Different data types/structures
  5. Data Entry Methods — Simple UI first, fancy UI later
  6. Major Effort — "Implement one + add remaining"
  7. Simple/Complex — Core simplest version first, variations later
  8. Defer Performance — "Make it work" before "make it fast"
  9. Break Out a Spike — Time-box investigation when uncertainty blocks splitting

Meta-Pattern (Applies Across All Patterns)

  1. Identify the core complexity
  2. List all variations
  3. Reduce variations to one complete slice
  4. Make other variations separate stories

Why This Works

  • Prevents arbitrary splitting: Methodical checklist prevents guessing
  • Preserves user value: Every story delivers observable value
  • Reveals waste: Good splits expose low-value work you can deprioritize
  • Repeatable: Apply to any epic consistently

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

Step 0: Provide Epic Context

Agent asks:

Please share your epic:

  • Epic title/ID
  • Description or hypothesis
  • Acceptance criteria (especially multiple "When/Then" pairs)
  • Target persona
  • Rough estimate

You can paste from Jira, Linear, or describe briefly.


Step 1: Pre-Split Validation (INVEST Check)

Before splitting, verify your story satisfies INVEST criteria (except "Small"):

Agent asks questions sequentially:

1. Independent? "Can this story be prioritized and developed without hard technical dependencies on other stories?"

Options:

  • Yes — No blocking dependencies
  • No — Requires other work first (flag this)

2. Negotiable? "Does this story leave room for the team to discover implementation details collaboratively, rather than prescribing exact solutions?"

Options:

  • Yes — It's a conversation starter, not a spec
  • No — It's too prescriptive (may need reframing)

3. Valuable? "Does this story deliver observable value to a user? (If not, combine it with related work rather than splitting.)"

Options:

  • Yes — Users see/experience something different
  • No — It's a technical task (not a user story—don't split, reframe)

⚠️ Critical Check: If story fails "Valuable," STOP. Don't split. Instead, combine with other work to create a meaningful increment.


4. Estimable? "Can your team size this story relatively (even if roughly)?"

Options:

  • Yes — Team can estimate days/points
  • No — Too much uncertainty (may need spike first)

5. Testable? "Does this story have concrete acceptance criteria that QA can verify?"

Options:

  • Yes — Clear pass/fail conditions
  • No — Needs clearer acceptance criteria (refine before splitting)

If story passes all checks → Proceed to Step 2 (Splitting Patterns) If story fails any check → Fix the issue before splitting


Step 2: Apply Splitting Patterns Sequentially

Work through patterns in order. For each pattern, ask "Does this apply?"


Pattern 1: Workflow Steps

Key insight: Split into thin end-to-end slices, not step-by-step. Start with a simple case covering the full workflow, then add intermediate steps as separate stories.

Agent asks: "Does your epic involve a multi-step workflow where you could deliver a simple case first, then add intermediate steps later?"

Example:

  • Original: "Publish content (requires editorial review, legal approval, staging)"
  • ❌ Wrong split (step-by-step): Story 1 = Editorial review, Story 2 = Legal approval, Story 3 = Publish
  • ✅ Right split (thin end-to-end):
    • Story 1: Publish content (simple path: author uploads, content goes live immediately—no reviews)
    • Story 2: Add editorial review step (now content waits for editor approval before going live)
    • Story 3: Add legal approval step (content waits for legal + editorial before going live)

Each story delivers full workflow, just with increasing sophistication.

Options:

  1. Yes, multi-step workflow → "Describe the workflow steps"
  2. No, single step → Continue to Pattern 2

If YES: Agent generates thin end-to-end slice splits.


Pattern 2: Operations (CRUD)

Key insight: The word "manage" signals multiple operations. Split into Create, Read, Update, Delete.

Agent asks: "Does your epic use words like 'manage,' 'handle,' or 'maintain'? If so, it likely bundles multiple operations (CRUD)."

Example:

  • Original: "Manage user accounts"
  • Split:
    • Story 1: Create user account
    • Story 2: View user account details
    • Story 3: Edit user account info
    • Story 4: Delete user account

Options:

  1. Yes, contains multiple operations → "List the operations (Create/Read/Update/Delete/etc.)"
  2. No, single operation → Continue to Pattern 3

If YES: Agent generates one story per operation.


Pattern 3: Business Rule Variations

Key insight: When identical functionality operates under different rules, each rule becomes its own story.

Agent asks: "Does your epic have different business rules for different scenarios (user types, regions, tiers, conditions)?"

Example:

  • Original: "Flight search with flexible dates (date range, specific weekends, date offsets)"
  • Split:
    • Story 1: Search by date range (+/- N days)
    • Story 2: Search by specific weekends only
    • Story 3: Search by date offsets (N days before/after)

Options:

  1. Yes, different rules → "Describe the rule variations"
  2. No, same rules for all → Continue to Pattern 4

If YES: Agent generates one story per rule variation.


Pattern 4: Data Variations

Key insight: Complexity from handling different data types or structures. Add variations just-in-time as needed.

Agent asks: "Does your epic handle different data types, formats, or structures (e.g., file types, geographic levels, user attributes)?"

Example:

  • Original: "Geographic search (counties, cities/towns/neighborhoods, custom provider areas)"
  • Split:
    • Story 1: Search by county
    • Story 2: Add city/town/neighborhood search
    • Story 3: Add custom provider area search

Options:

  1. Yes, different data types → "List the data variations"
  2. No, single data type → Continue to Pattern 5

If YES: Agent generates one story per data variation (deliver simplest first).


Pattern 5: Data Entry Methods

Key insight: UI complexity independent of core functionality. Build simplest interface first, then add sophisticated UI as follow-ups.

Agent asks: "Does your epic include fancy UI elements (date pickers, autocomplete, drag-and-drop) that aren't essential to core functionality?"

Example:

  • Original: "Search with calendar date picker"
  • Split:
    • Story 1: Search by date (basic text input: "YYYY-MM-DD")
    • Story 2: Add visual calendar picker UI

Options:

  1. Yes, fancy UI elements → "Describe the UI enhancements"
  2. No, basic UI only → Continue to Pattern 6

If YES: Agent generates Story 1 = basic input, Story 2+ = UI enhancements.


Pattern 6: Major Effort

Key insight: When initial implementation carries most complexity, with additions being trivial. Frame as "implement one + add remaining."

Agent asks: "Does your epic involve building infrastructure where the first implementation is hard, but adding more is easy?"

Example:

  • Original: "Accept credit card payments (Visa, Mastercard, Amex, Discover)"
  • Split:
    • Story 1: Accept Visa payments (build full payment infrastructure)
    • Story 2: Add Mastercard, Amex, Discover support (trivial additions)

⚠️ Note: First story does the heavy lift (payment gateway, security, compliance). Subsequent stories are small additions.

Options:

  1. Yes, major effort pattern → "What's the first implementation + what are the additions?"
  2. No, no infrastructure work → Continue to Pattern 7

If YES: Agent generates Story 1 = build infrastructure, Story 2 = add remaining variants.


Pattern 7: Simple/Complex

Key insight: Identify story's core by asking "What's the simplest version?" Extract variations into separate stories.

Agent asks: "What's the simplest version of this epic that still delivers value? Can you strip away complexity and add it back later?"

Example:

  • Original: "Flight search (with max stops, nearby airports, flexible dates)"
  • Split:
    • Story 1: Basic flight search (origin, destination, date)
    • Story 2: Add max stops filter
    • Story 3: Add nearby airports option
    • Story 4: Add flexible dates option

Options:

  1. Yes, can identify simplest core → "Describe the simplest version + what variations to defer"
  2. No, it's already simple → Continue to Pattern 8

If YES: Agent generates Story 1 = simplest core, Story 2+ = variations.


Pattern 8: Defer Performance

Key insight: Split "make it work" from "make it fast." Non-functional requirements (performance, security, scalability) can follow functional delivery.

Agent asks: "Can you deliver functional value first, then optimize performance/security/scalability later?"

Example:

  • Original: "Real-time search with <100ms response time"
  • Split:
    • Story 1: Search works (functional, no performance guarantee)
    • Story 2: Optimize search to <100ms (add caching, indexing)

Options:

  1. Yes, can defer optimization → "What's the functional version + what's the optimization?"
  2. No, performance is essential → Continue to Pattern 9

If YES: Agent generates Story 1 = functional, Story 2 = optimize.


Pattern 9: Break Out a Spike

Key insight: Last resort when uncertainty prevents splitting. Time-box investigation to answer specific questions, then split implementation story with better understanding.

Agent says: "None of patterns 1-8 apply, which suggests high uncertainty. Before splitting, run a spike to reduce uncertainty."

A spike is a time-boxed investigation (not a story), answering questions like:

  • Is this technically feasible?
  • Which approach performs best?
  • What does the API actually return?

Agent asks: "What's the biggest unknown preventing you from splitting this epic?"

Options:

  1. Technical feasibility — "Can we build this with our stack?"
  2. Approach uncertainty — "Multiple ways to solve it, unclear which is best"
  3. External dependency — "Don't know what third-party API provides"

Agent recommends: → "Run a 1-2 day spike to answer [question]. After the spike, come back and we'll split the epic with better understanding."

⚠️ Spikes produce learning, not shippable code. After the spike, restart at Pattern 1.


Step 3: Evaluate Split Quality

After splitting, evaluate using these criteria:

Agent asks:

1. Does this split reveal low-value work you can deprioritize or eliminate?

  • Good splits expose the 80/20 principle: most value concentrates in a small portion of functionality
  • Example: After splitting "Flight search" into 4 stories, you realize "flexible dates" is rarely used → deprioritize or kill it

2. Does this split produce more equally-sized stories?

  • Equal-sized stories give Product Owners greater prioritization flexibility
  • Example: Instead of one 10-day epic, five 2-day stories allow reordering mid-sprint

If split doesn't satisfy either criterion, try a different pattern.


Meta-Pattern Application

Across all patterns, follow this sequence:

  1. Identify core complexity — What makes this epic hard?
  2. List variations — What are all the different ways/cases/rules?
  3. Reduce to one complete slice — Pick the simplest variation that still delivers end-to-end value
  4. Make other variations separate stories

Cynefin Domain Considerations

Strategy shifts based on complexity domain:

Agent asks: "How much uncertainty surrounds this epic?"

Options:

  1. Low uncertainty (Obvious/Complicated domain) — "We know what to build; it's just engineering work" → Find all stories, prioritize by value/risk

  2. High uncertainty (Complex domain) — "We're not sure what customers want or what will work" → Identify 1-2 learning stories; avoid exhaustive enumeration (work itself teaches what matters)

  3. Chaos — "Everything is on fire; priorities shift daily" → Defer splitting until stability emerges; focus on stabilization first


Output: Generate Story Breakdown

# Epic Breakdown Plan

**Epic:** [Original epic]
**Pre-Split Validation:** ✅ Passes INVEST (except Small)
**Splitting Pattern Applied:** [Pattern name]
**Rationale:** [Why this pattern fits]

---

## Story Breakdown

### Story 1: [Title] (Simplest Complete Slice)

**Summary:** [User-value-focused title]

**Use Case:**
- **As a** [persona]
- **I want to** [action]
- **so that** [outcome]

**Acceptance Criteria:**
- **Given:** [Preconditions]
- **When:** [Action]
- **Then:** [Outcome]

**Why This First:** [Delivers core value; simpler variations follow]
**Estimated Effort:** [Days/points]

---

### Story 2: [Title] (First Variation)

[Repeat...]

---

### Story 3: [Title] (Second Variation)

[Repeat...]

---

## Split Evaluation

✅ **Does this split reveal low-value work?**
- [Analysis: Which stories could be deprioritized/eliminated?]

✅ **Does this split produce equal-sized stories?**
- [Analysis: Are stories roughly equal in effort?]

---

## INVEST Validation (Each Story)

✅ **Independent:** Stories can be developed in any order
✅ **Negotiable:** Implementation details can be discovered collaboratively
✅ **Valuable:** Each story delivers observable user value
✅ **Estimable:** Team can size each story
✅ **Small:** Each story fits in 1-5 days
✅ **Testable:** Clear acceptance criteria for each

---

## Next Steps

1. **Review with team:** Do PM, design, engineering agree?
2. **Check for further splitting:** Are any stories still >5 days? If yes, **restart at Pattern 1** for that story.
3. **Prioritize:** Which story delivers most value first?
4. **Consider eliminating:** Did split reveal low-value stories? Kill or defer them.

---

**If stories are still too large, re-apply patterns starting at Pattern 1.**

Examples

Example 1: Pattern 1 Applied (Workflow Steps - Thin End-to-End)

Epic: "Publish blog post (requires editorial review, legal approval, staging)"

Pre-Split Validation: ✅ Passes INVEST

Pattern 1: "Does this have workflow steps?" → YES ✅

❌ Wrong Split (Step-by-Step):

  1. Editorial review story
  2. Legal approval story
  3. Publish story → Problem: Story 1 doesn't deliver value (users see nothing)

✅ Right Split (Thin End-to-End):

  1. Publish post (simple path) — Author uploads, post goes live immediately (no reviews)
  2. Add editorial review — Post now waits for editor approval before going live
  3. Add legal approval — Post waits for legal + editorial before going live

Why this works: Each story delivers full workflow, just with increasing sophistication.


Example 2: Pattern 2 Applied (CRUD Operations)

Epic: "Manage user profiles"

Pattern 2: "Does this say 'manage'?" → YES ✅ (signals CRUD)

Split:

  1. Create user profile
  2. View user profile details
  3. Edit user profile info
  4. Delete user profile

Split Evaluation:

  • Reveals low-value work: After analysis, "Delete profile" is rarely used → deprioritize
  • Equal-sized stories: Each 1-2 days

Example 3: Pattern 7 Applied (Simple/Complex)

Epic: "Flight search with max stops, nearby airports, flexible dates"

Pattern 7: "What's the simplest version?" → Basic search ✅

Split:

  1. Basic flight search (origin, destination, date) — Core value
  2. Add max stops filter — Enhancement
  3. Add nearby airports option — Enhancement
  4. Add flexible dates option — Enhancement

Split Evaluation:

  • Reveals low-value work: User research shows "flexible dates" rarely used → kill or defer
  • Equal-sized stories: Story 1 = 3 days, others = 1 day each

Example 4: Iterative Splitting (Multiple Patterns)

Epic: "Checkout flow with discounts (member, VIP, first-time) and payment (Visa, Mastercard, Amex)"

First Pass - Pattern 1 (Workflow): YES ✅

  • Story 1: Add items to cart
  • Story 2: Apply discount
  • Story 3: Complete payment

Check Story 2 ("Apply discount"): Still 4 days → Too large, re-split

Second Pass on Story 2 - Pattern 3 (Business Rules): YES ✅

  • Story 2a: Apply member discount (10%)
  • Story 2b: Apply VIP discount (20%)
  • Story 2c: Apply first-time discount (5%)

Check Story 3 ("Complete payment"): Still 5 days → Too large, re-split

Third Pass on Story 3 - Pattern 6 (Major Effort): YES ✅

  • Story 3a: Accept Visa payments (build payment infrastructure)
  • Story 3b: Add Mastercard, Amex support

Final Breakdown: 6 stories, all 1-2 days each


Common Pitfalls

Pitfall 1: Skipping Pre-Split Validation

Symptom: Jump straight to splitting without checking INVEST

Consequence: Split a story that shouldn't be split (e.g., not Valuable = technical task)

Fix: Always run Step 1 (INVEST check) before Step 2 (splitting patterns)


Pitfall 2: Step-by-Step Workflow Splitting (Pattern 1 Done Wrong)

Symptom: Story 1 = "Editorial review," Story 2 = "Legal approval"

Consequence: Stories don't deliver end-to-end value

Fix: Each story should cover full workflow (thin end-to-end slice), just with increasing sophistication


Pitfall 3: Horizontal Slicing (Technical Layers)

Symptom: "Story 1: Build API. Story 2: Build UI."

Consequence: Neither story delivers user value

Fix: Vertical slicing—each story includes front-end + back-end to deliver observable user behavior


Pitfall 4: Forcing a Pattern That Doesn't Fit

Symptom: "We'll split by workflow even though there's no sequence"

Consequence: Arbitrary, meaningless split

Fix: If pattern doesn't apply, say NO and continue to next pattern


Pitfall 5: Not Re-Splitting Large Stories

Symptom: Split epic into 3 stories, but each is still 5+ days

Consequence: Stories too large for sprint

Fix: Restart at Pattern 1 for each large story until all are 1-5 days


Pitfall 6: Ignoring Split Evaluation (Step 3)

Symptom: Split but don't evaluate if it reveals low-value work

Consequence: Miss opportunity to eliminate waste

Fix: After splitting, ask: "Does this reveal work we can kill or defer?"


Practice & Skill Development

Humanizing Work recommendation: Teams reach fluency in 2.5-3 hours across multiple practice sessions.

Practice approach:

  1. Analyze recently completed features (hindsight makes patterns obvious)
  2. Walk completed work through the flowchart — Which pattern would have applied?
  3. Find multiple split approaches for each feature
  4. Build shared vocabulary of domain-specific pattern examples

Don't skip practice work. Skill develops through analyzing past deliverables, not just refining future work.


References

Related Skills

  • user-story-splitting.md — The 9 patterns in detail
  • user-story.md — Format for writing stories
  • epic-hypothesis.md — Original epic format

External Frameworks

  • Richard Lawrence & Peter Green, The Humanizing Work Guide to Splitting User Stories — Complete methodology
  • Bill Wake, INVEST in Good Stories (2003) — Quality criteria

Sources


Skill type: Interactive Suggested filename: epic-breakdown-advisor.md Suggested placement: /skills/interactive/ Dependencies: Uses user-story-splitting.md, user-story.md, epic-hypothesis.md

将产品史诗转化为可测试假设,明确目标用户、预期成果及验证方法。适用于路线图或交付规划前,通过轻量级实验管理不确定性,避免盲目开发,确保以结果为导向并支持快速证伪。
定义重大产品倡议前 进行路线图、探索或交付规划前 早期功能探索阶段 验证新产品市场契合度 需要优先排序积压需求时
skills/epic-hypothesis/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill epic-hypothesis -g -y
SKILL.md
Frontmatter
{
    "name": "epic-hypothesis",
    "type": "component",
    "intent": "Frame epics as testable hypotheses using an if\/then structure that articulates the action or solution, the target beneficiary, the expected outcome, and how you'll validate success. Use this to manage uncertainty in product development by making assumptions explicit, defining lightweight experiments (\"tiny acts of discovery\"), and establishing measurable success criteria before committing to full build-out.",
    "description": "Frame an epic as a testable hypothesis with target user, expected outcome, and validation method. Use when defining a major initiative before roadmap, discovery, or delivery planning.",
    "argument-hint": "[initiative or epic idea]"
}

Purpose

Frame epics as testable hypotheses using an if/then structure that articulates the action or solution, the target beneficiary, the expected outcome, and how you'll validate success. Use this to manage uncertainty in product development by making assumptions explicit, defining lightweight experiments ("tiny acts of discovery"), and establishing measurable success criteria before committing to full build-out.

This is not a requirements spec—it's a hypothesis you're testing, not a feature you're committed to shipping.

Input

Works best with: The initiative or epic idea, in whatever form it currently exists — a sentence is enough. Also useful: The target user, the outcome you expect, and how you might measure it (the skill helps you sharpen all three).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks what the initiative is and who it's for, then builds the if/then hypothesis with you.

Example invocation: Frame as an epic hypothesis: adding usage-based alerts so account admins catch overages before invoice shock.

Key Concepts

The Epic Hypothesis Framework

Inspired by Tim Herbig's Lean UX hypothesis format, the structure is:

If/Then Hypothesis:

  • If we [action or solution on behalf of target persona]
  • for [target persona]
  • Then we will [attain or achieve a desirable outcome or job-to-be-done]

Tiny Acts of Discovery Experiments:

  • We will test our assumption by:
    • [Experiment 1]
    • [Experiment 2]
    • [Add more as necessary]

Validation Measures:

  • We know our hypothesis is valid if within [timeframe]
  • we observe:
    • [Quantitative measurable outcome]
    • [Qualitative measurable outcome]
    • [Add more as necessary]

Why This Structure Works

  • Hypothesis-driven: Forces you to state what you believe (and could be wrong about)
  • Outcome-focused: "Then we will" emphasizes user benefit, not feature output
  • Experiment-first: Encourages lightweight validation before full build
  • Falsifiable: Clear success criteria make it possible to kill bad ideas early
  • Risk management: Treats epics as bets, not commitments

Anti-Patterns (What This Is NOT)

  • Not a feature spec: "Build a dashboard with 5 charts" is a feature, not a hypothesis
  • Not a guaranteed commitment: Hypotheses can (and should) be invalidated
  • Not output-focused: "Ship feature X by Q2" misses the point—did it achieve the outcome?
  • Not experiment-free: If you skip experiments and go straight to build, you're not testing a hypothesis

When to Use This

  • Early-stage feature exploration (before committing to full roadmap)
  • Validating product-market fit for new capabilities
  • Prioritizing backlog (epics with validated hypotheses get higher priority)
  • Managing stakeholder expectations (frame work as experiments, not promises)

When NOT to Use This

  • For well-validated features (if you've already proven demand, skip straight to user stories)
  • For trivial features (don't over-engineer small tweaks)
  • When experiments aren't feasible (rare, but sometimes you must commit before testing)

Application

Use template.md for the full fill-in structure.

Step 1: Gather Context

Before drafting an epic hypothesis, ensure you have:

  • Problem understanding: What user problem does this address? (reference skills/problem-statement/SKILL.md)
  • Target persona: Who benefits? (reference skills/proto-persona/SKILL.md)
  • Jobs-to-be-Done: What outcome are they trying to achieve? (reference skills/jobs-to-be-done/SKILL.md)
  • Current alternatives: What do users do today? (competitors, workarounds, doing nothing)

If missing context: Run discovery interviews or problem validation work first.


Step 2: Draft the If/Then Hypothesis

Fill in the template:

### If/Then Hypothesis

**If we** [action or solution on behalf of the target persona]
**for** [target persona]
**Then we will** [attain or achieve a desirable outcome or job-to-be-done for the persona]

Quality checks:

  • "If we" is specific: Not "improve the product" but "add one-click Slack notifications when tasks are assigned"
  • "For" is a clear persona: Not "users" but "remote project managers juggling 3+ distributed teams" (reference skills/proto-persona/SKILL.md)
  • "Then we will" is an outcome: Not "users will have notifications" but "users will respond to task assignments 50% faster"

Examples:

  • ✅ "If we add one-click Google Calendar integration for trial users, then we will increase activation rates by 20% within 30 days"
  • ✅ "If we provide bulk delete functionality for power users managing 1000+ items, then we will reduce time spent on cleanup tasks by 70%"
  • ❌ "If we build a dashboard, then users will use it" (vague, not measurable)

Step 3: Design Tiny Acts of Discovery Experiments

Before building the full epic, define lightweight experiments to test the hypothesis:

### Tiny Acts of Discovery Experiments

**We will test our assumption by:**
- [Experiment 1: low-cost, fast test]
- [Experiment 2: another low-cost, fast test]
- [Add more as necessary]

Experiment types:

  • Prototype + user testing: Fake the feature with a clickable prototype, test with 5-10 users
  • Concierge test: Manually perform the feature for a few users, see if they value it
  • Landing page test: Describe the feature, measure sign-ups or interest
  • Wizard of Oz test: Present the feature as if it's automated, but do it manually behind the scenes
  • A/B test (if feasible): Test a lightweight version vs. control

Quality checks:

  • Fast: Experiments should take days/weeks, not months
  • Cheap: Avoid full engineering builds—use prototypes, manual processes, or existing tools
  • Falsifiable: Design experiments that could prove you wrong

Examples:

  • "Create a Figma prototype of the bulk delete flow and test with 5 power users"
  • "Manually send Slack notifications to 10 trial users and track response time"
  • "Add a 'Request this feature' button to the UI and measure click-through rate"

Step 4: Define Validation Measures

Specify what success looks like and the timeframe for evaluation:

### Validation Measures

**We know our hypothesis is valid if within** [timeframe in days or weeks]
**we observe:**
- [Desirable quantitative, measurable outcome]
- [Desirable qualitative, measurable outcome]
- [Add more as necessary]

Quality checks:

  • Timeframe is realistic: Not "within 6 months" (too slow) or "within 3 days" (too fast)
  • Quantitative measures are specific: Not "more users" but "20% increase in activation rate"
  • Qualitative measures are observable: Not "users like it" but "8 out of 10 users say they'd pay for this feature"

Examples:

  • ✅ "Within 4 weeks, we observe:"
    • "Activation rate increases from 40% to 50% (quantitative)"
    • "75% of surveyed trial users say the integration saved them time (qualitative)"
  • ❌ "Within 1 year, we observe:"
    • "Revenue goes up" (too vague, too long)

Step 5: Run Experiments and Evaluate

  • Execute experiments: Build prototypes, run tests, gather data
  • Measure results: Did you hit the validation measures?
  • Decision point:
    • Hypothesis validated: Proceed to building user stories and adding to roadmap
    • Hypothesis invalidated: Kill the epic or pivot to a different hypothesis
    • ⚠️ Inconclusive: Run additional experiments or tighten validation measures

Step 6: Convert to User Stories (If Validated)

Once the hypothesis is validated, break the epic into user stories:

### Epic: [Epic Name]

**Stories:**
1. [User Story 1 - reference `skills/user-story/SKILL.md`]
2. [User Story 2]
3. [User Story 3]

Examples

See examples/sample.md for full epic hypothesis examples.

Mini example excerpt:

**If we** provide one-click Google Calendar integration
**for** trial users managing multiple meetings
**Then we will** increase activation rate from 40% to 50%

Common Pitfalls

Pitfall 1: Hypothesis is a Feature, Not an Outcome

Symptom: "If we build a dashboard, then we will have a dashboard"

Consequence: You're describing output, not outcome. This doesn't test anything.

Fix: Focus on the user outcome: "If we build a dashboard showing real-time task status, then PMs will spend 50% less time asking for status updates."


Pitfall 2: Skipping Experiments

Symptom: "We'll test our assumption by building the full feature"

Consequence: You've committed to building before validating. Not a hypothesis—it's a feature commitment.

Fix: Design lightweight experiments (prototypes, concierge tests, landing pages) that take days/weeks, not months.


Pitfall 3: Vague Validation Measures

Symptom: "We know it's valid if users are happy"

Consequence: Success criteria are subjective and unmeasurable.

Fix: Define specific, falsifiable metrics: "80% of surveyed users rate the feature 4+ out of 5" or "Response time drops by 50%."


Pitfall 4: Unrealistic Timeframes

Symptom: "We know it's valid if within 6 months revenue increases"

Consequence: Too slow to inform decisions. By then, you've already built it.

Fix: Aim for 2-4 week validation cycles. If you can't measure in that timeframe, choose a leading indicator (e.g., activation rate, not annual revenue).


Pitfall 5: Treating Epics as Commitments

Symptom: "We already told the CEO we're shipping this, so we have to validate it"

Consequence: Experiments are theater—you're going to build it regardless of results.

Fix: Frame epics as hypotheses before making commitments. If stakeholders need certainty, explain the risk of building unvalidated features.


References

Related Skills

  • skills/problem-statement/SKILL.md — Hypothesis should address a validated problem
  • skills/proto-persona/SKILL.md — Defines the "for [persona]" section
  • skills/jobs-to-be-done/SKILL.md — Informs the "then we will" outcome
  • skills/user-story/SKILL.md — Validated epics decompose into user stories
  • skills/user-story-splitting/SKILL.md — How to break validated epics into stories

External Frameworks

  • Tim Herbig, Lean UX Hypothesis Statement — Origin of if/then hypothesis format
  • Jeff Gothelf & Josh Seiden, Lean UX (2013) — Hypothesis-driven product development
  • Alberto Savoia, Pretotype It (2011) — Lightweight experiments to validate ideas
  • Eric Ries, The Lean Startup (2011) — Build-Measure-Learn cycle

Dean's Work

  • Backlog Epic Hypothesis Prompt (inspired by Tim Herbig's framework)

Provenance

  • Adapted from prompts/backlog-epic-hypothesis.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: epic-hypothesis.md Suggested placement: /skills/components/ Dependencies: References skills/problem-statement/SKILL.md, skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md Used by: skills/user-story/SKILL.md, skills/user-story-splitting/SKILL.md

为VP或CPO提供30-60-90天入职诊断指南,强调以顾问心态观察而非急于执行。通过分阶段诊断、验证和基于证据行动,帮助高管在理解组织现状后做出可持续决策,避免盲目变革导致的失败。
担任新产品副总裁或首席产品官的入职规划 需要制定高管过渡期的诊断策略
skills/executive-onboarding-playbook/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill executive-onboarding-playbook -g -y
SKILL.md
Frontmatter
{
    "name": "executive-onboarding-playbook",
    "type": "workflow",
    "theme": "career-leadership",
    "intent": "Structure the first 90 days of a VP or CPO transition as a diagnostic process, not an execution sprint. The single most common failure in senior product leadership transitions is acting before understanding — changing structures, replacing people, or announcing strategy before building the evidence base that makes those decisions defensible.",
    "best_for": [
        "Starting a new VP or CPO role in the first 90 days",
        "Evaluating a CPO offer — what to ask before you accept",
        "Diagnosing an organization you've just inherited"
    ],
    "scenarios": [
        "I just accepted a VP of Product role starting next month — help me plan my first 90 days",
        "I'm evaluating a CPO offer and want to know what questions to ask the hiring CEO",
        "I'm two months into a new role and want to validate what I've learned before I start acting"
    ],
    "description": "Plan a VP or CPO 30-60-90 day diagnostic onboarding path. Use when entering a new executive product role and avoiding premature change.",
    "argument-hint": "[role and company context]",
    "estimated_time": "20-30 min"
}

Purpose

Structure the first 90 days of a VP or CPO transition as a diagnostic process, not an execution sprint. The single most common failure in senior product leadership transitions is acting before understanding — changing structures, replacing people, or announcing strategy before building the evidence base that makes those decisions defensible.

This playbook runs in three phases: Diagnose (Month 1), Validate (Month 2), Act with Evidence (Month 3). Each phase builds on the last. Skipping phases doesn't accelerate results — it guarantees expensive reversals.

This is not a 100-day plan for impressing your new boss. It's a diagnostic protocol for making durable decisions.

Input

Works best with: The role you're stepping into (VP or CPO) and basic company context — size, stage, how the product org is set up. Also useful: How far you are from Day 1 (offer stage, pre-start, week 3), known landmines, and what the CEO says success looks like.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The playbook opens by asking your start date and company context, then anchors you in the right phase.

Example invocation: I start as VP Product at a 300-person Series C in 3 weeks — first product exec hire, founder currently runs product. Build my 30-60-90.

Key Concepts

The Consultant Mindset

Enter every new VP/CPO role as if you're an external consultant hired to assess the organization — before you're the person responsible for changing it.

What this means in practice:

  • Observe before diagnosing. Don't form opinions in the first week based on first impressions.
  • Ask questions before making declarations. "Help me understand how this works" is more powerful than "here's what we're going to do differently."
  • Understand how the steering connects to the rudder. In any organization, there are systems and relationships that look one way on paper and work completely differently in practice. Map that reality before you touch anything.
  • Don't throw the big red switch. If you walked into a power plant you'd never operated before and saw a large red switch, you probably wouldn't throw it. The same logic applies to org structures, processes, reporting lines, and team compositions you've inherited. Understand what they control first.

Negotiate this upfront: tell your boss and peers that Month 1 is explicitly a learning phase. Set the expectation that your first major recommendations will come in Month 2. Executives who've been through transitions will respect this; executives who want action in Week 1 are a signal worth noting.


Unwritten Strategy

At VP and CPO level, significant strategy is never fully written down. It lives in:

  • The CEO's head, shaped by conversations you weren't in
  • Board meeting dynamics and investor preferences
  • Last night's executive dinner
  • Off-the-record conversations between founders
  • Tribal knowledge that long-tenured leaders treat as obvious

This isn't dysfunction — it's how every organization works at the executive level. Treating written strategy as complete strategy will get you into trouble fast.

Your job in the first 90 days is to surface the unwritten layer. How:

  • Ask indirect questions: "What's the history here?" / "How did we end up with this approach?" / "What did we try before that didn't work?"
  • Let information find you. People who want to shape the new leader's perspective will seek you out. Take those meetings. Take notes.
  • Reality-check with your boss: "Here's what I'm hearing from the organization. This is different from what you told me. Help me understand." This is not confrontational — it's how you triangulate toward the truth.

The Body of Evidence

Every significant decision you make in Month 3 and beyond should rest on a body of evidence collected in Months 1 and 2. This means:

  • Detailed notes from every diagnostic conversation
  • Patterns noted across multiple independent sources (not just one vocal person)
  • Reality-checks completed with your manager and key peers
  • A clear picture of what's working, what's broken, and why

The body of evidence is what separates confident decisions from guesses. It's also what makes hard decisions defensible — to your team, to your peers, and to the board.


People Assessment: Two Categories

Two distinct people situations require different responses:

Diamonds in the rough — Capable, undervalued people who haven't had a champion. They exist in almost every organization. You'll find them in Months 1-2 by listening for: "She's really talented but nobody gives her the hard problems" or noticing who gives you the most useful, unvarnished information in your diagnostic interviews. These people become critical early allies.

Strong people in wrong roles — Not weak performers; people whose strengths are mismatched to their current scope. This is more common in organizations that grew fast, went through acquisitions, or promoted based on tenure. A former sales rep who became a PM because they knew the product. A brilliant individual contributor managing a team that needs a coach. These situations require honest, compassionate conversations — coach up if they're coachable, find them another role, or part ways. All three outcomes are better than leaving the mismatch in place.


Phase 0: Before Day 1

If you're evaluating whether to take the role, use this phase to interview the organization before it interviews you.

Five questions to probe with the hiring CEO:

  1. "What are you expecting from the product organization in the first 90 days? The first year?" — Surfaces unrealistic transformation timelines early. Red flag: "I expect the roadmap to be fully overhauled by Q2."

  2. "Who are the all-stars on your product team, and why?" — Reveals the CEO's perceptions and biases. They're often wrong, but knowing their mental model matters.

  3. "Who has gaps, and why?" — What does the CEO believe the org's weakness is? Is it accurate?

  4. "What constraints are we working with that I should understand upfront?" — Financial, organizational, market. Understand your actual degrees of freedom before you accept.

  5. "What does success look like for this role at one year?" — Force specificity. Vague answers ("transformed the product culture") are red flags. Specific answers ("85% on-time delivery, two new enterprise accounts, one rebuilt team") are workable.

Red flags that change the calculus:

  • "You can't change the existing product roadmap" — loss of basic authority before you start
  • "We need you to transform the organization in six months" — sets you up to fail
  • Misalignment between CEO's talent assessment and what you learn elsewhere in conversations

Application

Phase 1: Diagnose (Month 1)

Objective: Build the body of evidence. Understand reality, not the official version.

Step 1: Interview everyone Schedule 30-minute conversations with your direct reports, key cross-functional peers (CRO, CFO, CMO, Engineering leadership), and a sample of the PMs in your organization. The question set is simple:

  • "What's working well that I should understand and protect?"
  • "What's not working that you've been hoping someone would fix?"
  • "What do you think I need to know that I probably won't hear in official briefings?"
  • "Who are the people in this organization I should make sure to talk to?"

Step 2: Let people find you Don't do all the seeking. Some of the most valuable information comes from people who proactively schedule time with the new leader. They have an agenda — surface it, evaluate it, and note the signal (both in what they say and in that they came to you at all).

Step 3: Take detailed notes Every conversation. Note not just content but context: who said it, what their incentive might be, whether you heard the same thing from multiple independent sources. Patterns that appear across multiple conversations are much more reliable than strong opinions from single sources.

Step 4: Resist action When you see something obviously broken in Month 1, your instinct will be to fix it. Resist. You don't yet have the context to know why it's broken, whether previous attempts to fix it failed, or what it's connected to. Note it in your evidence log instead.

Deliverable: A detailed notebook of organizational reality, not yet interpreted.


Phase 2: Validate (Month 2)

Objective: Surface patterns, challenge your emerging conclusions, identify the people situations.

Step 1: Reality-check with your boss Take your emerging picture of the organization back to your manager:

  • "I'm hearing [X] from multiple people. This is different from what I understood coming in. Help me understand the history."
  • "I'm seeing [Y] pattern across the team. Is that consistent with what you've observed?"

This is not confrontational. It's how you separate signal from noise and build a shared baseline of organizational reality.

Step 2: Map the unwritten strategy By now you've had enough conversations to start seeing the gap between stated priorities and actual organizational behavior. Ask directly: "What does the organization actually optimize for when things get hard?" The answer is usually different from the mission statement.

Step 3: Complete your people assessment By end of Month 2, you should have a preliminary read on:

  • Who your diamonds in the rough are (and how to give them more scope)
  • Who is strong but in the wrong role (and what the right conversation looks like)
  • Who is genuinely not coachable to the level the org needs (and what timeline is appropriate)

Step 4: Identify your 3-5 highest-leverage changes Not a full transformation plan — three to five specific changes that would most improve organizational effectiveness. These become your Month 3 agenda.

Deliverable: An interpreted organizational assessment with people map and initial strategic priorities.


Phase 3: Act with Evidence (Month 3)

Objective: Begin making decisions grounded in the body of evidence. Introduce structure and direction, not transformation.

Step 1: Share your organizational assessment Don't keep it private. Bring your key findings to your boss and your direct reports: "Here's what I've learned about how this organization works, where it's strong, and where it needs to develop. Here's my initial plan for the next quarter." This builds trust through transparency and surfaces disagreements before you act on them.

Step 2: Run your first Cascading Context Map Use the organizational and strategic clarity you've built to create direction for your team — even if company strategy above you is still ambiguous. (See skills/altitude-horizon-framework/SKILL.md for the full technique.) Your team has been waiting for context. Give them your best current translation and commit to refining it.

Step 3: Start the people conversations Now that you have evidence, have the hard conversations:

  • Diamonds in the rough: give them a stretch assignment or expanded scope
  • People in wrong roles: a direct, honest conversation about the mismatch and the options
  • Exits: begin with honesty and care, not avoidance

Step 4: Build your executive alliance deliberately By Month 3 you know who the key players are and what they need from product. Start the weekly alignment practice: regular touchpoints with CRO, CFO, and CMO to ensure they understand product's priorities and the trade-offs being made. Don't wait for them to be surprised. (See skills/vp-cpo-readiness-advisor/SKILL.md for the Alliance Building branch.)

Deliverable: A shared organizational assessment, an initial strategic direction, and three to five active changes underway with clear rationale.


Examples

See examples/sample.md for a full 30-60-90 diagnostic walkthrough with concrete artifacts and decisions by month.

Good: Consultant Mindset Preventing a Costly Mistake

Situation: New CPO joins and immediately notices the team's longest-tenured PM is resistant, slow to deliver, and visibly unpopular with engineering.

Impulsive response: Put her on a performance plan in Month 1.

Consultant response: Keeps notes, asks questions. Discovers in Month 2 that she's the only person on the team who understands the legacy platform's architecture — and that a previous CPO already tried to push her out, creating the defensive behavior. She's strong but in the wrong role (PM scope requires stakeholder management she struggles with; technical architecture is where she adds irreplaceable value).

Outcome: She's moved into a technical product owner role by Month 3. Engineering's delivery velocity improves. The CPO avoids destroying an irreplaceable relationship.


Bad: Acting Before Understanding

Situation: New VP of Product hears in Week 2 that three PMs each have completely different formats for their roadmap documentation. She standardizes them in Week 3.

What she didn't know: Each format exists because of specific requirements from different internal stakeholder groups. The "inconsistency" was a feature, not a bug.

Outcome: Three sets of stakeholders lose the views they relied on. The VP spends Month 2 rebuilding goodwill she spent three weeks burning.

The diagnostic question she should have asked first: "Why does each team use a different format? What would break if they were unified?"


Good: Surfacing Unwritten Strategy

Situation: VP joins a company whose stated priority is "enterprise expansion." After 30 diagnostic conversations, he realizes the CEO has a specific enterprise customer in mind — a reference customer that would unlock a Series B — that has never been mentioned in any written strategy document.

How it surfaces: He asks an indirect question in his Month 2 reality-check: "When you imagine what success looks like at the end of this year, what does the portfolio look like?" The CEO mentions the target customer by name.

Outcome: The VP realigns two product teams' priorities around the capabilities that matter to that specific customer. Strategy becomes executable. Without surfacing the unwritten layer, he would have pursued a generic enterprise strategy that didn't move the actual needle.


Common Pitfalls

Pitfall 1: Performing Action Instead of Building Evidence

Symptom: Making structural announcements or process changes in Month 1 to signal decisive leadership

Consequence: You build on incomplete understanding. Reversals in Month 3 damage credibility more than patience in Month 1 would have.

Fix: Reframe patience as methodology, not passivity. "I'm in diagnostic mode for the first 30 days" is a confident statement when said clearly to your boss and team.


Pitfall 2: Staying in Consultant Mode Too Long

Symptom: Still gathering information in Month 3; no visible actions or decisions

Consequence: Organizational confidence erodes. People start to wonder if the new leader has opinions. Your boss starts to wonder if you can make decisions.

Fix: Month 3 is the action phase. You won't have complete information — no one ever does. Act on your best current evidence and commit to learning from what follows.


Pitfall 3: Trusting the Loudest Voice

Symptom: Forming early opinions based on the most vocal, most accessible, or most persuasive person you met in Month 1

Consequence: You adopt one person's organizational narrative as ground truth. Decisions built on single-source information collapse when the rest of the organization provides context.

Fix: Pattern-match across multiple independent conversations. Only act on themes you've heard from three or more unrelated sources.


Pitfall 4: Skipping the CEO Interview (Before Accepting)

Symptom: Taking the CPO role without probing constraints, expectations, and talent assessment upfront

Consequence: You walk into a situation where the roadmap is locked, the timeline is impossible, or the CEO's mental model of the team is so wrong that your first six months are spent managing their misperceptions instead of leading.

Fix: The five questions in Phase 0 are not optional. Walk away from roles where the answers reveal fundamental misalignment. No role is worth a death march.


Pitfall 5: Ignoring Executive Dysfunction

Symptom: Assuming that executive staff meetings will be mature, collaborative, and politics-free

Consequence: You're blindsided by alliances, personal agendas, and interpersonal dynamics that operate beneath the surface of every executive team.

Fix: Expect dysfunction. Patrick Lencioni's Five Dysfunctions of a Team applies to leadership teams as much as any other. Integrity gets tested more at higher levels, not less. Map the alliances in Month 1 as carefully as you map the product portfolio.


References

Related Skills

  • skills/vp-cpo-readiness-advisor/SKILL.md — Interactive advisor for all four VP/CPO transition situations; the Alliance Building branch covers ongoing executive relationship management
  • skills/altitude-horizon-framework/SKILL.md — The Cascading Context Map technique referenced in Phase 3
  • skills/director-readiness-advisor/SKILL.md — The Director-level transition equivalent; relevant if you're coaching a new Director through their own onboarding

Source Material

External Frameworks

  • Michael Watkins, The First 90 Days — Foundational reference for structured leadership transitions
  • Patrick Lencioni, Five Dysfunctions of a Team — Diagnostic for executive team dysfunction
  • Marty Cagan, Empowered — Organizational dynamics and product leadership at scale
为产品经理提供基于财务视角的功能投资决策支持,通过分析收入影响、成本结构(开发/COGS/OpEx)、ROI及战略价值,输出数据驱动的构建建议。
评估功能是否值得投资 进行基于财务影响的功能优先级排序 计算新功能或改进的ROI 决定构建、购买还是合作
skills/feature-investment-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill feature-investment-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "feature-investment-advisor",
    "type": "interactive",
    "intent": "Guide product managers through evaluating whether to build a feature based on financial impact analysis. Use this to make data-driven prioritization decisions by assessing revenue connection (direct or indirect), cost structure (dev + COGS + OpEx), ROI calculation, and strategic value—then deliver actionable build\/don't build recommendations with supporting math.",
    "best_for": [
        "Assessing whether a feature should be built now",
        "Comparing ROI and strategic value of feature ideas",
        "Pressure-testing roadmap requests with financial logic"
    ],
    "scenarios": [
        "Should we build SSO for mid-market customers this quarter?",
        "Evaluate whether an AI assistant feature is worth the investment",
        "Help me decide if this roadmap request has enough ROI to build"
    ],
    "description": "Evaluate feature investments using revenue impact, cost structure, ROI, and strategy. Use when deciding whether a feature deserves investment.",
    "argument-hint": "[feature to evaluate]"
}

Purpose

Guide product managers through evaluating whether to build a feature based on financial impact analysis. Use this to make data-driven prioritization decisions by assessing revenue connection (direct or indirect), cost structure (dev + COGS + OpEx), ROI calculation, and strategic value—then deliver actionable build/don't build recommendations with supporting math.

This is not a generic prioritization framework—it's a financial lens for feature decisions that complements other prioritization methods (RICE, value vs. effort, user research). Use when financial impact is a key decision factor.

Input

Works best with: The feature you're deciding on, in a sentence or two. Also useful: Revenue connection (direct or indirect), rough cost inputs (dev time, COGS, ongoing OpEx), and the strategic argument being made for it.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking what the feature is and how it's supposed to make or save money.

Example invocation: Should we build SSO/SAML? Enterprise deals keep stalling on it; est. 2 engineer-months plus ongoing support burden.

Key Concepts

The Feature Investment Framework

A systematic approach to evaluate features financially:

  1. Revenue Connection — How does this feature impact revenue?

    • Direct monetization (new tier, add-on, usage charges)
    • Indirect monetization (retention, conversion, expansion enablement)
  2. Cost Structure — What does it cost to build and run?

    • Development cost (one-time investment)
    • COGS impact (ongoing infrastructure, processing)
    • OpEx impact (ongoing support, maintenance)
  3. ROI Calculation — Is the return worth the investment?

    • Direct monetization: Revenue impact / Development cost
    • Retention features: LTV impact across customer base / Development cost
    • Factor in gross margin, not just revenue
  4. Strategic Value — Non-financial value that might override pure ROI

    • Competitive moat (prevents churn to competitor)
    • Platform enabler (unlocks future features)
    • Market positioning (needed for enterprise deals)
    • Risk reduction (compliance, security)

Anti-Patterns (What This Is NOT)

  • Not feature scoring alone: Combines financial analysis with strategic judgment
  • Not revenue-only thinking: Considers margins, costs, and ROI, not just top-line revenue
  • Not ignoring retention: Indirect revenue impact (churn reduction) is equally valid
  • Not building without validation: Assumes you've done discovery; this is the financial lens

When to Use This Framework

Use this when:

  • Prioritizing between features with quantifiable revenue/retention impact
  • Evaluating expensive features (>1 engineer-month of work)
  • Making build/buy/partner decisions
  • Defending feature prioritization to stakeholders or leadership
  • Choosing between direct monetization (add-on) vs. indirect (retention)

Don't use this when:

  • Feature is table stakes (must-have for competitive parity)
  • Impact is purely qualitative (brand, UX delight without measurable retention effect)
  • You haven't validated the problem (do discovery first)
  • Feature is < 1 week of work (just build it)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 4 adaptive questions, offering 3-5 enumerated options at decision points.


Step 0: Gather Context

Agent asks:

"Let's evaluate the financial impact of this feature investment. Please provide:

Feature description:

  • What's the feature? (1-2 sentences)
  • Target customer segment (SMB, mid-market, enterprise, all)

Current business context:

  • Current MRR/ARR (or customer count if pre-revenue)
  • Current ARPU/ARPA
  • Current monthly churn rate
  • Gross margin %

Constraints:

  • Development cost estimate (team size × time)
  • Any ongoing COGS or OpEx implications?

You can provide estimates if you don't have exact numbers."


Step 1: Identify Revenue Connection

Agent asks:

"How does this feature impact revenue? Choose the option that best describes the revenue connection:

  1. Direct monetization (new revenue stream) — We'll charge for this (new pricing tier, paid add-on, usage-based fee)
  2. Retention improvement (reduce churn) — Addresses key churn reason; keeps customers from leaving
  3. Conversion improvement (trial-to-paid) — Helps convert free/trial users to paid customers
  4. Expansion enabler (upsell/cross-sell) — Creates upsell path or drives usage-based expansion
  5. No direct revenue impact — Table stakes, platform improvement, or strategic value only

Choose a number, or describe a custom revenue connection."

Based on selection, agent adapts:

If 1 (Direct monetization):

  • "What pricing are you considering?"
  • "What % of customers do you expect to adopt this?" (conservative, base, optimistic)
  • Calculate: Potential Monthly Revenue = Customer Base × Adoption Rate × Price

If 2 (Retention improvement):

  • "What % of churn does this feature address?" (e.g., "30% of churned customers cited this gap")
  • "What churn reduction do you expect?" (e.g., "5% → 4% monthly churn")
  • Calculate: LTV Impact = Increase in Customer Lifetime × Customer Base × ARPU × Margin

If 3 (Conversion improvement):

  • "Current trial-to-paid conversion rate?"
  • "Expected conversion lift?" (e.g., "20% → 25% conversion")
  • Calculate: Additional MRR = Trial Users × Conversion Lift × ARPU

If 4 (Expansion enabler):

  • "What expansion opportunity does this create?" (upsell tier, usage growth, add-on)
  • "What % of customers will expand?"
  • Calculate: Expansion MRR = Customer Base × Expansion Rate × ARPU Increase

If 5 (No direct revenue impact):

  • Skip to strategic value assessment

Step 2: Assess Cost Structure

Agent asks:

"What's the cost structure for this feature?

Development cost (one-time):

  • Team size: ___ engineers
  • Time estimate: ___ weeks/months
  • Estimated dev cost: $___

Ongoing costs (if any):

  • COGS impact: $___ /month (hosting, infrastructure, processing)
  • OpEx impact: $___ /month (support, maintenance)

If no ongoing costs, enter $0."

Agent calculates:

  • One-time investment: Development cost
  • Ongoing monthly cost: COGS + OpEx
  • Contribution margin impact: (Revenue - COGS) / Revenue

Agent flags:

  • If COGS is >20% of projected revenue: "⚠️ This feature significantly dilutes margins"
  • If ongoing costs are high relative to revenue: "⚠️ Consider if this is sustainable"

Step 3: Evaluate Constraints and Timing

Agent asks:

"What constraints or timing considerations apply?

  1. Time-sensitive competitive threat — Competitor launched this; we're losing deals
  2. Limited budget/team capacity — We can only build one major feature this quarter
  3. Dependencies on other work — Requires platform improvements or other features first
  4. No major constraints — We have capacity and flexibility

Choose a number, or describe your constraints."

Based on selection:

If 1 (Competitive threat):

  • Strategic value increases (churn prevention)
  • Urgency factor in recommendation

If 2 (Limited capacity):

  • Compare ROI against other features in backlog
  • Recommend stack ranking

If 3 (Dependencies):

  • Flag dependency risk
  • Suggest sequencing

If 4 (No constraints):

  • Proceed to recommendations

Step 4: Deliver Recommendations

Agent synthesizes:

  • Revenue impact (from Step 1)
  • Cost structure (from Step 2)
  • Constraints (from Step 3)
  • ROI calculation
  • Strategic value assessment

Agent offers 3-4 recommendations:


Recommendation Pattern 1: Strong Financial Case

When:

  • ROI >3:1 (direct monetization) or LTV impact >10:1 (retention/expansion)
  • Positive contribution margin
  • No major red flags

Recommendation:

"Build now — Strong financial case

Revenue Impact:

  • [Direct/Indirect revenue impact calculation]
  • Conservative estimate: $___/month
  • Optimistic estimate: $___/month

Cost:

  • Development: $___
  • Ongoing COGS/OpEx: $___/month
  • Net margin impact: ___%

ROI:

  • Year 1 ROI: ___:1
  • Payback period: ___ months

Why this makes sense: [Specific reasoning based on numbers]

Next steps:

  1. Validate pricing/adoption assumptions with customer research
  2. Build MVP to test core value prop
  3. Monitor [specific metric] to measure impact"

Recommendation Pattern 2: Weak Financial Case, Build Anyway (Strategic)

When:

  • ROI <2:1 or marginal financial impact
  • But high strategic value (competitive, platform, compliance)

Recommendation:

"Build for strategic reasons (financial case is marginal)

Financial Reality:

  • Revenue impact: $___/month (modest)
  • Development cost: $___
  • ROI: ___:1 (below 3:1 threshold)

Strategic Value:

  • [Competitive moat / Platform enabler / Market requirement]
  • Prevents churn to competitor X
  • Required for enterprise segment (30% of pipeline)

Recommendation: Build, but monitor closely:

  1. Track adoption vs. projections
  2. Measure churn impact (target: reduce churn by ___%)
  3. Re-evaluate after 6 months if adoption is low

Risk: Opportunity cost—other features may have better ROI"


Recommendation Pattern 3: Don't Build (Poor ROI)

When:

  • ROI <1:1 (direct monetization) or negative LTV impact
  • Margin-diluting
  • No compelling strategic value

Recommendation:

"Don't build — Financial case doesn't support investment

Why:

  • Revenue impact: $___/month
  • Development cost: $___
  • ROI: ___:1 (below breakeven)
  • Margin impact: Dilutes gross margin from ___% to ___%

Alternative approaches:

  1. Reduce scope — Can we build a simpler version at 50% cost?
  2. Change monetization — Can we charge more or differently?
  3. Deprioritize — Focus on higher-ROI features like [alternative]

What would need to change:

  • If adoption rate increases from ___% to ___%, ROI becomes viable
  • If we can reduce dev cost to $___, payback becomes acceptable"

Recommendation Pattern 4: Build Later / Need More Data

When:

  • Assumptions are highly uncertain
  • Revenue impact depends on unvalidated hypotheses
  • Medium strategic value

Recommendation:

"Build later — Validate assumptions first

Current uncertainty:

  • Adoption rate assumption: ___% (needs validation)
  • Churn impact: ___% reduction (hypothesis, not proven)
  • Pricing unknown

What to validate:

  1. Run feature demand survey with 50+ customers
  2. Prototype and test willingness-to-pay
  3. Interview churned customers to confirm this addresses churn reason

Decision criteria:

  • If % of customers say they'd pay $, build
  • If churn interviews confirm this is top 3 reason, build
  • Otherwise, deprioritize

Timeline:

  • Spend 2-4 weeks validating
  • Re-evaluate with real data"

Step 5: Allow Follow-Up Questions

Agent offers:

"Do you want to:

  1. See the detailed math breakdown
  2. Compare this to another feature
  3. Adjust assumptions (pricing, adoption, cost)
  4. Export recommendation summary

Or, ask any follow-up questions."

Agent can:

  • Show detailed calculations
  • Sensitivity analysis (what if adoption is 2x? 0.5x?)
  • Compare multiple features side-by-side
  • Export summary for stakeholders

Examples

See examples/ folder for sample conversation flows. Mini examples below:

Example 1: Direct Monetization (Time Tracking Add-On)

User: "We're considering building time tracking as a paid add-on."

Agent: [Gathers context]

User provides:

  • Current: 1,000 customers, $500 ARPU, 80% gross margin
  • Feature: Time tracking add-on, $10/user/month
  • Dev cost: $100K (2 engineers × 3 months)
  • Adoption estimate: 20% of customers

Agent calculates:

  • Customers with 10 users/account avg = 1,000 accounts × 10 users = 10,000 users
  • Adoption: 20% of users = 2,000 users
  • Revenue: 2,000 × $10 = $20K/month = $240K/year
  • Margin: $240K × 80% = $192K gross profit/year
  • ROI: $192K / $100K = 1.92:1 in year 1
  • Payback: $100K / $20K = 5 months

Agent recommends:

"Build now — Positive ROI with fast payback

Revenue Impact: $240K/year (conservative 20% adoption) ROI: 1.92:1 in year 1, 3.8:1 in year 2 Payback: 5 months

Why this works:

  • Fast payback (5 months) means low risk
  • 80% gross margin on add-on revenue
  • 20% adoption is conservative (test willingness-to-pay)

Next steps:

  1. Survey customers: who would pay $10/user for time tracking?
  2. Build MVP with core time tracking only
  3. Beta with 50 customers before broad launch
  4. Track adoption rate vs. 20% target"

Example 2: Retention Feature (Data Export)

User: "We're losing customers because they can't export their data easily. Should we build a comprehensive export feature?"

Agent: [Gathers context]

User provides:

  • Current: $2M MRR, 500 customers, $4K ARPA, 5% monthly churn
  • Feature: Full data export (CSV, API, scheduled exports)
  • Dev cost: $150K (3 engineers × 2 months)
  • Churn context: 30% of churned customers cited data export as a reason

Agent calculates:

  • Current annual churn: ~46% (5% monthly compounded)
  • Customers churned annually: 500 × 46% = 230 customers
  • Customers churned due to export issue: 230 × 30% = 69 customers
  • MRR lost: 69 × $4K = $276K MRR lost/year = $3.3M ARR

If feature reduces this by 50%:

  • Churn prevented: 35 customers/year
  • MRR saved: $140K/year
  • LTV impact (assuming 24-month lifetime): $140K × 24 = $3.36M

Agent calculates ROI:

  • Investment: $150K
  • LTV saved: $3.36M (conservative 50% reduction)
  • ROI: $3.36M / $150K = 22.4:1 🚀

Agent recommends:

"Build immediately — Exceptional ROI on retention

Impact:

  • Prevents ~35 customer churns/year
  • Saves $140K MRR annually
  • LTV impact: $3.36M over customer lifetime
  • ROI: 22:1 (exceptional)

Why this is a no-brainer:

  • 30% of churn cites this gap (validated problem)
  • Even if you only prevent 25% (not 50%), ROI is still 11:1
  • Retention improvements compound (reduces future churn too)

Next steps:

  1. Interview churned customers to validate export was primary reason
  2. Build core export (CSV, API) first
  3. Measure churn rate change after launch (target: 5% → 4.5%)
  4. Add scheduled exports if adoption is high"

Example 3: Poor ROI Feature (Dark Mode)

User: "Users are requesting dark mode. Should we prioritize it?"

Agent: [Gathers context]

User provides:

  • Current: $500K MRR, 2,000 customers, $250 ARPA, 3% monthly churn, 75% gross margin
  • Feature: Full dark mode across product
  • Dev cost: $80K (2 designers + 2 engineers × 1 month)
  • Revenue connection: Indirect—may improve retention slightly

Agent asks: "What evidence do you have that dark mode will reduce churn?"

User: "Feature requests from 50 users. No data on churn impact."

Agent calculates:

  • 50 feature requests out of 2,000 customers = 2.5% of base
  • No validated churn impact
  • Dev cost: $80K
  • Optimistic scenario: Prevents 5 churns/year (2.5% of base)
  • MRR saved: 5 × $250 = $1,250/month = $15K/year
  • LTV impact (24-month lifetime): $15K × 24 = $360K

ROI: $360K / $80K = 4.5:1 (looks okay, but based on weak assumptions)

Agent recommends:

"Build later — Weak evidence for ROI

Current case:

  • Revenue impact: $15K/year (optimistic)
  • Development cost: $80K
  • ROI: 4.5:1 (assumes dark mode prevents churn)

Problem:

  • Only 50 users requested this (2.5% of base)
  • No evidence dark mode reduces churn
  • Churn interviews don't mention this as a top reason

Alternative approach:

  1. Survey churned customers — Is dark mode in top 5 churn reasons?
  2. Test demand — Ask trial users: "Would dark mode affect your decision to convert?"
  3. Reduce scope — Build basic dark mode (20% cost) as experiment

Better features to consider:

  • If retention is priority: Interview churned customers, find top 3 churn drivers
  • If revenue is priority: Focus on expansion features (upsell, add-ons)

Decision criteria to build:

  • If churn interviews show dark mode is top 3 reason → build
  • If conversion research shows 10%+ impact → build
  • Otherwise → deprioritize"

Common Pitfalls

Pitfall 1: Confusing Revenue with Profit

Symptom: "This feature will generate $1M in revenue!" (ignoring $800K COGS)

Consequence: $1M revenue at 20% margin is worth $200K profit, not $1M. Feature looks great until you factor in costs.

Fix: Always calculate contribution margin. Use Revenue × Margin %, not just revenue.


Pitfall 2: Ignoring Payback Period

Symptom: "ROI is 5:1, let's build!" (but payback is 36 months and customers churn at 24 months)

Consequence: You never recover the investment because customers leave before payback.

Fix: Check payback period. Must be shorter than average customer lifetime.


Pitfall 3: Overestimating Adoption

Symptom: "100% of customers will use this paid add-on!"

Consequence: Real adoption is 10-20%. Revenue projections are 5-10x too high.

Fix: Use conservative adoption estimates (10-20% for add-ons). Validate with willingness-to-pay research.


Pitfall 4: Building Without Validation

Symptom: "We think this will reduce churn" (no customer interviews)

Consequence: You build a feature that doesn't address real churn reasons. Churn stays flat.

Fix: Interview churned customers first. Validate that this feature addresses top 3 churn reasons.


Pitfall 5: Ignoring Opportunity Cost

Symptom: "This feature has 2:1 ROI, let's build!" (other features have 10:1 ROI)

Consequence: You build a mediocre feature while better options sit in the backlog.

Fix: Compare ROI across features. Build highest-ROI features first (unless strategic value overrides).


Pitfall 6: Strategic Value as Excuse

Symptom: "ROI is terrible but it's strategic!" (no clear strategy)

Consequence: "Strategic" becomes a catch-all for building low-value features.

Fix: Define what "strategic" means (competitive moat, platform enabler, compliance). If it doesn't fit, it's not strategic.


Pitfall 7: Margin Dilution Blindness

Symptom: "This feature adds $500K revenue!" (but COGS is $400K)

Consequence: Your gross margin drops from 80% to 60%. Feature destroys unit economics.

Fix: Calculate contribution margin. If margin is <50%, reconsider or charge a premium.


Pitfall 8: Celebrating Vanity Metrics

Symptom: "This feature will increase engagement!" (but not revenue or retention)

Consequence: You build features that feel good but don't impact business outcomes.

Fix: Tie features to revenue or retention. Engagement is a leading indicator, not an outcome.


Pitfall 9: Forgetting Time Value of Money

Symptom: "This feature pays back in 5 years"

Consequence: $1 in 5 years is worth ~$0.65 today (at 9% discount rate). ROI is overstated.

Fix: For long payback periods (>24 months), use NPV (net present value) to discount future cash flows.


Pitfall 10: Building Features for Loud Minorities

Symptom: "50 customers requested this!" (out of 10,000)

Consequence: You optimize for 0.5% of your base while ignoring the other 99.5%.

Fix: Weight feature requests by revenue impact or customer segment. 10 enterprise customers > 100 SMB customers if enterprise is your strategy.


References

Related Skills

  • saas-revenue-growth-metrics — Revenue, ARPU, churn, NRR metrics used in impact calculations
  • saas-economics-efficiency-metrics — ROI, payback, contribution margin calculations
  • finance-metrics-quickref — Quick lookup for formulas and benchmarks
  • acquisition-channel-advisor — Similar ROI framework for channel decisions
  • finance-based-pricing-advisor — Pricing impact analysis for monetization features

External Frameworks

  • RICE Prioritization — Combines Reach, Impact, Confidence, Effort (this skill adds financial lens)
  • Value vs. Effort Matrix — This skill quantifies "value" financially
  • Jobs-to-be-Done — Understand customer problems before evaluating financial impact
  • Opportunity Solution Tree (Teresa Torres) — Map opportunities before calculating ROI

Provenance

  • Adapted from research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md (Decision Framework #1)
  • Quiz scenarios from research/finance/Finance for Product Managers.md
评估定价变更的财务影响,涵盖ARPU、转化率、流失风险、NRR及CAC回收周期。用于在决定推出价格调整前进行数据驱动的可行性分析与风险评估。
需要评估涨价或新层级方案的财务影响 决策是否推出新的定价策略或折扣方案 分析定价变更对转化率和客户流失的影响
skills/finance-based-pricing-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill finance-based-pricing-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "finance-based-pricing-advisor",
    "type": "interactive",
    "intent": "Evaluate the **financial impact** of pricing changes (price increases, new tiers, add-ons, discounts) using ARPU\/ARPA analysis, conversion impact, churn risk, NRR effects, and CAC payback implications. Use this to make data-driven go\/no-go decisions on proposed pricing changes with supporting math and risk assessment.",
    "best_for": [
        "Evaluating price increases, discounts, or new packaging",
        "Estimating churn and conversion risk before a pricing change",
        "Making a go\/no-go call on monetization changes"
    ],
    "scenarios": [
        "Should we raise prices 15% for new customers next quarter?",
        "Evaluate a new premium tier for our SaaS product",
        "Help me assess whether an annual discount will improve revenue"
    ],
    "description": "Evaluate pricing changes using ARPU, conversion, churn risk, NRR, and payback. Use when deciding whether a pricing move should ship.",
    "argument-hint": "[pricing change to evaluate]"
}

Purpose

Evaluate the financial impact of pricing changes (price increases, new tiers, add-ons, discounts) using ARPU/ARPA analysis, conversion impact, churn risk, NRR effects, and CAC payback implications. Use this to make data-driven go/no-go decisions on proposed pricing changes with supporting math and risk assessment.

What this is: Financial impact evaluation for pricing decisions you're already considering.

What this is NOT: Comprehensive pricing strategy design, value-based pricing frameworks, willingness-to-pay research, competitive positioning, psychological pricing, packaging architecture, or monetization model selection. For those topics, see the future pricing-strategy-suite skills.

This skill assumes you have a specific pricing change in mind and need to evaluate its financial viability.

Input

Works best with: The pricing change on the table — increase, new tier, add-on, or discount — and current pricing. Also useful: Current ARPU/ARPA, conversion and churn baselines, NRR, and who's pushing for the change.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking what change is proposed and what today's pricing looks like.

Example invocation: Evaluate raising our Pro plan from $49 to $59/seat; ARPU $52, monthly logo churn 1.8%, NRR 108%.

Key Concepts

The Pricing Impact Framework

A systematic approach to evaluate pricing changes financially:

  1. Revenue Impact — How does this change ARPU/ARPA?

    • Direct revenue lift from price increase
    • Revenue loss from reduced conversion or increased churn
    • Net revenue impact
  2. Conversion Impact — How does this affect trial-to-paid or sales conversion?

    • Higher prices may reduce conversion rate
    • Better packaging may improve conversion
    • Test assumptions
  3. Churn Risk — Will existing customers leave due to price change?

    • Grandfathering strategy (protect existing customers)
    • Churn risk by segment (SMB vs. enterprise)
    • Churn elasticity (how sensitive are customers to price?)
  4. Expansion Impact — Does this create or block expansion opportunities?

    • New premium tier = upsell path
    • Usage-based pricing = expansion as customers grow
    • Add-ons = cross-sell opportunities
  5. CAC Payback Impact — Does pricing change affect unit economics?

    • Higher ARPU = faster payback
    • Lower conversion = higher effective CAC
    • Net effect on LTV:CAC ratio

Pricing Change Types

Direct monetization changes:

  • Price increase (raise prices for all customers or new customers only)
  • New premium tier (create upsell path)
  • Paid add-on (monetize previously free feature)
  • Usage-based pricing (charge for consumption)

Discount strategies:

  • Annual prepay discount (improve cash flow)
  • Volume discounts (larger deals)
  • Promotional pricing (temporary price reduction)

Packaging changes:

  • Feature bundling (combine features into tiers)
  • Unbundling (separate features into add-ons)
  • Pricing metric change (seats → usage, or vice versa)

Anti-Patterns (What This Is NOT)

  • Not value-based pricing: This evaluates a proposed change, not "what should we charge?"
  • Not WTP research: This analyzes impact, not "what will customers pay?"
  • Not competitive positioning: This is financial analysis, not market positioning
  • Not packaging architecture: This evaluates one change, not redesigning all tiers

When to Use This Framework

Use this when:

  • You have a specific pricing change to evaluate (e.g., "Should we raise prices 20%?")
  • You need to quantify revenue, churn, and conversion trade-offs
  • You're deciding between pricing change options (test A vs. B)
  • You need to present pricing change impact to leadership or board

Don't use this when:

  • You're designing pricing strategy from scratch (use value-based pricing frameworks)
  • You haven't validated willingness-to-pay (do customer research first)
  • You don't have baseline metrics (ARPU, churn, conversion rates)
  • Change is too small to matter (<5% price change, <10% of customers affected)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 4 adaptive questions, offering 3-5 enumerated options at decision points.


Step 0: Gather Context

Agent asks:

"Let's evaluate the financial impact of your pricing change. Please provide:

Current pricing:

  • Current ARPU or ARPA
  • Current pricing tiers (if applicable)
  • Current monthly churn rate
  • Current trial-to-paid conversion rate (if relevant)

Proposed pricing change:

  • What change are you considering? (price increase, new tier, add-on, etc.)
  • New pricing (if known)
  • Affected customer segment (all, new only, specific tier)

Business context:

  • Total customers (or MRR/ARR)
  • CAC (to assess payback impact)
  • NRR (to assess expansion context)

You can provide estimates if you don't have exact numbers."


Step 1: Identify Pricing Change Type

Agent asks:

"What type of pricing change are you considering?

  1. Price increase — Raise prices for new customers, existing customers, or both
  2. New premium tier — Add higher-priced tier with additional features
  3. Paid add-on — Monetize a new or existing feature separately
  4. Usage-based pricing — Charge for consumption (seats, API calls, storage, etc.)
  5. Discount strategy — Annual prepay discount, volume pricing, or promotional pricing
  6. Packaging change — Rebundle features, change pricing metric, or tier restructure

Choose a number, or describe your specific pricing change."

Based on selection, agent adapts questions:


If Option 1 (Price Increase):

Agent asks:

"Price increase details:

  • Current price: $___
  • New price: $___
  • Increase: ___%

Who is affected?

  1. New customers only (grandfather existing)
  2. All customers (existing + new)
  3. Specific segment (e.g., SMB only, new plan only)

When would this take effect?

  • Immediately
  • Next billing cycle
  • Gradual rollout (test first)"

If Option 2 (New Premium Tier):

Agent asks:

"Premium tier details:

  • Current top tier price: $___
  • New premium tier price: $___
  • Key features in premium tier: [list]

Expected adoption:

  • What % of current customers might upgrade? ___%
  • What % of new customers might choose premium? ___%

Cannibalization risk:

  • Will premium tier cannibalize current top tier?"

If Option 3 (Paid Add-On):

Agent asks:

"Add-on details:

  • Add-on name: ___
  • Price: $___ /month or /user
  • Currently free or new feature?

Expected adoption:

  • What % of customers would pay for this? ___%
  • Is this feature currently used (if free)?
  • Will making it paid hurt retention?"

If Option 4 (Usage-Based Pricing):

Agent asks:

"Usage pricing details:

  • Usage metric: (seats, API calls, storage, transactions, etc.)
  • Pricing: $___ per [unit]
  • Free tier or minimum? (e.g., first 1,000 API calls free)

Expected impact:

  • Average customer usage: ___ units/month
  • Expected ARPU change: $current → $new

Expansion potential:

  • As customers grow usage, will ARPU increase?"

If Option 5 (Discount Strategy):

Agent asks:

"Discount details:

  • Discount type: (annual prepay, volume, promotional)
  • Discount amount: ___% off
  • Duration: (ongoing, limited time)

Trade-off:

  • Lower price vs. improved cash flow (annual prepay)
  • Lower price vs. larger deal size (volume)
  • Lower price vs. urgency (promotional)"

If Option 6 (Packaging Change):

Agent asks:

"Packaging change details:

  • What are you changing? (bundling, unbundling, pricing metric)
  • Current packaging: [describe]
  • New packaging: [describe]

Expected impact:

  • ARPU change: $current → $new
  • Conversion change: ___% → ___%
  • Churn risk: (low, medium, high)"

Step 2: Assess Expected Impact

Agent asks:

"Now let's quantify the impact. Based on your pricing change, estimate:

Revenue impact:

  • Current ARPU: $___
  • Expected new ARPU: $___
  • ARPU lift: ___%

Conversion impact:

  • Current conversion rate: ___%
  • Expected new conversion rate: ___%
  • Conversion change: [increase / decrease / no change]

Churn risk:

  • Current monthly churn: ___%
  • Expected churn after change: ___%
  • Churn risk: [low / medium / high]

Expansion impact:

  • Does this create expansion opportunities? (new tier to upgrade to, usage growth)
  • Expected NRR change: ___% → ___%

You can provide estimates. We'll model scenarios (conservative, base, optimistic)."


Step 3: Evaluate Current State

Agent asks:

"To assess whether this pricing change makes sense, I need your current baseline:

Current metrics:

  • MRR or ARR: $___
  • Number of customers: ___
  • ARPU/ARPA: $___
  • Monthly churn rate: ___%
  • NRR: ___%
  • CAC: $___
  • LTV: $___

Growth context:

  • Current growth rate: ___% MoM or YoY
  • Target growth rate: ___%

Competitive context:

  • Are you priced below, at, or above market?
  • Competitive pressure: (low, medium, high)"

Step 4: Deliver Recommendations

Agent synthesizes:

  • Revenue impact (ARPU lift × customer base)
  • Conversion impact (new customers affected)
  • Churn impact (existing customers affected)
  • Net revenue impact
  • CAC payback impact
  • Risk assessment

Agent offers 3-4 recommendations:


Recommendation Pattern 1: Implement Broadly

When:

  • Net revenue impact clearly positive (>10% ARPU lift, <5% churn risk)
  • Minimal conversion impact
  • Strong value justification

Recommendation:

"Implement this pricing change — Strong financial case

Revenue Impact:

  • Current MRR: $___
  • ARPU lift: ___% ($current → $new)
  • Expected MRR increase: +$/month (+%)

Churn Risk: Low

  • Expected churn increase: ___% → % (+% points)
  • Churn-driven MRR loss: -$___/month
  • Net MRR impact: +$___/month

Conversion Impact:

  • Current conversion: ___%
  • Expected conversion: % (% change)
  • Impact on new customer acquisition: [minimal / manageable]

CAC Payback Impact:

  • Current payback: ___ months
  • New payback: ___ months (faster due to higher ARPU)

Why this works: [Specific reasoning based on numbers]

How to implement:

  1. Grandfather existing customers (if raising prices)
    • Protect current base from churn
    • New pricing for new customers only
  2. Communicate value
    • Emphasize features, outcomes, ROI
    • Justify price with value delivered
  3. Monitor metrics (first 30-60 days)
    • Conversion rate (should stay within ___%)
    • Churn rate (should stay <___%)
    • Customer feedback

Expected timeline:

  • Month 1: +$___ MRR from new customers
  • Month 3: +$___ MRR (cumulative)
  • Month 6: +$___ MRR
  • Year 1: +$___ ARR

Success criteria:

  • Conversion rate stays >___%
  • Churn rate stays <___%
  • NRR improves to >___%"

Recommendation Pattern 2: Test First (A/B Test)

When:

  • Uncertain impact (wide range between conservative and optimistic)
  • Moderate churn or conversion risk
  • Large customer base (can test with subset)

Recommendation:

"Test with a segment before broad rollout — Impact is uncertain

Why test:

  • ARPU lift estimate: ___% (wide confidence interval)
  • Churn risk: Medium (___% → ___%)
  • Conversion impact: Uncertain (___% → ___% estimated)

Test design:

Cohort A (Control):

  • Current pricing: $___
  • Size: ___% of new customers (or ___ customers)

Cohort B (Test):

  • New pricing: $___
  • Size: ___% of new customers (or ___ customers)

Duration: 60-90 days (need statistical significance)

Metrics to track:

  • Conversion rate (A vs. B)
  • ARPU (A vs. B)
  • 30-day retention (A vs. B)
  • 90-day churn (A vs. B)
  • NRR (A vs. B)

Decision criteria:

Roll out broadly if:

  • Conversion rate (B) >___% of control (A)
  • Churn rate (B) <___% higher than control
  • Net revenue (B) >___% higher than control

Don't roll out if:

  • Conversion drops >___%
  • Churn increases >___%
  • Net revenue impact negative

Expected timeline:

  • Week 1-2: Launch test
  • Week 8-12: Enough data for statistical significance
  • Month 3: Decision to roll out or kill

Risk: Medium. Test mitigates risk before broad rollout."


Recommendation Pattern 3: Modify Approach

When:

  • Original proposal has significant risk
  • Better alternative exists
  • Need to adjust pricing change to improve outcomes

Recommendation:

"Modify your approach — Original proposal has risks

Original Proposal:

  • [Price increase / New tier / Add-on / etc.]
  • Expected ARPU lift: ___%
  • Churn risk: High (___% → ___%)
  • Net revenue impact: Uncertain or negative

Problem: [Specific issue: e.g., "20% price increase will likely cause 10% churn, wiping out revenue gains"]

Alternative Approach:

Option 1: Smaller price increase

  • Instead of ___% increase, try ___%
  • Lower churn risk (___% vs. ___%)
  • Still positive net revenue: +$___/month

Option 2: Grandfather existing, raise for new only

  • Protect current base (zero churn risk)
  • Higher prices for new customers only
  • Gradual ARPU improvement over time

Option 3: Value-based pricing (charge more for high-value segments)

  • Keep SMB pricing flat
  • Raise enterprise pricing ___%
  • Lower churn risk (enterprise is stickier)

Recommended: [Specific option with reasoning]

Why this is better:

  • Lower churn risk
  • Comparable revenue upside
  • Easier to communicate

How to implement: [Specific steps for alternative approach]"


Recommendation Pattern 4: Don't Change Pricing

When:

  • Net revenue impact negative or marginal
  • High churn risk without offsetting gains
  • Competitive or strategic reasons to hold pricing

Recommendation:

"Don't change pricing — Risks outweigh benefits

Why:

  • Expected revenue lift: +$/month (%)
  • Expected churn impact: -$/month (%)
  • Net revenue impact: -$___/month 🚨 or marginal

Problem: [Specific issue: e.g., "Churn-driven revenue loss exceeds price increase gains"]

What would need to change:

For price increase to work:

  • Churn rate must stay below ___% (currently ___%)
  • OR conversion rate must stay above ___% (currently ___%)
  • OR you need to reduce CAC to offset lower conversion

Alternative strategies:

Instead of raising prices:

  1. Improve retention — Reduce churn from ___% to ___% (same revenue impact as price increase, lower risk)
  2. Expand within base — Increase NRR from ___% to ___% via upsells
  3. Reduce CAC — More efficient acquisition (better than pricing)

When to revisit pricing:

  • After improving retention (churn <___%)
  • After validating willingness-to-pay (WTP research)
  • After competitive landscape changes

Decision: Hold pricing for now, focus on [retention / expansion / acquisition efficiency]."


Step 5: Sensitivity Analysis (Optional)

Agent offers:

"Want to see what-if scenarios?

  1. Optimistic case — Higher ARPU lift, lower churn
  2. Pessimistic case — Lower ARPU lift, higher churn
  3. Breakeven analysis — What churn rate makes this neutral?

Or ask any follow-up questions."

Agent can provide:

  • Scenario modeling (optimistic/pessimistic/breakeven)
  • Sensitivity tables (if churn is X%, revenue impact is Y)
  • Comparison to alternative pricing strategies

Examples

See examples/ folder for sample conversation flows. Mini examples below:

Example 1: Price Increase (Good Case)

Scenario: 20% price increase for new customers only

Current state:

  • ARPU: $100/month
  • Customers: 1,000
  • MRR: $100K
  • Churn: 3%/month
  • New customers/month: 50

Proposed change:

  • New customer pricing: $120/month (+20%)
  • Existing customers: Grandfathered at $100

Impact:

  • New customer ARPU: $120 (+20%)
  • Churn risk: Low (existing protected)
  • Conversion impact: Minimal (<5% drop estimated)

Recommendation: Implement. Net revenue impact +$12K/year with low risk.


Example 2: Price Increase (Risky)

Scenario: 30% price increase for all customers

Current state:

  • ARPU: $50/month
  • Customers: 5,000
  • MRR: $250K
  • Churn: 5%/month (already high)

Proposed change:

  • All customers: $65/month (+30%)

Impact:

  • ARPU lift: +30% = +$75K MRR
  • Churn risk: High (5% → 8% estimated)
  • Churn-driven loss: 3% × 5,000 × $65 = -$9.75K MRR/month

Net impact: +$75K - $9.75K = +$65K MRR (but accelerating churn problem)

Recommendation: Don't change. Fix retention first (reduce 5% churn), then raise prices.


Example 3: New Premium Tier

Scenario: Add $500/month premium tier

Current state:

  • Top tier: $200/month (500 customers)
  • ARPA: $200

Proposed change:

  • New tier: $500/month with advanced features
  • Expected adoption: 10% of current top tier (50 customers)

Impact:

  • Upsell revenue: 50 × ($500 - $200) = +$15K MRR
  • Cannibalization risk: Low (features justify premium)
  • NRR impact: Increases from 105% to 110%

Recommendation: Implement. Creates expansion path, minimal cannibalization risk.


Common Pitfalls

Pitfall 1: Ignoring Churn Impact

Symptom: "We'll raise prices 30% and make $X more!" (no churn modeling)

Consequence: Churn wipes out revenue gains. Net impact negative.

Fix: Model churn scenarios (conservative, base, optimistic). Factor churn-driven revenue loss into net impact.


Pitfall 2: Not Grandfathering Existing Customers

Symptom: "We're raising prices for everyone effective immediately"

Consequence: Massive churn spike from existing customers who feel betrayed.

Fix: Grandfather existing customers. Raise prices for new customers only.


Pitfall 3: Testing Without Statistical Power

Symptom: "We tested on 10 customers and it worked!"

Consequence: 10 customers isn't statistically significant. Results are noise.

Fix: Test with large enough sample (100+ customers per cohort) for 60-90 days.


Pitfall 4: Pricing Changes Without Value Justification

Symptom: "We're raising prices because we need more revenue"

Consequence: Customers see price increase without corresponding value increase. Churn.

Fix: Tie price increases to value improvements (new features, better support, outcomes delivered).


Pitfall 5: Ignoring CAC Payback Impact

Symptom: "Higher ARPU is always better!"

Consequence: If conversion drops 30%, effective CAC increases dramatically. Payback period explodes.

Fix: Calculate CAC payback impact. Higher ARPU with lower conversion might make payback worse, not better.


Pitfall 6: Annual Discounts That Hurt Margin

Symptom: "30% discount for annual prepay!" (improves cash but destroys LTV)

Consequence: Customers lock in low prices for a year. Revenue per customer decreases.

Fix: Limit annual discounts to 10-15%. Balance cash flow improvement with LTV protection.


Pitfall 7: Copycat Pricing (Competitor-Based)

Symptom: "Competitor raised prices, so should we"

Consequence: Your customers, value prop, and cost structure are different. What works for them may not work for you.

Fix: Use competitors as data points, not decisions. Make pricing decisions based on your unit economics.


Pitfall 8: Premature Optimization

Symptom: "Let's A/B test 47 different price points!"

Consequence: Analysis paralysis. Spending months on 5% pricing optimizations while missing 50% growth opportunities elsewhere.

Fix: Big pricing changes (tiers, packaging, add-ons) matter more than micro-optimizations. Start there.


Pitfall 9: Forgetting Expansion Revenue

Symptom: "We're maximizing ARPU at acquisition"

Consequence: High upfront pricing prevents landing customers. Miss expansion opportunities.

Fix: Consider "land and expand" strategy. Lower entry price, higher expansion revenue via upsells.


Pitfall 10: No Pricing Change Communication Plan

Symptom: "We're raising prices next month" (no customer communication)

Consequence: Surprised customers churn. Poor reviews. Reputation damage.

Fix: Communicate pricing changes 30-60 days in advance. Emphasize value, not just price.


References

Related Skills

  • saas-revenue-growth-metrics — ARPU, ARPA, churn, NRR metrics used in pricing analysis
  • saas-economics-efficiency-metrics — CAC payback impact of pricing changes
  • finance-metrics-quickref — Quick lookup for pricing-related formulas
  • feature-investment-advisor — Evaluates whether to build features that enable pricing changes
  • business-health-diagnostic — Broader business context for pricing decisions

External Frameworks (Comprehensive Pricing Strategy)

These are OUTSIDE the scope of this skill but relevant for broader pricing work:

  • Value-Based Pricing — Price based on value delivered, not cost
  • Van Westendorp Price Sensitivity — WTP research methodology
  • Conjoint Analysis — Feature-to-price trade-off research
  • Good-Better-Best Packaging — Tier architecture design
  • Price Anchoring & Decoy Pricing — Psychological pricing tactics
  • Patrick Campbell (ProfitWell): Pricing research and benchmarks

Future Skills (Comprehensive Pricing)

For topics NOT covered here, see future pricing-strategy-suite:

  • value-based-pricing-framework — How to price based on value
  • willingness-to-pay-research — WTP research methods
  • packaging-architecture-advisor — Tier and bundle design
  • pricing-psychology-guide — Anchoring, decoys, framing
  • monetization-model-advisor — Seat-based vs. usage vs. outcome pricing

Provenance

  • Adapted from research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md (Decision Framework #3)
  • Pricing scenarios from research/finance/Finance for Product Managers.md
快速查阅SaaS财务指标、公式及基准的速查工具。适用于需快速获取定义、公式或基准的场景,如董事会准备或决策评估。按收入、单位经济等分类,提供红牌警示,非教学用途。
需要快速查找SaaS财务指标公式或定义 查询特定指标的基准数据或红牌警示 准备董事会会议或投资者电话会议
skills/finance-metrics-quickref/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill finance-metrics-quickref -g -y
SKILL.md
Frontmatter
{
    "name": "finance-metrics-quickref",
    "type": "component",
    "intent": "Quick reference for any SaaS finance metric without deep teaching. Use this when you need a fast formula lookup, benchmark check, or decision framework reminder. For detailed explanations, calculations, and examples, see the related deep-dive skills.",
    "best_for": [
        "Quick metric lookups during product or finance reviews",
        "Checking formulas and benchmarks without reading a long explainer",
        "Refreshing decision rules for common SaaS metrics"
    ],
    "scenarios": [
        "What is the formula for NRR and what is a good benchmark?",
        "Give me a quick reference for CAC payback and Rule of 40",
        "I need a fast SaaS metrics cheat sheet for a business review"
    ],
    "description": "Look up SaaS finance metrics, formulas, and benchmarks fast. Use when you need a quick metric definition, formula, or benchmark during analysis.",
    "argument-hint": "[metric name]"
}

Purpose

Quick reference for any SaaS finance metric without deep teaching. Use this when you need a fast formula lookup, benchmark check, or decision framework reminder. For detailed explanations, calculations, and examples, see the related deep-dive skills.

This is not a teaching tool—it's a cheat sheet optimized for speed. Scan, find, apply.

Input

Works best with: The metric you need — name it and get the formula, benchmark, and decision context. Also useful: Your numbers, if you want the formula applied on the spot.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. Ask for the metric family you're working in (revenue, retention, efficiency, capital) and scan from there.

Example invocation: Quick ref: burn multiple — formula, benchmark, and whether 1.7 is bad for Series B.

Key Concepts

Metric Categories

Metrics are organized into four families:

  1. Revenue & Growth — Top-line money (revenue, ARPU, ARPA, MRR/ARR, churn, NRR, expansion)
  2. Unit Economics — Customer-level profitability (CAC, LTV, payback, margins)
  3. Capital Efficiency — Cash management (burn rate, runway, OpEx, net income)
  4. Efficiency Ratios — Growth vs. profitability balance (Rule of 40, magic number)

When to Use This Skill

Use this when:

  • You need a quick formula or benchmark
  • You're preparing for a board meeting or investor call
  • You're evaluating a decision and need to check which metrics matter
  • You want to identify red flags quickly

Don't use this when:

  • You need detailed calculation guidance (use saas-revenue-growth-metrics or saas-economics-efficiency-metrics)
  • You're learning these metrics for the first time (start with deep-dive skills)
  • You need examples and common pitfalls (covered in related skills)

Application

All Metrics Reference Table

Metric Formula What It Measures Good Benchmark Red Flag
Revenue Total sales before expenses Top-line money earned Growth rate >20% YoY (varies by stage) Revenue growing slower than costs
ARPU Total Revenue / Total Users Revenue per individual user Varies by model; track trend ARPU declining cohort-over-cohort
ARPA MRR / Active Accounts Revenue per customer account SMB: $100-$1K; Mid: $1K-$10K; Ent: $10K+ High ARPA + low ARPU (undermonetized seats)
ACV Annual Recurring Revenue per Contract Annualized contract value SMB: $5K-$25K; Mid: $25K-$100K; Ent: $100K+ ACV declining (moving downmarket unintentionally)
MRR/ARR MRR × 12 = ARR Predictable recurring revenue Growth + quality matter; track components New MRR declining while churn stable/growing
Churn Rate Customers Lost / Starting Customers % of customers who cancel Monthly <2% great, <5% ok; Annual <10% great Churn increasing cohort-over-cohort
NRR (Start ARR + Expansion - Churn - Contraction) / Start ARR × 100 Revenue retention + expansion >120% excellent; 100-120% good; 90-100% ok NRR <100% (base is contracting)
Expansion Revenue Upsells + Cross-sells + Usage Growth Additional revenue from existing customers 20-30% of total revenue Expansion <10% of MRR
Quick Ratio (New MRR + Expansion MRR) / (Churned MRR + Contraction) Revenue gains vs. losses >4 excellent; 2-4 healthy; <2 leaky bucket Quick Ratio <2 (leaky bucket)
Gross Margin (Revenue - COGS) / Revenue × 100 % of revenue after direct costs SaaS: 70-85% good; <60% concerning Gross margin <60% or declining
CAC Total S&M Spend / New Customers Cost to acquire one customer Varies: Ent $10K+ ok; SMB <$500 CAC increasing while LTV flat
LTV ARPU × Gross Margin % / Churn Rate Total revenue from one customer Must be 3x+ CAC; varies by segment LTV declining cohort-over-cohort
LTV:CAC LTV / CAC Unit economics efficiency 3:1 healthy; <1:1 unsustainable; >5:1 underinvesting LTV:CAC <1.5:1
Payback Period CAC / (Monthly ARPU × Gross Margin %) Months to recover CAC <12 months great; 12-18 ok; >24 concerning Payback >24 months (cash trap)
Contribution Margin (Revenue - All Variable Costs) / Revenue × 100 True contribution after variable costs 60-80% good for SaaS; <40% concerning Contribution margin <40%
Burn Rate Monthly Cash Spent - Revenue Cash consumed per month Net burn <$200K manageable early; <$500K growth Net burn accelerating
Runway Cash Balance / Monthly Net Burn Months until money runs out 12+ months good; 6-12 ok; <6 crisis Runway <6 months
OpEx S&M + R&D + G&A Costs to run the business Should grow slower than revenue OpEx growing faster than revenue
Net Income Revenue - All Expenses Actual profit/loss Early negative ok; mature 10-20%+ margin Losses accelerating without growth
Rule of 40 Revenue Growth % + Profit Margin % Balance of growth vs. efficiency >40 healthy; 25-40 ok; <25 concerning Rule of 40 <25
Magic Number (Q Revenue - Prev Q Revenue) × 4 / Prev Q S&M S&M efficiency >0.75 efficient; 0.5-0.75 ok; <0.5 fix GTM Magic Number <0.5
Operating Leverage Revenue Growth vs. OpEx Growth Scaling efficiency Revenue growth > OpEx growth OpEx growing faster than revenue
Gross vs. Net Revenue Net = Gross - Discounts - Refunds - Credits What you actually keep Refunds <10%; discounts <20% Refunds >10% (product problem)
Revenue Concentration Top N Customers / Total Revenue Dependency on largest customers Top customer <10%; Top 10 <40% Top customer >25% (existential risk)
Revenue Mix Product/Segment Revenue / Total Revenue Portfolio composition No single product >60% ideal Single product >80% (no diversification)
Cohort Analysis Group customers by join date; track behavior Whether business improving or degrading Recent cohorts same/better than old Newer cohorts perform worse
CAC Payback by Channel CAC / Monthly Contribution (by channel) Payback by acquisition channel Compare across channels One channel far worse than others
Gross Margin Payback CAC / (Monthly ARPU × Gross Margin %) Payback using actual profit Typically 1.5-2x simple payback Payback using margin >36 months
Unit Economics Revenue per unit - Cost per unit Profitability of each "unit" Positive contribution required Negative contribution margin
Segment Payback CAC / Monthly Contribution (by segment) Payback by customer segment Compare to allocate resources One segment unprofitable
Incrementality Revenue caused by action - Baseline True impact of marketing/promo Measure with holdout tests Celebrating revenue that would've happened anyway
Working Capital Cash timing between revenue and collection Cash vs. revenue timing Annual upfront > monthly billing Long payment terms killing runway

Quick Decision Frameworks

Use these frameworks to combine metrics for common PM decisions.

Framework 1: Should We Build This Feature?

Ask:

  1. Revenue impact? Direct (pricing, add-on) or indirect (retention, conversion)?
  2. Margin impact? What's the COGS? Does it dilute margins?
  3. ROI? Revenue impact / Development cost

Build if:

  • ROI >3x in year one (direct monetization), OR
  • LTV impact >10x development cost (retention), OR
  • Strategic value overrides short-term ROI

Don't build if:

  • Negative contribution margin even with optimistic adoption
  • Payback period exceeds average customer lifetime

Metrics to check: Revenue, Gross Margin, LTV, Contribution Margin


Framework 2: Should We Scale This Acquisition Channel?

Ask:

  1. Unit economics? CAC, LTV, LTV:CAC ratio
  2. Cash efficiency? Payback period
  3. Customer quality? Cohort retention, NRR by channel
  4. Scalability? Magic Number, addressable volume

Scale if:

  • LTV:CAC >3:1 AND
  • Payback <18 months AND
  • Customer quality meets/beats other channels AND
  • Magic Number >0.75

Don't scale if:

  • LTV:CAC <1.5:1 AND
  • No clear path to improvement

Metrics to check: CAC, LTV, LTV:CAC, Payback Period, NRR, Magic Number


Framework 3: Should We Change Pricing?

Ask:

  1. ARPU/ARPA impact? Will revenue per customer increase?
  2. Conversion impact? Help or hurt trial-to-paid conversion?
  3. Churn impact? Create churn risk or reduce it?
  4. NRR impact? Enable expansion or create contraction?

Implement if:

  • Net revenue impact positive after churn risk
  • Can test with segment before broad rollout

Don't change if:

  • High churn risk without offsetting expansion
  • Can't test hypothesis before committing

Metrics to check: ARPU, ARPA, Churn Rate, NRR, CAC Payback


Framework 4: Is the Business Healthy?

Check by stage:

Early Stage (Pre-$10M ARR):

  • Growth Rate >50% YoY
  • LTV:CAC >3:1
  • Gross Margin >70%
  • Runway >12 months

Growth Stage ($10M-$50M ARR):

  • Growth Rate >40% YoY
  • NRR >100%
  • Rule of 40 >40
  • Magic Number >0.75

Scale Stage ($50M+ ARR):

  • Growth Rate >25% YoY
  • NRR >110%
  • Rule of 40 >40
  • Profit Margin >10%

Metrics to check: Revenue Growth, NRR, LTV:CAC, Rule of 40, Magic Number, Gross Margin


Red Flags by Category

Revenue & Growth Red Flags

Red Flag What It Means Action
Churn increasing cohort-over-cohort Product-market fit degrading Stop scaling acquisition; fix retention first
NRR <100% Base is contracting Fix expansion or reduce churn before scaling
Revenue churn > logo churn Losing big customers Investigate why high-value customers leave
Quick Ratio <2 Leaky bucket (barely outpacing losses) Fix retention before scaling acquisition
Expansion revenue <10% of MRR No upsell/cross-sell engine Build expansion paths
Revenue concentration >50% in top 10 customers Existential dependency risk Diversify customer base

Unit Economics Red Flags

Red Flag What It Means Action
LTV:CAC <1.5:1 Buying revenue at a loss Reduce CAC or increase LTV before scaling
Payback >24 months Cash trap (long cash recovery) Negotiate annual upfront or reduce CAC
Gross margin <60% Low profitability per dollar Increase prices or reduce COGS
CAC increasing while LTV flat Unit economics degrading Optimize conversion or reduce sales cycle
Contribution margin <40% Unprofitable after variable costs Cut variable costs or increase prices

Capital Efficiency Red Flags

Red Flag What It Means Action
Runway <6 months Survival crisis Raise capital immediately or cut burn
Net burn accelerating without revenue growth Burning faster without results Cut costs or increase revenue urgency
OpEx growing faster than revenue Negative operating leverage Freeze hiring; optimize spend
Rule of 40 <25 Burning cash without growth Improve growth or cut to profitability
Magic Number <0.5 S&M engine broken Fix GTM efficiency before scaling spend

When to Use Which Metric

Prioritizing features:

  • Revenue impact → Revenue, ARPU, Expansion Revenue
  • Margin impact → Gross Margin, Contribution Margin
  • ROI → LTV impact, Development cost

Evaluating channels:

  • Acquisition cost → CAC, CAC by Channel
  • Customer value → LTV, NRR by Channel
  • Payback → Payback Period, CAC Payback by Channel
  • Scalability → Magic Number

Pricing decisions:

  • Monetization → ARPU, ARPA, ACV
  • Impact → Churn Rate, NRR, Expansion Revenue
  • Efficiency → CAC Payback (will pricing change affect it?)

Business health:

  • Growth → Revenue Growth, MRR/ARR Growth
  • Retention → Churn Rate, NRR, Quick Ratio
  • Economics → LTV:CAC, Payback Period, Gross Margin
  • Efficiency → Rule of 40, Magic Number, Operating Leverage
  • Survival → Burn Rate, Runway

Board/investor reporting:

  • Key metrics: ARR, Revenue Growth %, NRR, LTV:CAC, Rule of 40, Magic Number, Burn Rate, Runway
  • Stage-specific: Early stage emphasize growth + unit economics; Growth stage emphasize Rule of 40 + Magic Number; Scale stage emphasize profitability + efficiency

Examples

Example 1: Feature Investment Sanity Check

You are deciding whether to build a premium export feature.

  1. Use Framework 1 (Should We Build This Feature?)
  2. Pull baseline metrics: ARPU, Gross Margin, LTV, Contribution Margin
  3. Model optimistic, base, and downside adoption
  4. Reject if contribution margin turns negative in downside case

Quick output:

  • Base case ROI: 3.8x
  • Contribution margin impact: +4 points
  • Decision: Build now, with a 90-day post-launch check on churn and expansion

Example 2: Channel Scale Decision

Paid social is generating many signups but weak retention.

  1. Use Framework 2 (Should We Scale This Acquisition Channel?)
  2. Check CAC, LTV:CAC, Payback Period, and NRR by channel
  3. Compare against best-performing channel, not company average

Quick output:

  • LTV:CAC: 1.6:1
  • Payback: 26 months
  • NRR: 88%
  • Decision: Do not scale; cap spend and run targeted optimization tests

Common Pitfalls

  • Using blended company averages instead of cohort or channel-level metrics
  • Scaling acquisition when Quick Ratio is weak and retention is deteriorating
  • Treating high LTV:CAC as sufficient without checking payback and runway impact
  • Raising prices based on ARPU lift alone without modeling churn and contraction
  • Comparing benchmarks across mismatched company stages or business models
  • Tracking many metrics without a clear decision question

References

Related Skills (Deep Dives)

  • saas-revenue-growth-metrics — Detailed guidance on revenue, retention, and growth metrics (13 metrics)
  • saas-economics-efficiency-metrics — Detailed guidance on unit economics and capital efficiency (17 metrics)
  • feature-investment-advisor — Uses these metrics to evaluate feature ROI
  • acquisition-channel-advisor — Uses these metrics to evaluate channel viability
  • finance-based-pricing-advisor — Uses these metrics to evaluate pricing changes
  • business-health-diagnostic — Uses these metrics to diagnose business health

External Resources

  • Bessemer Venture Partners: "SaaS Metrics 2.0" — Comprehensive SaaS benchmarking
  • David Skok (Matrix Partners): "SaaS Metrics" blog series — Deep dive on unit economics
  • Tomasz Tunguz (Redpoint): SaaS benchmarking research and blog
  • ChartMogul, Baremetrics, ProfitWell: SaaS analytics platforms with metric definitions
  • SaaStr: Annual SaaS benchmarking surveys

Provenance

  • Adapted from research/finance/Finance_QuickRef.md
  • Formulas from research/finance/Finance for Product Managers.md
  • Decision frameworks from research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md
基于JTBD框架系统分析客户的目标、痛点与收益,区分功能、社交及情感需求。适用于挖掘未满足需求、验证产品理念、优化定位与 messaging,避免将表面功能请求误认为真实动机。
澄清未满足的客户需求 重新定位产品价值主张 改进用户发现与营销信息
skills/jobs-to-be-done/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill jobs-to-be-done -g -y
SKILL.md
Frontmatter
{
    "name": "jobs-to-be-done",
    "type": "component",
    "intent": "Systematically explore what customers are trying to accomplish (functional, social, emotional jobs), the pains they experience, and the gains they seek. Use this framework to uncover unmet needs, validate product ideas, and ensure your solution addresses real motivations—not just surface-level feature requests.",
    "description": "Uncover customer jobs, pains, and gains in a structured JTBD format. Use when clarifying unmet needs, repositioning a product, or improving discovery and messaging.",
    "argument-hint": "[customer segment or product]"
}

Purpose

Systematically explore what customers are trying to accomplish (functional, social, emotional jobs), the pains they experience, and the gains they seek. Use this framework to uncover unmet needs, validate product ideas, and ensure your solution addresses real motivations—not just surface-level feature requests.

This is not a survey—it's a structured lens for understanding why customers "hire" your product and what would make them "fire" it.

Input

Works best with: The customer segment (or product whose customers) you're analyzing. Also useful: Interview notes, support tickets, or research to mine for jobs, pains, and gains; the situation or trigger you care about.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks who the customer is and what progress they're trying to make before structuring the JTBD breakdown.

Example invocation: Run JTBD for freelance designers using our invoicing tool — here are 6 interview summaries.

Key Concepts

The Jobs-to-be-Done Framework

Influenced by Clayton Christensen and the Value Proposition Canvas (Osterwalder), JTBD breaks customer needs into three categories:

1. Customer Jobs:

  • Functional jobs: Tasks customers need to perform (e.g., "send an invoice")
  • Social jobs: How customers want to be perceived (e.g., "look professional to clients")
  • Emotional jobs: Emotional states customers seek or avoid (e.g., "feel confident in my work")

2. Pains:

  • Challenges: Obstacles customers face
  • Costliness: What's too expensive in time, money, or effort
  • Common mistakes: Errors customers make that could be prevented
  • Unresolved problems: Gaps in current solutions

3. Gains:

  • Expectations: What would exceed current solutions
  • Savings: Time, money, or effort reductions that delight
  • Adoption factors: What increases likelihood of switching
  • Life improvement: How a solution makes life easier or more enjoyable

Why This Structure Works

  • Separates job from solution: "Communicate with my team" (job) ≠ "email" (solution)
  • Reveals underlying motivations: Functional job may be "track expenses," but emotional job is "feel in control of finances"
  • Surfaces competition you didn't see: Customers "hire" non-obvious alternatives (pen and paper, spreadsheets, workarounds)
  • Prioritizes by intensity: Not all pains are equal—focus on the most acute

Anti-Patterns (What This Is NOT)

  • Not a feature wishlist: "I want AI, automation, and dashboards" is not a job
  • Not demographics: "Millennials want mobile-first" is a persona trait, not a job
  • Not generic: "Be more productive" is too vague—dig into which tasks and why
  • Not one-dimensional: Focusing only on functional jobs misses social/emotional motivations

When to Use This

  • Early-stage discovery (before you know the solution)
  • Validating product-market fit (does your solution address the right jobs?)
  • Prioritizing roadmap (which jobs are most painful/important?)
  • Competitive analysis (what are customers "hiring" competitors for?)
  • Marketing messaging (speak to jobs, not features)

When NOT to Use This

  • After you've already built the product (too late for discovery)
  • For trivial features (don't over-analyze small tweaks)
  • As a substitute for quantitative validation (JTBD informs hypotheses; data validates them)

Application

Use template.md for the full fill-in structure.

Step 1: Define the Context

Before exploring JTBD, clarify:

  • Target customer segment: Who are you studying? (reference skills/proto-persona/SKILL.md)
  • Situation: In what context does the job arise? (e.g., "When managing a project deadline...")
  • Current solutions: What do they use today? (competitors, workarounds, doing nothing)

If missing context: Conduct customer interviews, contextual inquiries, or "switch interviews" (why they switched from a previous solution).


Step 2: Explore Customer Jobs

Functional Jobs

Ask: "What tasks are you trying to complete?"

### Functional Jobs:
- [Task 1 customer needs to perform]
- [Task 2 customer needs to perform]
- [Task 3 customer needs to perform]

Examples:

  • "Reconcile monthly expenses for tax filing"
  • "Onboard a new team member in under 2 hours"
  • "Deploy code to production without downtime"

Quality checks:

  • Verb-driven: Jobs are actions ("send," "analyze," "coordinate")
  • Solution-agnostic: Don't say "use email to communicate"—say "communicate with remote teammates"
  • Specific: "Manage finances" is too broad; "Track business expenses for tax deductions" is specific

Social Jobs

Ask: "How do you want to be perceived by others?"

### Social Jobs:
- [Way customer wants to be perceived socially 1]
- [Way customer wants to be perceived socially 2]
- [Way customer wants to be perceived socially 3]

Examples:

  • "Be seen as a strategic thinker by my exec team"
  • "Appear responsive and reliable to clients"
  • "Look tech-savvy to my younger colleagues"

Quality checks:

  • Audience-specific: Who is the customer trying to impress? (boss, clients, peers, etc.)
  • Emotional weight: Social jobs often drive adoption more than functional jobs

Emotional Jobs

Ask: "What emotional state do you want to achieve or avoid?"

### Emotional Jobs:
- [Emotional state customer seeks or avoids 1]
- [Emotional state customer seeks or avoids 2]
- [Emotional state customer seeks or avoids 3]

Examples:

  • "Feel confident I'm not missing important details"
  • "Avoid the anxiety of manual data entry errors"
  • "Feel a sense of accomplishment at the end of the day"

Quality checks:

  • Positive and negative: Include both what they seek ("feel in control") and what they avoid ("avoid embarrassment")
  • Rooted in research: Don't fabricate emotions—use customer quotes

Step 3: Identify Pains

Challenges

Ask: "What obstacles are preventing you from completing this job?"

### Challenges:
- [Obstacle customer faces 1]
- [Obstacle customer faces 2]
- [Obstacle customer faces 3]

Examples:

  • "Tools don't integrate, forcing manual data entry"
  • "No visibility into what teammates are working on"
  • "Approval processes take 3+ days, blocking progress"

Costliness

Ask: "What takes too much time, money, or effort?"

### Costliness:
- [What's too costly in time, money, or effort 1]
- [What's too costly in time, money, or effort 2]

Examples:

  • "Generating monthly reports takes 8 hours of manual work"
  • "Hiring a specialist costs $10k, which we can't afford"
  • "Learning the current tool requires 20+ hours of training"

Common Mistakes

Ask: "What errors do you make frequently that could be prevented?"

### Common Mistakes:
- [Frequent error 1]
- [Frequent error 2]

Examples:

  • "Forgetting to CC stakeholders on critical emails"
  • "Miscalculating tax deductions due to missing receipts"
  • "Accidentally overwriting someone else's work in shared files"

Unresolved Problems

Ask: "What problems do current solutions fail to address?"

### Unresolved Problems:
- [Problem not solved by current solutions 1]
- [Problem not solved by current solutions 2]

Examples:

  • "Current CRM doesn't track customer health scores"
  • "Email doesn't preserve conversation context when people are added mid-thread"
  • "Existing tools require technical expertise we don't have"

Step 4: Uncover Gains

Expectations

Ask: "What would make you love a solution?"

### Expectations:
- [What could exceed expectations 1]
- [What could exceed expectations 2]

Examples:

  • "Automatically categorizes expenses without manual tagging"
  • "Suggests next steps based on project status"
  • "Integrates seamlessly with tools we already use"

Savings

Ask: "What savings in time, money, or effort would delight you?"

### Savings:
- [Way of saving time, money, or effort 1]
- [Way of saving time, money, or effort 2]

Examples:

  • "Reduce report generation from 8 hours to 10 minutes"
  • "Eliminate the need for a full-time admin"
  • "Cut onboarding time from 2 weeks to 2 days"

Adoption Factors

Ask: "What would make you switch from your current solution?"

### Adoption Factors:
- [Factor increasing likelihood of adoption 1]
- [Factor increasing likelihood of adoption 2]

Examples:

  • "Free trial with no credit card required"
  • "Migration support to import existing data"
  • "Testimonials from companies like ours"

Life Improvement

Ask: "How would your life be better if this job were easier?"

### Life Improvement:
- [How solution makes life easier or more enjoyable 1]
- [How solution makes life easier or more enjoyable 2]

Examples:

  • "I could leave work on time instead of staying late to finish reports"
  • "I'd feel less stressed about missing important deadlines"
  • "I could focus on strategic work instead of busywork"

Step 5: Prioritize and Validate

  • Rank pains by intensity: Which pains are acute vs. mild annoyances?
  • Identify must-have vs. nice-to-have gains: What would drive adoption vs. what's just a bonus?
  • Cross-reference with personas: Do different personas have different jobs/pains/gains? (reference skills/proto-persona/SKILL.md)
  • Validate with data: Survey a broader audience to confirm JTBD insights from interviews

Examples

See examples/sample.md for full JTBD examples.

Mini example excerpt:

**Functional Jobs:** Coordinate tasks across a distributed team
**Pains - Challenges:** Team members use different tools, creating silos
**Gains - Savings:** Reduce status reporting time from 3 hours to 15 minutes

Common Pitfalls

Pitfall 1: Confusing Jobs with Solutions

Symptom: "I need to use Slack" or "I need AI-powered analytics"

Consequence: You've anchored on a solution, not the underlying job.

Fix: Ask "Why?" 5 times. "I need Slack" → "Why?" → "To communicate with my team" → "Why?" → "To get quick answers" → "Why?" → "To avoid project delays."


Pitfall 2: Generic Jobs

Symptom: "Be more productive" or "Save time"

Consequence: Too vague to inform product decisions.

Fix: Get specific. "Save time" → "Reduce time spent generating monthly reports from 8 hours to 1 hour."


Pitfall 3: Ignoring Social/Emotional Jobs

Symptom: Only documenting functional jobs

Consequence: You miss powerful motivators. People often buy based on emotional/social needs, not just functional.

Fix: Explicitly ask about perception and emotions in interviews. "How would solving this make you feel?" "Who would notice if you solved this?"


Pitfall 4: Fabricating JTBD Without Research

Symptom: Filling out the template based on assumptions

Consequence: You're guessing. JTBD analysis is only valuable if grounded in real customer insights.

Fix: Conduct "switch interviews" (ask why they switched from a previous solution), contextual inquiries, or problem validation interviews.


Pitfall 5: Treating All Pains as Equal

Symptom: Listing 20 pains without prioritization

Consequence: No clarity on what to solve first.

Fix: Rank pains by intensity (acute vs. mild). Ask "If we only solved one pain, which would have the biggest impact?"


References

Related Skills

  • skills/proto-persona/SKILL.md — Defines who has these jobs/pains/gains
  • skills/problem-statement/SKILL.md — JTBD informs the "Trying to" and "But" sections
  • skills/positioning-statement/SKILL.md — JTBD informs the "that need" statement

External Frameworks

  • Clayton Christensen, Competing Against Luck (2016) — Origin of Jobs-to-be-Done theory
  • Tony Ulwick, Outcome-Driven Innovation (2016) — Quantifying jobs and outcomes
  • Alexander Osterwalder, Value Proposition Canvas (2014) — Customer jobs/pains/gains framework

Dean's Work

  • [Link to relevant Dean Peters' Substack articles if applicable]

Provenance

  • Adapted from prompts/jobs-to-be-done.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: jobs-to-be-done.md Suggested placement: /skills/components/ Dependencies: References skills/proto-persona/SKILL.md Used by: skills/positioning-statement/SKILL.md, skills/problem-statement/SKILL.md, skills/epic-hypothesis/SKILL.md

指导团队使用精益画布v2,聚焦业务问题而非解决方案。通过梳理假设、定义学习目标并设计实验,帮助跨职能团队对齐认知,将产出转化为成果,避免无效开发,确保每次迭代都能验证核心价值。
需要框定业务问题或重构解决方案想法时 团队需梳理核心假设以设计可测试的实验 希望从关注功能输出转向关注业务成果时 在启动新项目或冲刺前暴露理解盲区
skills/lean-ux-canvas/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill lean-ux-canvas -g -y
SKILL.md
Frontmatter
{
    "name": "lean-ux-canvas",
    "type": "interactive",
    "intent": "Guide product managers through creating **Jeff Gothelf's Lean UX Canvas (v2)**—a one-page facilitation tool that frames work around a **business problem to solve**, not a **solution to implement**. Use this to align cross-functional teams around core assumptions, craft testable hypotheses, and ensure learning happens every sprint by exposing gaps in understanding (problem, users, value, and why the solution should work).",
    "best_for": [
        "Framing a business problem before solutioning",
        "Surfacing assumptions in a cross-functional workshop",
        "Turning a vague initiative into hypotheses and learning goals"
    ],
    "scenarios": [
        "Help me run a Lean UX Canvas workshop for onboarding drop-off",
        "Use Lean UX Canvas to frame a new AI product idea",
        "We have a business problem but too many assumptions. Run a Lean UX Canvas session."
    ],
    "description": "Guide teams through Lean UX Canvas v2. Use when framing a business problem, surfacing assumptions, and defining what to learn next.",
    "argument-hint": "[business problem]"
}

Purpose

Guide product managers through creating Jeff Gothelf's Lean UX Canvas (v2)—a one-page facilitation tool that frames work around a business problem to solve, not a solution to implement. Use this to align cross-functional teams around core assumptions, craft testable hypotheses, and ensure learning happens every sprint by exposing gaps in understanding (problem, users, value, and why the solution should work).

This is not a roadmap or feature list—it's an "insurance policy" that turns assumptions into experiments before committing to full development. The canvas shifts conversations from outputs to outcomes and ensures teams build the right thing, not just build things right.

Input

Works best with: The business problem you're framing — or the solution idea you're being handed, which the canvas will reframe as a problem. Also useful: Known users, evidence so far, and what the team already believes (assumptions to surface).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill opens with Box 1: what business problem are you trying to solve?

Example invocation: Fill a Lean UX canvas: leadership wants 'an AI chatbot' — underlying problem seems to be support ticket volume growing 3x faster than the team.

Key Concepts

What is the Lean UX Canvas?

The Lean UX Canvas (v2) is a structured, one-page template designed to help teams frame their work around a business problem, not a solution. It aligns cross-functional teams on:

  • What problem exists (and why it matters now)
  • What measurable outcomes indicate success
  • Who we're solving for
  • What assumptions we're making
  • What we need to learn first
  • What experiments will test those assumptions

Origin: Created by Jeff Gothelf, author of Lean UX (O'Reilly, 2013). Version 2 was released to improve clarity around business vs. user outcomes.

Key Insight: The canvas acts like an insurance policy—it exposes gaps in understanding before you build, ensuring you don't waste sprints on the wrong thing.


Canvas Structure (8 Boxes)

Layout (3 columns × 3 rows):

┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │              │ 2. Business Outcomes  │
│                     │              │                       │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users            │  (tall box   │ 4. User Outcomes      │
│                     │   spanning   │    & Benefits         │
├─────────────────────┤   rows 1-2)  ├───────────────────────┤
│ 6. Hypotheses       │──────────────┤ 8. Least Work /       │
│                     │ 7. Learn     │    Experiments        │
│                     │    First     │                       │
└─────────────────────┴──────────────┴───────────────────────┘

The 8 Boxes (fill in this order):

  1. Business Problem — What changed in the world that created a problem worth solving?
  2. Business Outcomes — What measurable behavior change indicates success?
  3. Users — Which persona(s) should you focus on first?
  4. User Outcomes & Benefits — Why would users seek this? What benefit do they gain?
  5. Solutions — What features/initiatives might solve the problem and meet user needs?
  6. Hypotheses — Testable assumptions combining boxes 2-5 (If/Then format)
  7. What's Most Important to Learn First? — The single riskiest assumption right now
  8. What's the Least Work to Learn Next? — Smallest experiment to validate/invalidate that assumption

Why This Works

Problem-First, Not Solution-First: Starts with "what changed in the world?" not "we should build X." This prevents solution-driven thinking.

Assumption-Driven: Makes hypotheses explicit before building. Every discipline surfaces their risks (technical feasibility, user value, business viability).

Experiment-Focused: Tests assumptions before committing resources. Small experiments beat big bets.

Cross-Functional Alignment: Shared canvas creates common language. Everyone sees the same gaps in understanding.


Key Distinctions (Avoid Confusion)

Box 2 (Business Outcomes) vs. Box 4 (User Outcomes):

  • Box 2: Measurable behavior change (retention rate, time on site, average order value)
  • Box 4: Goals, benefits, emotions, empathy (save money, get promoted, spend time with family)

Box 2 is metrics. Box 4 is human.

Solutions (Box 5) Are Hypotheses, Not Commitments: List candidate solutions (features, policies, even business model shifts). You're not committing to build all of them—you're exploring the solution space.

Hypotheses (Box 6) Are Testable: Use the template: "We believe [business outcome] will be achieved if [user] attains [benefit] with [solution]." Each hypothesis focuses on one solution.


Anti-Patterns (What This Is NOT)

  • Not a feature list: Solutions are ideas to test, not a backlog
  • Not a project plan: Canvas frames learning, not delivery timelines
  • Not a replacement for strategy: Canvas executes strategy; it doesn't create it
  • Not a one-time exercise: Re-visit as you learn; update assumptions

When to Use This

Use this when:

  • Starting a new product initiative or feature
  • Reframing an existing project (suspect you're building the wrong thing)
  • Aligning cross-functional teams on assumptions and experiments
  • Planning discovery sprints or MVPs
  • Stakeholders are solution-driven ("we need to build X") and you need to expose assumptions

Don't use this when:

  • Problem and solution are already validated (move to execution)
  • Tactical bug fixes or technical debt (no learning needed)
  • Stakeholders have committed to a solution regardless of evidence (address alignment first)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

Use template.md for the full fill-in structure.

This interactive skill walks through 8 adaptive questions (one per canvas box) in sequence. At each step, the agent offers guidance, examples, and options to help you fill the box correctly.


Step 0: Gather Context

Agent asks:

Before we fill out the Lean UX Canvas, let's gather context. Please share:

Business Context:

  • Stakeholder request, product brief, or initiative description
  • Business metrics (revenue, churn, growth targets, KPIs)
  • Strategic goals (OKRs, roadmap priorities)

User Context:

  • Customer research, personas, JTBD insights
  • User feedback, support tickets, churn reasons
  • Competitor analysis, market trends

You can paste:

  • PRD or product brief
  • Stakeholder memo
  • User research summary
  • Just describe the initiative briefly

Question 1: Business Problem (Box 1)

Agent asks:

What problem does the business have that you are trying to solve?

Describe:

  • Current state: How does the business deliver value today?
  • What changed: Market shift, competitive threat, customer behavior change, new delivery channel
  • Why it matters: Why isn't the current situation meeting expectations?

Good examples:

  • "Our checkout conversion rate dropped 15% after mobile traffic surpassed desktop. Our checkout flow wasn't designed for mobile, and competitors have one-tap checkout."
  • "Enterprise customers are churning after 6 months because our onboarding process requires 3+ weeks of manual configuration. Competitors offer self-service onboarding."

Bad examples (too vague):

  • "We need to increase revenue" (no context on what changed)
  • "Users want more features" (no business problem stated)

Agent offers 3 options:

  1. I'll describe the business problem — [Paste or write your description]
  2. Help me identify the business problem — [Agent asks follow-up questions: What changed? What metrics are affected? What are competitors doing?]
  3. I'm not sure what the business problem is — [Agent suggests starting with skills/problem-statement/SKILL.md or skills/problem-framing-canvas/SKILL.md first]

User response: [Selection or description]

Agent validates: Does this describe what changed and why it creates a problem? If not, ask clarifying questions.


Question 2: Business Outcomes (Box 2)

Agent asks:

How will you know you solved the business problem? What will you measure?

Focus on measurable behavior change (leading indicators welcome). Ask yourself: "What will people be doing differently if the solution works?"

Examples of business outcomes:

  • Increase mobile checkout conversion rate from 45% to 60%
  • Reduce enterprise onboarding time from 3 weeks to 3 days
  • Increase average order value from $50 to $75
  • Reduce customer support tickets by 30%
  • Increase free-to-paid conversion rate from 5% to 10%

Important: This is Box 2 (behavior change), not Box 4 (user benefits/empathy). Metrics go here. Emotions go in Box 4.

Agent offers 3 options:

  1. I have specific metrics in mind — [State your business outcomes]
  2. Help me define measurable outcomes — [Agent suggests metrics based on the business problem]
  3. I only have lagging indicators (revenue, profit) — [Agent helps identify leading indicators that predict those outcomes]

User response: [Selection or description]

Agent validates: Are these measurable? Observable? Do they indicate behavior change (not just "increase revenue")?


Question 3: Users (Box 3)

Agent asks:

What types (i.e., personas) of users and customers should you focus on first?

Consider:

  • Who buys it?
  • Who uses it?
  • Who configures it?
  • Who administers it?

Why this matters: Teams tend to shortcut here ("everyone"). The canvas wants a shared vision of the user—and it's not always "the customer."

Examples:

  • "SMB owners (1-10 employees) in professional services (consultants, accountants, lawyers)"
  • "Enterprise IT admins who configure SSO for 500+ employees"
  • "Mobile-first millennials (25-35) who order takeout 3+ times per week"

Agent offers 3 options:

  1. I have personas already — [Reference skills/proto-persona/SKILL.md or paste persona]
  2. Help me identify target users — [Agent asks: Who experiences the business problem most? Who's most likely to adopt? Who's easiest to reach?]
  3. I need to create personas first — [Agent suggests using skills/proto-persona/SKILL.md component skill]

User response: [Selection or description]

Agent validates: Is this specific enough to imagine a real person? Or is it too broad ("all users")?


Question 4: User Outcomes & Benefits (Box 4)

Agent asks:

Why would your users seek out your product or service? What benefit would they gain? What behavior change can we observe that tells us they've achieved their goal?

Focus on goals, benefits, emotions, empathy—not metrics (those go in Box 2).

Examples of user outcomes & benefits:

  • Save 10 hours per week on manual data entry (spend more time with family)
  • Get promoted by delivering projects faster
  • Avoid embarrassment of failed checkout in front of friends
  • Feel confident configuring enterprise software without calling support

Why this matters: This is the empathy box. It's about human motivation, not just behavior change.

Agent offers 3 options:

  1. I know what users want to achieve — [Describe user benefits]
  2. Help me identify user benefits — [Agent prompts: What job are they hiring this product to do? What pain are they avoiding? What gain are they seeking?]
  3. I need to research this first — [Agent suggests skills/jobs-to-be-done/SKILL.md or skills/discovery-interview-prep/SKILL.md]

User response: [Selection or description]

Agent validates: Does this explain why the user cares (not just what they'll do)?


Question 5: Solutions (Box 5)

Agent asks:

What can we make that will solve our business problem and meet the needs of our customers at the same time?

List features, initiatives, policies, systems, or even business model shifts that might work. Encourage a wide solution space: big/small, innovative, "weird," and non-technical solutions.

Examples:

  • One-tap mobile checkout (Apple Pay, Google Pay)
  • Self-service onboarding wizard (no human configuration)
  • AI-powered recommendation engine
  • Concierge onboarding (high-touch, manual—test before automating)
  • Change pricing model (usage-based instead of flat rate)

Important: These are hypotheses, not commitments. You're exploring options, not committing to build everything.

Agent offers 3 options:

  1. I have solution ideas — [List your candidate solutions]
  2. Help me brainstorm solutions — [Agent suggests solutions based on problem, outcomes, and users]
  3. I only have one solution in mind — [Agent challenges: "What else could solve this? What if that solution doesn't work?"]

User response: [Selection or description]

Agent validates: Do you have at least 3 candidate solutions? (More options = better hypotheses later)


Question 6: Hypotheses (Box 6)

Agent asks:

Now let's create testable hypotheses by combining assumptions from Boxes 2-5.

Use this template:

We believe that [business outcome from Box 2] will be achieved if [user from Box 3] attains [benefit from Box 4] with [solution from Box 5].

Rules:

  • Each hypothesis focuses on one solution (from Box 5)
  • Combines assumptions from Boxes 2, 3, 4, and 5
  • Must be testable (you can design an experiment to validate/invalidate it)

Example:

We believe that increasing mobile checkout conversion rate from 45% to 60% will be achieved if mobile-first millennials (25-35) attain faster, friction-free checkout with one-tap Apple Pay integration.

Agent offers:

Based on your inputs, here are suggested hypotheses (one per solution from Box 5):

  1. [Generated hypothesis 1]
  2. [Generated hypothesis 2]
  3. [Generated hypothesis 3]

Options:

  • Accept these hypotheses — [Agent records them]
  • Edit a hypothesis — [Modify wording]
  • Write my own hypotheses — [Use the template]

User response: [Selection or description]

Agent validates: Does each hypothesis clearly state what you believe will happen if the solution works?


Question 7: What's the Most Important Thing We Need to Learn First? (Box 7)

Agent asks:

For each hypothesis from Box 6, identify its riskiest assumptions. Then determine the riskiest one right now.

Types of risk:

  • Value risk: Will users actually use this? Do they care?
  • Usability risk: Can users figure out how to use it?
  • Feasibility risk: Can we technically build this?
  • Viability risk: Will this achieve the business outcome?

Hint: Early on, focus risk on value more than feasibility (most of the time). Don't build something users don't want, even if it's technically feasible.

Agent offers:

Based on your hypotheses, here are the riskiest assumptions:

  1. [Hypothesis 1 risk] — e.g., "Users will trust one-tap checkout without seeing itemized charges"
  2. [Hypothesis 2 risk] — e.g., "Self-service onboarding will reduce setup time to <3 days"
  3. [Hypothesis 3 risk] — e.g., "AI recommendations will increase average order value by 50%"

Which is the riskiest right now?

Options:

  1. Risk 1 — [Select and explain why]
  2. Risk 2 — [Select and explain why]
  3. Risk 3 — [Select and explain why]
  4. I'm not sure which is riskiest — [Agent helps prioritize: Which assumption, if wrong, would kill the initiative?]

User response: [Selection]

Agent records: This is the assumption we'll test first.


Question 8: What's the Least Amount of Work We Need to Do to Learn the Next Most Important Thing? (Box 8)

Agent asks:

Design an experiment to validate or invalidate the riskiest assumption (from Box 7) as fast as you can.

Examples of experiment types:

  • Customer interviews — 5-10 interviews to test value hypothesis
  • Landing page — Fake door test to measure interest
  • Concierge / manual prototype — High-touch, manual version before automating
  • Wizard-of-Oz — Pretend the feature exists (humans behind the scenes)
  • Smoke test — Announce the feature, measure signups

Reminder: Experiment design is an art. The canvas nudges you to do it—expect to iterate on the experiment design separately.

Agent offers:

Based on your riskiest assumption, here are experiment options:

  1. Customer Interviews — Talk to 10 users, ask if they'd use [solution], observe their current workaround
  2. Landing Page Test — Create a landing page describing [solution], measure signup rate
  3. Concierge Test — Manually deliver [benefit] to 5 users, observe if they achieve [outcome]
  4. Wizard-of-Oz Prototype — Fake [solution] with humans behind the scenes, see if users complete the workflow
  5. Design a custom experiment — [Describe your experiment]

Which experiment will you run?

User response: [Select one or describe custom experiment]

Agent validates: Is this the smallest test that can validate/invalidate the assumption? (If it takes >2 weeks, it's too big—break it down.)


Step 9: Review and Export Canvas

Agent summarizes:

Here's your completed Lean UX Canvas (v2):

┌─────────────────────────────────────────────────────────────┐
│ Lean UX Canvas (v2)                                         │
│ Initiative: [Title]                                         │
│ Date: [Today's date]                                        │
│ Iteration: 1                                                │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │              │ 2. Business Outcomes  │
│ [Your input]        │              │ [Your input]          │
│                     │              │                       │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users            │              │ 4. User Outcomes      │
│ [Your input]        │ [Your input] │    & Benefits         │
│                     │              │ [Your input]          │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. Hypotheses       │ 7. Learn     │ 8. Experiments        │
│ [Your input]        │    First     │ [Your input]          │
│                     │ [Your input] │                       │
└─────────────────────┴──────────────┴───────────────────────┘

Next steps:

  1. Run the experiment (Box 8) — Set a timeline (e.g., 2 weeks)
  2. Document learnings — What did you learn? Was the assumption validated or invalidated?
  3. Update the canvas — Revise hypotheses based on learnings, choose next riskiest assumption
  4. Iterate — Repeat Box 7 → Box 8 until confidence is high enough to build

Agent asks:

Would you like me to:

  1. Export this canvas as a Markdown file?
  2. Suggest related skills to use next (e.g., skills/discovery-interview-prep/SKILL.md for customer interviews)?
  3. Refine a specific box (if something feels incomplete)?

Examples

See examples/sample.md for full Lean UX Canvas examples.

Mini example excerpt:

**Box 1:** Mobile checkout conversion is 15% lower than desktop
**Box 2:** Increase mobile conversion from 45% to 60%
**Box 8:** Wizard-of-Oz test with one-tap checkout

Common Pitfalls

1. Starting with Solutions, Not Problems

Failure Mode: Box 1 says "We need to build X" instead of describing what changed.

Consequence: You build the solution someone already decided on, without validating the problem exists.

Fix: Ask: "What changed in the world? Why is this a problem now (vs. 6 months ago)?"


2. Vague Business Outcomes

Failure Mode: Box 2 says "Increase revenue" or "Make users happy."

Consequence: No way to measure success; can't tell if experiments worked.

Fix: Define measurable behavior change. "Increase average order value from $50 to $75" or "Reduce support tickets by 30%."


3. Too-Broad User Segments

Failure Mode: Box 3 says "All users" or "Everyone."

Consequence: Can't design targeted experiments; waste time on personas who won't adopt.

Fix: Pick one persona to start. You can expand later.


4. Confusing Box 2 and Box 4

Failure Mode: Putting emotions in Box 2 and metrics in Box 4 (or vice versa).

Consequence: Misaligned hypotheses; unclear success criteria.

Fix: Box 2 = Behavior change (metrics). Box 4 = Goals, benefits, emotions (empathy).


5. Only One Solution in Box 5

Failure Mode: Listing one feature because stakeholders already decided.

Consequence: No exploration of alternatives; can't test which solution is best.

Fix: Force yourself to list 3+ solutions. Ask: "What else could solve this problem?"


6. Skipping Experiments (Box 8)

Failure Mode: "We'll just build it and see what happens."

Consequence: Waste weeks/months building the wrong thing.

Fix: Design smallest experiment first. If you can't think of one, use skills/pol-probe-advisor/SKILL.md to choose a validation method.


References

Related Skills

External Frameworks

  • Jeff GothelfLean UX: Designing Great Products with Agile Teams (O'Reilly, 2013; 2nd ed. 2016)
  • Jeff GothelfLean UX Canvas v2 (official blog post)
  • Lean UX Canvas PDFDownload v2 PDF

Tools

  • Miro / Mural — Digital whiteboard for collaborative canvas filling
  • Google Slides / PowerPoint — Template available from Jeff Gothelf's site
  • Notion / Coda — Database view for tracking multiple canvases
指导产品经理构建机会解决方案树,从模糊需求结构化探索目标、客户痛点、潜在方案及验证实验。避免过早收敛和特性工厂模式,确保在开发前解决正确问题。
利益相关者提出功能或产品发起请求 需要对模糊的产品需求进行问题界定和结构化发现
skills/opportunity-solution-tree/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill opportunity-solution-tree -g -y
SKILL.md
Frontmatter
{
    "name": "opportunity-solution-tree",
    "type": "interactive",
    "intent": "Guide product managers through creating an Opportunity Solution Tree (OST) by extracting target outcomes from stakeholder requests, generating opportunity options (problems to solve), mapping potential solutions, and selecting the best proof-of-concept (POC) based on feasibility, impact, and market fit. Use this to move from vague product requests to structured discovery, ensuring teams solve the right problems before jumping to solutions—avoiding \"feature factory\" syndrome and premature convergence on ideas.",
    "description": "Build an Opportunity Solution Tree from outcomes to opportunities, solutions, and tests. Use when a stakeholder request needs problem framing before you decide what to build.",
    "argument-hint": "[stakeholder request or outcome]"
}

Purpose

Guide product managers through creating an Opportunity Solution Tree (OST) by extracting target outcomes from stakeholder requests, generating opportunity options (problems to solve), mapping potential solutions, and selecting the best proof-of-concept (POC) based on feasibility, impact, and market fit. Use this to move from vague product requests to structured discovery, ensuring teams solve the right problems before jumping to solutions—avoiding "feature factory" syndrome and premature convergence on ideas.

This is not a roadmap generator—it's a structured discovery process that outputs validated opportunities with testable solution hypotheses.

Input

Works best with: The stakeholder request or the target outcome you're starting from. Also useful: Customer evidence you already have, constraints, and solutions already being pushed.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill opens by asking for the request or desired outcome, then extracts the measurable target outcome from it.

Example invocation: Build an OST from this request: 'Sales says we need a mobile app because competitors have one.'

Key Concepts

What is an Opportunity Solution Tree (OST)?

An OST is a visual framework (Teresa Torres, Continuous Discovery Habits) that connects:

  1. Desired Outcome (business goal or product metric)
  2. Opportunities (customer problems, needs, pain points, or desires that could drive the outcome)
  3. Solutions (ways to address each opportunity)
  4. Experiments (tests to validate solutions)

Structure:

         Desired Outcome (1)
                |
    +-----------+-----------+
    |           |           |
Opportunity  Opportunity  Opportunity (3)
    |           |           |
  +-+-+       +-+-+       +-+-+
  | | |       | | |       | | |
 S1 S2 S3    S1 S2 S3    S1 S2 S3 (9 total solutions)

Why This Works

  • Outcome-driven: Starts with business goal, not feature requests
  • Divergent before convergent: Explores multiple opportunities before picking solutions
  • Problem-focused: Opportunities are problems, not solutions disguised as problems
  • Testable: Each solution maps to experiments, not just "build it and ship"
  • POC selection: Evaluates feasibility, impact, market fit before committing resources

Anti-Patterns (What This Is NOT)

  • Not a feature list: Opportunities are problems customers face, not "we need dark mode"
  • Not solution-first: Don't start with "we should build X"—start with "customers struggle with Y"
  • Not waterfall planning: OST is a discovery tool, not a project plan
  • Not a one-time exercise: OSTs evolve as you learn from experiments

When to Use This

  • Stakeholder requests a feature or product initiative
  • Starting discovery for a new product area
  • Clarifying vague OKRs or strategic goals
  • Prioritizing which problems to solve first
  • Aligning team on what outcomes you're driving

When NOT to Use This

  • When the problem is already validated (move to solution testing)
  • For tactical bug fixes or technical debt (no discovery needed)
  • When stakeholders demand a specific solution (address alignment issues first)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

Use template.md for the full fill-in structure.

This interactive skill follows a two-phase process:

Phase 1: Generate OST (extract outcome, identify opportunities, map solutions) Phase 2: Select POC (evaluate solutions, recommend best starting point)


Step 0: Gather Context (Before Questions)

Agent suggests:

Before we create your Opportunity Solution Tree, let's gather context:

Stakeholder Request or Product Initiative:

  • What did the stakeholder ask for? (Feature request, product idea, strategic goal)
  • Any existing materials: PRD drafts, OKR documents, strategy memos, meeting notes
  • Problem statements, customer complaints, or research findings

Product Context (if available):

  • Website copy, positioning statements, product descriptions
  • Competitor materials, customer reviews (G2, Capterra), community discussions
  • Usage data, support tickets, churn reasons

You can paste this content directly, or describe the request briefly.


Phase 1: Generate Opportunity Solution Tree

Question 1: Extract Desired Outcome

Agent asks: "What's the desired outcome for this initiative? (What business or product metric are you trying to move?)"

Offer 4 enumerated options:

  1. Revenue growth — "Increase ARR, expand revenue from existing customers, new revenue streams" (Common for scaling products)
  2. Customer retention — "Reduce churn, increase activation, improve engagement/stickiness" (Common for established products with retention issues)
  3. Customer acquisition — "Increase sign-ups, trial conversions, new user growth" (Common for early-stage or growth products)
  4. Product efficiency — "Reduce support costs, decrease time-to-value, improve operational metrics" (Common for mature products optimizing operations)

Or describe your specific desired outcome (be measurable: e.g., "Increase trial-to-paid conversion from 15% to 25%").

User response: [Selection or custom]

Agent extracts and confirms:

  • Desired Outcome: [Specific, measurable outcome]
  • Why it matters: [Rationale from stakeholder request or context]

Question 2: Identify Opportunities (Problems to Solve)

Agent generates 3 opportunities based on the desired outcome and context provided.

Agent says: "Based on your desired outcome ([from Q1]) and the context you provided, here are 3 opportunities (customer problems or needs) that could drive this outcome:"

Example (if Outcome = Increase trial-to-paid conversion):

  1. Opportunity 1: Users don't experience value during trial — "New users sign up but don't complete onboarding, never reach 'aha moment,' abandon before seeing core value"

    • Evidence: [From context: onboarding analytics, support tickets, exit surveys]
  2. Opportunity 2: Pricing is unclear or misaligned — "Users unsure if paid plan is worth it; don't understand what they get for the price; pricing page confusing"

    • Evidence: [From context: conversion funnel drop-off at pricing page, sales objections]
  3. Opportunity 3: Free plan is 'good enough' — "Users stay on free tier indefinitely because it meets their needs; no compelling reason to upgrade"

    • Evidence: [From context: freemium user retention data, support tickets asking for workarounds]

Agent asks: "Which opportunity feels most critical to explore first, or would you like to modify/add opportunities?"

User response: [Selection or custom]


Question 3: Generate Solutions for Selected Opportunity

Agent generates 3 solution ideas for the selected opportunity.

Agent says: "For Opportunity [X]: [Name], here are 3 potential solutions to test:"

Example (if Opportunity 1 selected: Users don't experience value during trial):

  1. Solution 1: Guided onboarding checklist — "Interactive checklist that walks users through core workflows step-by-step (e.g., 'Create your first project,' 'Invite a teammate,' 'Complete a task')"

    • Hypothesis: Structured guidance increases completion rate
    • Experiment: A/B test checklist vs. no checklist, measure activation rate
  2. Solution 2: Time-to-value triggers — "Automatically prompt users when they're stuck (e.g., 'You haven't created a project yet—here's a template to get started')"

    • Hypothesis: Proactive nudges prevent drop-off
    • Experiment: Track engagement with prompts, measure trial-to-paid lift
  3. Solution 3: Human-assisted onboarding — "Offer 15-min onboarding call with CSM for high-value trial users (enterprise, team plans)"

    • Hypothesis: Personal touch increases conversion for high-intent users
    • Experiment: Offer to 50 trial users, measure conversion vs. control group

Agent asks: "Would you like to explore solutions for another opportunity, or move to POC selection?"

User response: [Selection or custom]


Phase 2: Select Proof-of-Concept (POC)

After generating solutions, the agent helps select which solution to test first.


Question 4: Evaluate Solutions (Feasibility, Impact, Market Fit)

Agent says: "Let's evaluate your solutions to pick the best starting point. I'll score each solution on Feasibility (how hard to build), Impact (how much it could move the outcome), and Market Fit (how well it aligns with customer needs)."

Agent generates evaluation table:

Solution Feasibility (1-5) Impact (1-5) Market Fit (1-5) Total Score Rationale
Solution 1: Guided onboarding checklist 4 4 5 13 High feasibility (UI pattern), proven impact (industry standard), strong market fit (users expect onboarding)
Solution 2: Time-to-value triggers 3 3 4 10 Medium feasibility (requires analytics integration), moderate impact (depends on trigger quality), good market fit
Solution 3: Human-assisted onboarding 5 5 3 13 High feasibility (no dev work), high impact (personal touch), lower market fit (doesn't scale, high-touch only)

Scoring criteria:

  • Feasibility: 1 = months of work, 5 = days/weeks
  • Impact: 1 = minimal outcome movement, 5 = major outcome shift
  • Market Fit: 1 = customers don't care, 5 = customers actively request this

Agent recommends:

Recommended POC: Solution 1 (Guided onboarding checklist)

Why this POC:

  • Balances feasibility (can build in 2-4 weeks) with impact (proven pattern)
  • Strong market fit (users expect onboarding guidance)
  • Testable hypothesis: "If we guide users through core workflows, activation rate will increase from X% to Y%"

Alternative POC: Solution 3 (Human-assisted onboarding)

  • If you want to learn fast with no dev work, start here
  • Test manually with 20-50 trial users, gather qualitative feedback
  • Use learnings to inform automated solution (Solution 1)

Not recommended for POC: Solution 2 (Time-to-value triggers)

  • Requires more upfront investment
  • Impact depends on trigger quality (needs experimentation to get right)
  • Better as follow-up after validating core onboarding flow

Question 5: Define Experiment

Agent asks: "How will you test this solution? What's the experiment?"

Offer 3 enumerated options:

  1. A/B test — "Build MVP, show to 50% of trial users, compare conversion vs. control" (Best for: Quantitative validation, requires traffic)
  2. Prototype + usability test — "Create clickable prototype, watch 10 users attempt onboarding, gather qualitative feedback" (Best for: Early-stage validation, low traffic)
  3. Manual concierge test — "Run the solution manually with 20 users (e.g., personally walk them through onboarding), measure outcomes" (Best for: Learning fast, no dev work)

Or describe your experiment approach.

User response: [Selection or custom]


Output: Opportunity Solution Tree + POC Plan

After completing the flow, the agent outputs:

# Opportunity Solution Tree + POC Plan

## Desired Outcome
**Outcome:** [From Q1]
**Target Metric:** [Specific, measurable goal]
**Why it matters:** [Rationale]

---

## Opportunity Map

### Opportunity 1: [Name]
**Problem:** [Description]
**Evidence:** [From context]

**Solutions:**
1. [Solution A]
2. [Solution B]
3. [Solution C]

---

### Opportunity 2: [Name]
**Problem:** [Description]
**Evidence:** [From context]

**Solutions:**
1. [Solution A]
2. [Solution B]
3. [Solution C]

---

### Opportunity 3: [Name]
**Problem:** [Description]
**Evidence:** [From context]

**Solutions:**
1. [Solution A]
2. [Solution B]
3. [Solution C]

---

## Selected POC

**Opportunity:** [Selected opportunity]
**Solution:** [Selected solution]

**Hypothesis:**
- "If we [implement solution], then [outcome metric] will [increase/decrease] from [X] to [Y] because [rationale]."

**Experiment:**
- **Type:** [A/B test / Prototype test / Concierge test]
- **Participants:** [Number of users, segment]
- **Duration:** [Timeline]
- **Success criteria:** [What validates the hypothesis]

**Feasibility Score:** [1-5]
**Impact Score:** [1-5]
**Market Fit Score:** [1-5]
**Total:** [Sum]

**Why this POC:**
- [Rationale 1]
- [Rationale 2]
- [Rationale 3]

---

## Next Steps

1. **Build experiment:** [Specific action, e.g., "Create onboarding checklist wireframes"]
2. **Run experiment:** [Specific action, e.g., "Deploy to 50% of trial users for 2 weeks"]
3. **Measure results:** [Specific metric, e.g., "Compare activation rate: checklist vs. control"]
4. **Decide:** [If successful → scale; if failed → try next solution]

---

**Ready to build the experiment? Let me know if you'd like to refine the hypothesis or explore alternative solutions.**

Examples

See examples/sample.md for full OST examples.

Mini example excerpt:

**Desired Outcome:** Increase trial-to-paid conversion from 15% to 25%
**Opportunity:** Users don’t reach "aha" moment during trial
**Solution:** Guided onboarding checklist

Common Pitfalls

Pitfall 1: Opportunities Disguised as Solutions

Symptom: "Opportunity: We need a mobile app"

Consequence: You've already converged on a solution without exploring the problem.

Fix: Reframe opportunities as customer problems: "Mobile-first users can't access product on the go."


Pitfall 2: Skipping Divergence (Jumping to One Solution)

Symptom: "We know the solution is [X], just need to build it"

Consequence: Miss better alternatives, no learning.

Fix: Generate at least 3 solutions per opportunity. Force divergence before convergence.


Pitfall 3: Outcome is Too Vague

Symptom: "Desired Outcome: Improve user experience"

Consequence: Can't measure success, can't prioritize opportunities.

Fix: Make outcomes measurable: "Increase NPS from 30 to 50" or "Reduce onboarding drop-off from 60% to 40%."


Pitfall 4: No Experiments (Just Build It)

Symptom: Picking a solution and moving straight to roadmap

Consequence: No validation, high risk of building wrong thing.

Fix: Every solution must map to an experiment. No experiments = no OST.


Pitfall 5: Analysis Paralysis (Exploring Forever)

Symptom: Generating 20 opportunities, 50 solutions, never picking one

Consequence: Team stuck in discovery, no progress.

Fix: Limit to 3 opportunities, 3 solutions each (9 total). Pick POC, run experiment, learn, iterate.


References

Related Skills

  • skills/problem-statement/SKILL.md — Frames opportunities as customer problems
  • skills/jobs-to-be-done/SKILL.md — Helps identify opportunities from JTBD research
  • skills/epic-hypothesis/SKILL.md — Turns validated solutions into testable epics
  • skills/user-story/SKILL.md — Breaks experiments into deliverable stories
  • skills/discovery-interview-prep/SKILL.md — Validates opportunities through customer interviews

External Frameworks

  • Teresa Torres, Continuous Discovery Habits (2021) — Origin of Opportunity Solution Tree
  • Jeff Patton, User Story Mapping (2014) — Outcome-driven product planning
  • Ash Maurya, Running Lean (2012) — Hypothesis-driven experimentation

Dean's Work

  • Productside Blueprint — Strategic product discovery process
  • [If Dean has OST resources, link here]

Skill type: Interactive Suggested filename: opportunity-solution-tree.md Suggested placement: /skills/interactive/ Dependencies: Uses skills/problem-statement/SKILL.md, skills/jobs-to-be-done/SKILL.md, skills/epic-hypothesis/SKILL.md, skills/user-story/SKILL.md

基于麦肯锡增长金字塔,帮助产品经理快速诊断增长瓶颈位置,通过两问三测将情况映射至增长路径矩阵,推荐单一增长方向及首个实验假设,适用于增长停滞或需快速决策场景。
增长停滞且不确定下一步策略 多个增长路径可行需选择其一 团队对增长方向存在争议需快速决断
skills/organic-growth-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill organic-growth-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "organic-growth-advisor",
    "type": "interactive",
    "intent": "Guide product managers through a fast triage to identify which of four organic growth paths fits their current constraint: new customer segments (L2), new geographies (L3), new distribution channels (L4), or new products or services (L5). Uses a 2x2 diagnostic based on customer\/market context familiarity and degree of product change required. Outputs a growth path recommendation with rationale and immediate next steps.",
    "best_for": [
        "Choosing which organic growth motion to pursue when multiple seem viable",
        "Diagnosing whether the constraint is in reach, access, market context, or product value",
        "Setting up an AI-assisted growth experiment with the right starting hypothesis"
    ],
    "scenarios": [
        "We need to grow but aren't sure if we should go after new customer segments or new geographies",
        "Help me figure out which McKinsey growth level we should focus on",
        "We have strong product-market fit but growth is stalling. Where should we look?",
        "Which organic growth path fits our current situation?"
    ],
    "description": "Identify which organic growth path to pursue — new segments, geographies, channels, or products. Use when diagnosing where a growth constraint lives and which McKinsey growth level to act on next.",
    "argument-hint": "[product and growth context]"
}

Purpose

Help product managers identify which organic growth path to pursue by diagnosing where the constraint actually lives. This is not a comprehensive strategy tool. It is a fast triage that puts you in the right lane before you start building hypotheses or running experiments.

The four growth paths covered here are drawn from the McKinsey Growth Pyramid (Levels 2 through 5). Levels 1, 6, and 7 are out of scope: Level 1 (existing products to existing customers) is a retention and optimization problem, not a growth motion. Levels 6 and 7 (new industry structure, new arenas) require capital and executive mandate beyond typical product team scope.

This skill does three things and nothing more:

  1. Diagnoses where your growth constraint lives using two questions
  2. Places your situation on the Growth Path Matrix (customer/market context vs. degree of product change)
  3. Recommends one growth path with rationale, a diagnostic question, and a first experiment

Anti-Patterns (What This Is NOT)

  • Not a rigorous diagnostic instrument: A fast triage tool, not a scoring model
  • Not a maturity model or rubric: No stages, no grades, no weighted criteria
  • Not a substitute for customer discovery: It points you in a direction; discovery validates it
  • Not a guarantee: If the recommendation does not feel right, that tension is worth exploring

When to Use This Skill

  • Growth is stalling and you are unsure which lever to pull next
  • Multiple growth paths seem viable and you need to choose one to test first
  • You want to set up an AI-assisted experiment with a clear hypothesis
  • A team or stakeholder debate about growth direction needs a fast resolution

When NOT to Use This Skill

  • You have not yet achieved core product-market fit (fix L1 first)
  • You already have a validated growth path in motion (do not switch lanes mid-experiment)
  • You need a rigorous strategic planning tool (this is triage, not strategy)
  • You lack basic context about your current customers and their problems (gather that first)

Input

Works best with: Your product and where growth feels stuck, in a sentence or two. Also useful: Which customers/markets you serve today, what you've already tried, and any paths leadership is pushing (new segments, geos, channels, products).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens with Q1 of the 3-question triage to place you on the Growth Path Matrix.

Example invocation: Growth triage: B2B payroll tool, strong in US mid-market, plateaued — CEO wants Europe, sales wants an SMB tier.

Key Concepts

The Growth Path Matrix

Two questions place your situation on the matrix:

X axis: Customer/Market Context How familiar is the next customer or market you want to reach?

  • Known: Same market, same type of buyer, familiar problem context
  • Less Known: Different geography, unfamiliar cultural or regulatory context, buyer type you have not served before

Y axis: Degree of Product Change How much does the product itself need to change to unlock the next wave of growth?

  • Low: The product mostly works. What needs to change is how customers find or access it, or which customer you go after next.
  • High: The product needs to evolve. New capabilities or an entirely new product line is required to solve the next job.

The Four Growth Paths

L2: New Customer Segments (Known context + Low product change) You already solve a real problem. A nearby buyer may need it too.

L4: New Distribution Channels (Known context + High product change) Product offers same value. People need a better way to find or access it.

L3: New Geographies (Less Known context + Low product change) The product may travel. The market context does not come with it automatically.

L5: New Products or Services (Less Known context + High product change) Customers are pulling you toward adjacent jobs your offer does not fully solve.

Why This Order Matters

Risk scales with distance from your core. L2 is closest: same market, same product. L5 is furthest: new product, less familiar context. Most teams overinvest in L5 before they have exhausted L2 and L4. If your core product-market fit is strong and your current market is not saturated, L2 or L4 is almost always the right move first.

The Knowledge Principle

Innovation at any level is downstream of accumulated contextual knowledge. The teams that succeed at L3 are not the ones who moved fastest. They are the ones who studied how value actually travels in the new market before they tried to scale it. The teams that succeed at L5 are not the most creative. They built the adjacent product their existing customers were already asking for, in language they already understood.


Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Q1/3 and Recommendation)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.


Application

This interactive skill asks 3 adaptive questions, offering 3 enumerated options at each diagnostic step.


Question 1: Current Situation

Agent asks:

"Let's identify your best organic growth path. To start:

  • What does your product do, and who is your current core customer?
  • Where is growth stalling right now?
  • What have you already tried?"

Accept a brief answer. Two to four sentences is enough. The goal is to establish baseline context before asking the diagnostic questions.


Question 2: Customer/Market Context

Agent asks:

"Think about the next customer or market you want to reach: the one who would unlock your next wave of growth.

How familiar is that context to you?"

Offer 3 enumerated options:

  1. Well known — Same market, same type of buyer, familiar problem and context. You have served customers like this before.
  2. Somewhat known — Adjacent buyer or market. You have a hypothesis about who they are, but limited direct experience with them.
  3. Less known — New geography, new industry, new buyer profile. Their context, norms, and decision-making process are meaningfully different from what you know.

Question 3: Degree of Product Change

Agent asks:

"To reach that customer and grow, how much does your product need to change?

What does the constraint actually require?"

Offer 3 enumerated options:

  1. Low change — The product mostly works for this next customer. What needs to change is how they find it, access it, or how you reach them.
  2. High change — The product does not fully solve what this customer needs. New capabilities or a new product line is required.
  3. Somewhere in between — Describe what feels more pressing. That will determine the path.

Output: Growth Path Recommendation

After three questions, the agent delivers a recommendation using the pattern below.


Recommendation Pattern

## Your Growth Path: [L2 / L3 / L4 / L5] — [Name]

**Where you sit on the matrix:**
- Customer/market context: [Known / Less Known]
- Degree of product change: [Low / High]

**Why this path fits your situation:**
[2 to 3 sentences connecting their specific context to the growth path. Be direct. Reference what they told you.]

**The diagnostic question to keep asking:**
[One sharp question: the one that will tell them if they are right about this path]

**What innovation looks like here:**
[Concrete description of what real innovation looks like at this level. Not a feature list, but a pattern.]

**A first experiment to run this week:**
[One specific, low-cost action they can take in the next 5 to 7 days to test whether this path is real]

**Watch out for:**
[One trap that kills teams pursuing this path: the most common mistake at this level]

Path-Specific Guidance

L2: New Customer Segments

Diagnostic question: Who else has the problem we already solve?

What innovation looks like: Finding adjacent buyers inside your existing market whose context is similar enough that your current product mostly works for them. Not rebuilding value. Improving how you reach, message, and onboard a slightly different buyer.

First experiment: Identify three companies or individuals who match a buyer profile adjacent to your ICP. Reach out directly. Ask them to describe their version of the problem you solve. Do not pitch. Listen for what is the same and what is different.

Watch out for: Assuming adjacent buyers need the same onboarding and messaging as your core ICP. They are close enough to reach, but different enough to misunderstand. Word of mouth travels within segments, not across them.


L4: New Distribution Channels

Diagnostic question: Where else could customers discover or access our value?

What innovation looks like: Turning product output into a distribution surface. Placing the product where buyers already spend time. Creating a free tier or embedded entry point that removes the signup barrier. The product does not change. The front door does.

First experiment: Identify one place where your product output is already being shared or seen by non-users. Map what a non-user sees when they encounter it. Ask whether that moment creates curiosity or stops there. Design one change to that moment that makes curiosity easier to act on.

Watch out for: Confusing marketing campaigns with distribution innovation. A campaign gets attention once. A distribution channel compounds. The test is whether the mechanism works without ongoing spend behind it.


L3: New Geographies

Diagnostic question: Where is demand already showing up that we do not yet serve well?

What innovation looks like: Studying how word of mouth actually travels in the target market before scaling anything. Building local trust signals: content, partners, language. Doing that before investing in paid growth. Pacing expansion to match local product-market fit signals, not a global launch calendar.

First experiment: Look at your current inbound data. Is there organic traffic, signups, or inquiries from a market you have not targeted? If yes, reach out to three of those users and ask why they found you and what they were hoping to get. That is your signal.

Watch out for: Assuming what worked at home works everywhere. Trust is built differently across markets. The product may translate. The growth loop almost never does without adaptation.


L5: New Products or Services

Diagnostic question: What adjacent jobs are customers already trying to solve around us?

What innovation looks like: Building something new that extends the core workflow customers already live in. Not a pivot, but an expansion. The new product retains existing customers by absorbing more of their workflow and attracts new buyers who need that job done.

First experiment: Ask five current customers what they do immediately before or after using your product to complete the job it helps with. Look for a consistent adjacent step they take with a different tool or manual process. That gap is your L5 hypothesis.

Watch out for: Building new before the core is strong. L5 requires more knowledge, more resources, and more risk than any other path. If you have not saturated L2 and L4 first, you are probably moving too early.


Examples

Example 1: L2 Recommendation

Context: B2B SaaS project management tool. Core ICP is engineering teams. Growth has slowed. They have tried paid ads and a PLG free tier. Both underperforming.

Q2 response: Well known — same buyer type, familiar context.

Q3 response: Low change — the product mostly works, the constraint is reach.

Recommendation: L2 — New Customer Segments

The product solves a coordination problem engineering teams have. Design and product teams inside the same companies have a nearly identical coordination problem. Word of mouth from engineering is already warm. It just stops at the team boundary. The growth path is not a new channel. It is a new segment inside the same market.

First experiment: Pull a list of your best engineering team customers. Identify which ones also have active design or product teams. Reach out to those adjacent teams directly with a message that references the engineering team's usage. Ask what their coordination problem looks like.


Example 2: L4 Recommendation

Context: SaaS tool for creating short-form video explainers. Strong product-market fit with marketing teams. Growth plateau after initial viral push faded.

Q2 response: Well known — same buyer type, familiar context.

Q3 response: Low change — the product works, the front door is the problem.

Recommendation: L4 — New Distribution Channels

Every video created is a distribution surface. Non-users see finished videos but have no low-friction path to act on their curiosity. The growth constraint is not that the product lacks value. It is that the moment of maximum curiosity (watching a video) has no conversion mechanism attached to it.

First experiment: Add a subtle "Made with [Product]" watermark or link to the bottom of every exported video. Track whether inbound signups increase from referral source. If yes, the output is already a channel. Design the next step from there.


Example 3: L3 Recommendation

Context: HR software built for US mid-market companies. Starting to see inbound from UK and Australia. No localization done yet.

Q2 response: Less known — different regulatory and hiring norms.

Q3 response: Low change — the core product mostly works, local context adaptation is needed.

Recommendation: L3 — New Geographies

Organic inbound from the UK and Australia is a signal, not a coincidence. Moving directly to paid expansion without understanding local context is a common mistake. UK hiring law, data residency requirements, and HR norms differ enough to create friction at the point of sale and in onboarding, not in the product itself.

First experiment: Talk to the five most active UK or Australian users you already have. Ask what friction they hit when signing up and getting started. Ask what the product does not understand about their context. That conversation maps the localization investment before you make it.


Example 4: L5 Recommendation

Context: B2B analytics tool for e-commerce teams. Strong retention, high NPS. Customers keep asking for forecasting and inventory planning features the product does not currently offer.

Q2 response: Somewhat known — same buyer type, but the adjacent job pulls toward a different workflow.

Q3 response: High change — the product does not yet solve what customers are pulling toward.

Recommendation: L5 — New Products or Services

Customers are not just asking for more reports. They are asking you to absorb a workflow step that currently lives in a separate tool. That is an L5 signal. The adjacent job (forecasting and planning) is close enough to your core that building it extends retention and opens a new buyer without requiring a new go-to-market motion.

First experiment: Interview eight current customers who have requested forecasting features. Ask them to walk you through exactly what they do today to handle that job. What tools do they use? Where does it break down? What would good enough look like? You are not scoping the feature. You are validating that the job is real and consistent enough to build toward.


Common Pitfalls

Pitfall 1: Pursuing L5 before L2 and L4 are exhausted

Symptom: The team is excited about building something new while existing market penetration is still below 30%.

Consequence: L5 requires the most knowledge, the most capital, and the most time. Starting there before the core is strong usually produces a distraction, not a second product.

Fix: Ask honestly whether you have fully exploited L2 and L4 before committing to L5. If not, start there.


Pitfall 2: Confusing a marketing campaign with a distribution channel

Symptom: "We launched on Product Hunt and got 2,000 signups" counted as a distribution channel win.

Consequence: Campaigns generate attention once. Channels compound without ongoing spend. If the mechanism stops working when you stop paying or promoting, it is not a channel.

Fix: Test whether the distribution mechanism works without active investment. If yes, it is a channel. If not, it is a campaign.


Pitfall 3: Expanding geographically before local word of mouth is understood

Symptom: Team translates the website, runs paid ads in the new market, and wonders why conversion is poor.

Consequence: Paid spend in a market where you have no local trust signals burns budget and produces low-quality leads.

Fix: Find organic inbound from the target market first. Talk to those users before spending anything. Understand how trust travels locally before trying to manufacture it.


Pitfall 4: Treating adjacent segments as identical to the core ICP

Symptom: "They have the same problem, so the same messaging should work."

Consequence: Adjacent buyers are close enough to reach but different enough to misunderstand. They share the problem but not always the language, urgency, or buying process.

Fix: Run discovery with the new segment before assuming your existing onboarding and messaging transfers. Small differences in framing compound into large differences in conversion.


Pitfall 5: Using this matrix as a precision instrument

Symptom: Team debates which quadrant they belong in for two hours.

Consequence: The matrix is a triage tool. Spending more time on placement than on experiments defeats the purpose.

Fix: Make a best-guess placement in five minutes. Use the first experiment to validate or invalidate. The matrix points you in a direction. It does not make the decision for you.


References

Related Skills

  • acquisition-channel-advisor — Evaluate unit economics for a specific distribution channel once L4 path is chosen
  • discovery-interview-prep — Prepare discovery interviews for new segment or geography validation
  • pol-probe — Define a Proof of Life experiment for the recommended growth path
  • epic-hypothesis — Frame the growth initiative as a testable hypothesis before roadmap commitment
  • jobs-to-be-done — Identify adjacent jobs for L5 hypothesis development

Framework Source

  • McKinsey Growth Pyramid (Baghai, Coley, White — "The Alchemy of Growth," 1999)
  • Levels 2 through 5 only. L1 is retention. L6 and L7 are out of scope for product team execution.

Provenance

  • Developed for Productside webinar: "Driving Organic Growth through Innovation" (May 20, 2026)
  • Growth Path Matrix axes: Customer/Market Context (Known to Less Known) and Degree of Product Change (Low to High)
用于系统分析政治、经济、社会、技术、环境和法律等宏观外部因素,识别产品或战略面临的机会与威胁。适用于市场进入评估、战略规划及风险研判,聚焦外部环境而非内部或竞争分析。
进入新市场或地理区域 制定年度或3-5年战略规划 评估新产品在变化环境中的可行性 进行新产品发起的风险评估 向高管或投资者展示对环境因素的认知
skills/pestel-analysis/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill pestel-analysis -g -y
SKILL.md
Frontmatter
{
    "name": "pestel-analysis",
    "type": "component",
    "intent": "Conduct a systematic analysis of macro-environmental factors—Political, Economic, Social, Technological, Environmental, and Legal—that could impact your product or project. Use this to identify external opportunities and threats, inform strategic planning, assess market entry risks, and make data-driven decisions about product direction in the context of broader forces beyond your control.",
    "description": "Analyze political, economic, social, technological, environmental, and legal forces. Use when external market shifts could materially affect a product, roadmap, or strategy.",
    "argument-hint": "[product or market]"
}

Purpose

Conduct a systematic analysis of macro-environmental factors—Political, Economic, Social, Technological, Environmental, and Legal—that could impact your product or project. Use this to identify external opportunities and threats, inform strategic planning, assess market entry risks, and make data-driven decisions about product direction in the context of broader forces beyond your control.

This is not internal analysis—it's outward-facing assessment of the big-picture forces shaping your product's environment.

Input

Works best with: The product, market, or strategic decision the analysis should serve. Also useful: Geography, time horizon, and which forces you already suspect matter most.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks what product/market and geography to analyze before scanning the six forces — an unanchored PESTEL is a trivia exercise.

Example invocation: PESTEL for launching our telehealth platform in Germany over the next 18 months.

Key Concepts

The PESTEL Framework

Originating from Francis Joseph Aguilar's 1967 PEST analysis, PESTEL extends the framework to six categories:

  1. Political: Government policies, stability, trade regulations, taxation
  2. Economic: Growth rates, inflation, exchange rates, consumer spending
  3. Social: Demographics, cultural trends, lifestyle changes, consumer attitudes
  4. Technological: Advancements, R&D, automation, digital transformation
  5. Environmental: Climate change, sustainability, resource scarcity, regulations
  6. Legal: Compliance, IP rights, employment laws, health/safety regulations

Why This Works

  • Comprehensive: Covers all major external forces affecting your product
  • Proactive: Identifies threats and opportunities before they become critical
  • Strategic: Informs long-term planning, not just tactical decisions
  • Risk management: Highlights vulnerabilities in your product strategy

Anti-Patterns (What This Is NOT)

  • Not competitive analysis: PESTEL looks at macro factors, not competitors
  • Not internal analysis: Focuses on external environment, not your company's strengths/weaknesses
  • Not static: Macro environment changes—reassess regularly

When to Use This

  • Entering a new market or geography
  • Strategic planning (annual roadmapping, 3-5 year planning)
  • Assessing product viability in a changing environment
  • Risk assessment for new product initiatives
  • Pitching to execs or investors (shows environmental awareness)

When NOT to Use This

  • For tactical, short-term decisions (use competitive analysis instead)
  • When external factors are stable and well-understood
  • As a substitute for customer research (PESTEL is macro, not micro)

Application

Use template.md for the full fill-in structure.

Step 1: Define the Scope

Clarify what you're analyzing:

## Overview

- **Project/Product Name:** [e.g., "AI-Powered Invoice Automation for SMBs"]
- **Analysis Purpose:** [e.g., "Assess viability of launching in EU market"]
- **Analyst:** [Your name or team]
- **Date:** [Date of analysis]
- **Geographic Scope:** [e.g., "United States and European Union"]
- **Time Horizon:** [e.g., "Next 12-24 months"]

Quality checks:

  • Specific: Not "analyze market" but "assess viability of EU launch"
  • Time-bound: PESTEL factors change—state your horizon

Step 2: Analyze Political Factors

Examine government and regulatory influences:

## 1. Political Factors

### Government Policies
- [How could government policies impact the product?]
- [Example: "EU's AI Act requires transparency in AI decision-making; our invoice automation must explain recommendations"]

### Political Stability
- [Assess stability in relevant regions]
- [Example: "US political stability is moderate; potential for regulatory changes in financial tech under new administration"]

### Trade Regulations
- [Examine trade regulations and their effects]
- [Example: "Brexit complicates data transfer between UK and EU; may require separate infrastructure"]

### Taxation Policy
- [Analyze taxation policies and implications]
- [Example: "Digital services tax in EU (3% on revenue) could impact pricing strategy"]

Quality checks:

  • Specific to your product: Don't list generic policies—explain the impact
  • Actionable: Can you adjust strategy based on this insight?

Step 3: Analyze Economic Factors

Examine economic conditions:

## 2. Economic Factors

### Economic Growth
- [Evaluate growth rates and their impact]
- [Example: "SMB sector growing 5% annually in US; strong demand for automation tools"]

### Inflation Rate
- [Consider inflation and its effect on pricing/costs]
- [Example: "High inflation (6%) pressures SMB budgets; price sensitivity increases"]

### Exchange Rates
- [Analyze exchange rate fluctuations]
- [Example: "Weak Euro vs. Dollar makes US pricing less competitive in EU; may need regional pricing"]

### Consumer Spending
- [Assess consumer spending levels]
- [Example: "SMBs cutting discretionary spending due to recession fears; emphasize ROI (time savings) in messaging"]

Quality checks:

  • Data-driven: Use real economic indicators (GDP growth, inflation rates, etc.)
  • Product-specific: How do these trends affect your product?

Step 4: Analyze Social Factors

Examine societal and cultural trends:

## 3. Social Factors

### Demographics
- [Examine demographics and market influence]
- [Example: "Aging SMB owners (Baby Boomers) less tech-savvy; younger Gen X/Millennial owners more receptive to automation"]

### Cultural Trends
- [Analyze cultural trends and demand impact]
- [Example: "Growing 'hustle culture' among freelancers increases demand for time-saving tools"]

### Lifestyle Changes
- [Consider lifestyle changes and implications]
- [Example: "Remote work boom increases solo entrepreneurs and freelancers; core target market expanding"]

### Consumer Attitudes
- [Assess consumer attitudes and behaviors]
- [Example: "Increasing trust in AI for routine tasks (invoicing, scheduling); less resistance than 5 years ago"]

Quality checks:

  • Trend-based: Reference actual cultural shifts, not assumptions
  • Validated: Use survey data, research reports, or demographic studies

Step 5: Analyze Technological Factors

Examine technology landscape:

## 4. Technological Factors

### Technological Advancements
- [Identify advancements and their impact]
- [Example: "Large language models (LLMs) enable better invoice data extraction; competitive advantage if adopted early"]

### R&D Activity
- [Evaluate sector R&D levels]
- [Example: "High R&D investment in fintech automation; rapid innovation cycle—need to iterate fast"]

### Automation
- [Assess automation implications]
- [Example: "Competitors adopting AI-powered automation; table stakes for market entry—must match or exceed"]

### Digital Transformation
- [Consider digital transformation trends]
- [Example: "SMBs adopting cloud-first tools (QuickBooks Online, Xero); need strong integrations to succeed"]

Quality checks:

  • Competitive context: How does the tech landscape affect your position?
  • Actionable: What R&D or partnerships do you need?

Step 6: Analyze Environmental Factors

Examine environmental and sustainability issues:

## 5. Environmental Factors

### Climate Change
- [Analyze climate change implications]
- [Example: "Minimal direct impact; however, B Corps and sustainability-focused SMBs prefer vendors with carbon-neutral operations"]

### Sustainability Practices
- [Evaluate sustainability impact]
- [Example: "Growing demand for 'green tech'; marketing opportunity to highlight cloud efficiency vs. on-prem servers"]

### Resource Scarcity
- [Assess resource scarcity risks]
- [Example: "Low risk; software product doesn't depend on physical resources"]

### Environmental Regulations
- [Examine environmental regulations]
- [Example: "EU's Carbon Border Adjustment Mechanism (CBAM) doesn't affect SaaS directly"]

Quality checks:

  • Honest assessment: If impact is minimal, say so (don't force relevance)
  • Market positioning: Can environmental factors be a differentiator?

Step 7: Analyze Legal Factors

Examine legal and compliance landscape:

## 6. Legal Factors

### Compliance Requirements
- [Identify legal/compliance requirements]
- [Example: "GDPR compliance required for EU customers; must implement data residency, right-to-be-forgotten, consent management"]

### Intellectual Property Rights
- [Evaluate IP importance and protection]
- [Example: "Patent landscape for AI invoice processing is crowded; focus on trade secrets over patents"]

### Employment Laws
- [Consider employment laws and implications]
- [Example: "Remote hiring across EU requires understanding of local labor laws (Germany, France have strict employment contracts)"]

### Health and Safety Regulations
- [Assess health/safety regulations]
- [Example: "Not applicable (software product)"]

Quality checks:

  • Legal risk assessment: What could block or delay your product?
  • Compliance costs: Budget for legal, data residency, certifications?

Step 8: Synthesize Insights

After analyzing all six factors, summarize:

## Strategic Insights Summary

### Top Opportunities:
1. **[Opportunity 1]** - [Description and action]
   - [Example: "Social: Remote work boom expands target market → Increase marketing to freelancers"]
2. **[Opportunity 2]** - [Description and action]
3. **[Opportunity 3]** - [Description and action]

### Top Threats:
1. **[Threat 1]** - [Description and mitigation]
   - [Example: "Economic: Recession fears increase price sensitivity → Emphasize ROI in messaging, offer lower-tier pricing"]
2. **[Threat 2]** - [Description and mitigation]
3. **[Threat 3]** - [Description and mitigation]

### Strategic Recommendations:
1. **[Recommendation 1]** - [Action to take]
2. **[Recommendation 2]** - [Action to take]
3. **[Recommendation 3]** - [Action to take]

Step 9: Update Regularly

  • Annual review: Reassess PESTEL factors during strategic planning
  • Trigger events: Update when major external events occur (new regulations, economic shifts, etc.)
  • Track changes: Document how factors evolve over time

Examples

See examples/sample.md for a full PESTEL analysis example.

Mini example excerpt:

### 1. Political Factors
- EU AI Act requires transparency in AI decision-making

### 2. Economic Factors
- High inflation increases SMB price sensitivity

Common Pitfalls

Pitfall 1: Generic Analysis

Symptom: "Political: Regulations exist. Economic: Economy affects spending."

Consequence: No actionable insights.

Fix: Be specific: "EU AI Act requires explainable AI → Need transparency features by Q3 2026."


Pitfall 2: Ignoring Low-Impact Factors

Symptom: Forcing relevance where none exists (e.g., "Climate change affects our SaaS product...")

Consequence: Wastes time, dilutes focus.

Fix: If a factor has low impact, say so. Focus effort on high-impact areas.


Pitfall 3: No Data Sources

Symptom: "Economic growth is strong" (no citation)

Consequence: Unverifiable claims, low credibility.

Fix: Cite sources: "SMB sector growing 5% annually (US Census Bureau, 2025)."


Pitfall 4: Analysis Without Action

Symptom: Long list of factors, no strategic recommendations

Consequence: Insights don't inform decisions.

Fix: Synthesize into "Top Opportunities," "Top Threats," and "Strategic Recommendations."


Pitfall 5: One-Time Exercise

Symptom: PESTEL analysis done once, never revisited

Consequence: Stale insights as macro environment shifts.

Fix: Review annually or when major external events occur (new regulations, economic shifts, etc.).


References

Related Skills

  • skills/recommendation-canvas/SKILL.md — PESTEL factors inform risk assessment in canvas
  • skills/positioning-statement/SKILL.md — PESTEL insights shape competitive positioning
  • skills/problem-statement/SKILL.md — Social/economic factors influence customer problems

External Frameworks

  • Francis Joseph Aguilar, Scanning the Business Environment (1967) — Origin of PEST analysis
  • PESTEL (extension of PEST to include Environmental and Legal)
  • Michael Porter, Competitive Strategy (1980) — Complements PESTEL with industry-level analysis

Dean's Work

  • PESTEL Analysis Prompt Template (adapted from Aguilar's framework)

Provenance

  • Adapted from prompts/pestel-analysis-prompt-template.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: pestel-analysis.md Suggested placement: /skills/components/ Dependencies: References skills/recommendation-canvas/SKILL.md, skills/positioning-statement/SKILL.md

通过引导式对话,将原始想法或内容转化为符合规范的 SKILL.md 草稿。适用于用户有初步概念需结构化设计技能时,辅助确定类型、范围及内容,生成可验证的草案。
需要将零散想法或原始内容转化为标准技能文档 希望借助交互式问答明确技能类型与结构
skills/pm-skill-creator/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill pm-skill-creator -g -y
SKILL.md
Frontmatter
{
    "name": "pm-skill-creator",
    "type": "interactive",
    "theme": "meta-authoring",
    "intent": "Walk through the full skill design process interactively — from raw idea or content to a structured, repo-compliant SKILL.md draft. Asks adaptive questions to determine skill type, scope, structure, and content, then generates a ready-to-validate draft.",
    "best_for": [
        "Turning a rough idea or framework into a structured PM skill",
        "Deciding whether raw content should be a component, interactive, or workflow skill",
        "Getting from blank page to a complete SKILL.md draft through guided conversation"
    ],
    "scenarios": [
        "I have notes from a workshop and want to turn them into a skill",
        "Help me create a new skill — I know the topic but not the structure",
        "I have a PM framework I want to formalize as a repo skill"
    ],
    "description": "Design a new PM skill through guided conversation. Use when you have raw content or an idea and want to shape it into a compliant skill.",
    "argument-hint": "[idea or raw content]",
    "estimated_time": "10-15 min"
}

Purpose

Walk through the full skill design process interactively — from raw idea or content to a structured, repo-compliant SKILL.md draft. Asks adaptive questions to determine skill type, scope, structure, and content, then generates a ready-to-validate draft.

This skill is the conversational complement to skill-authoring-workflow. That skill defines the process and validation gates. This one sits with you and figures out what to build before you build it.

Input

Bring the seed for the skill you want to design — half-formed is fine; shaping it is this skill's job:

  • Works best with: the idea, framework, or raw content (notes, prompt sequence, article) the skill should capture
  • Also useful: the skill type you suspect it is, who it's for, and any existing skills it should relate to

If you supply this inline with your request (e.g., "help me design a skill from my pricing-tiers framework"), the conversation uses that as the answer to Q1 and moves on — it won't re-ask. With no input, it opens by asking what you want the skill to help someone do.

Example: Use pm-skill-creator: I have a decision tree for choosing north-star metrics — help me shape it into a skill.

Key Concepts

When to Use This vs. Other Authoring Tools

Tool Best When
This skill (skill-creator) You have an idea or raw content and need help shaping it into the right structure through conversation
skill-authoring-workflow You already know what to build and need the process checklist and validation steps
scripts/build-a-skill.sh You know the structure and want a terminal wizard to collect sections
scripts/add-a-skill.sh You have a source document and want AI-assisted generation end-to-end

The Three Skill Types (Decision Criteria)

  • Component: One artifact or template. Self-contained. Gets referenced by other skills. Ask: "Is this a thing someone creates?"
  • Interactive: Guided conversation with adaptive questions and enumerated recommendations. Ask: "Does this require back-and-forth to be useful?"
  • Workflow: Multi-phase orchestration referencing other skills. Ask: "Does this coordinate multiple activities across steps?"

Skill Anatomy (Non-Negotiable Sections)

Every skill requires these sections in order:

  1. Purpose — What it does + when to use it (outcome-focused)
  2. Input — What the user can bring (subject, optional context), an example invocation, and the rule that inline input counts as answers already given. Must read as an invitation: zero input is fine, the guided flow covers it. Plain language only — no runtime template syntax like $ARGUMENTS
  3. Key Concepts — Frameworks, definitions, mental models
  4. Application — Step-by-step instructions an agent can follow
  5. Examples — At least one concrete, specific example
  6. Common Pitfalls — Named failure modes with consequences and fixes
  7. References — Related skills, external frameworks, source material

Metadata Constraints

  • name: lowercase kebab-case, ≤ 64 characters
  • description: ≤ 200 characters, must include trigger cue ("Use when...")
  • intent: longer repo-facing summary (no character limit)
  • type: one of component, interactive, workflow

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • Session heads-up + entry mode (Guided, Context dump, Best guess)
  • One-question turns with plain-language prompts
  • Progress labels (e.g., Context Q1/5)
  • Interruption handling and pause/resume behavior
  • Numbered recommendations at decision points
  • Quick-select numbered response options (include Other (specify) when useful)

This file defines the domain-specific content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 5 adaptive questions, then delivers a complete SKILL.md draft with frontmatter, all required sections, and repo-compliant structure.


Step 0: Session Start

Agent says:

"I'll help you design a new PM skill from scratch. This takes about 10-15 minutes and up to 5 questions. How do you want to start?

  1. Guided — I'll ask questions one at a time and build the skill from your answers (recommended)
  2. Context dump — Paste your raw content, notes, or framework and I'll propose a skill structure
  3. Best guess — Tell me just the topic and I'll draft a skill you can refine"

Question 1: What's the Raw Material? (Q1/5)

Agent asks:

"What are we turning into a skill? Give me whatever you have."

  1. A framework or mental model — A structured way of thinking about a PM problem (e.g., prioritization matrix, decision tree)
  2. A template or artifact — A deliverable PMs create (e.g., PRD section, positioning statement, epic format)
  3. A process or workflow — A multi-step method for completing a PM task (e.g., discovery sprint, roadmap planning)
  4. A coaching or advisory topic — A domain where PMs need guided, adaptive help (e.g., stakeholder navigation, pricing decisions)

Or describe what you have in your own words.

Agent note: If the user pastes raw content instead of choosing an option, analyze the content and infer the answer. Confirm your interpretation before proceeding.


Question 2: Skill Type Decision (Q2/5)

Based on Q1 answer, agent recommends a type and confirms:

If Q1 = Framework or Template:

"This sounds like a component skill — a self-contained artifact or reference. It would include a template, quality criteria, and examples. Does that fit, or is there a conversational/adaptive element I'm missing?

  1. Yes, component — It's a standalone deliverable or reference
  2. Actually, it needs conversation — Users need guided questions to use it well (→ interactive)
  3. It's bigger than one artifact — It orchestrates multiple steps or other skills (→ workflow)"

If Q1 = Process or Workflow:

"This sounds like a workflow skill — a multi-phase process. Does it reference or orchestrate other discrete skills/artifacts, or is it more of a guided conversation?

  1. Yes, workflow — It has distinct phases and may reference other skills
  2. It's more conversational — The value comes from adaptive questions and recommendations (→ interactive)
  3. It's simpler than I described — Really it's one artifact with steps (→ component)"

If Q1 = Coaching or Advisory:

"This sounds like an interactive skill — guided questions that adapt based on answers, ending with enumerated recommendations. Sound right?

  1. Yes, interactive — It needs back-and-forth to be useful
  2. It's more of a reference — Users just need the framework, not a conversation (→ component)
  3. It's a full process — Multiple phases, orchestrates other skills (→ workflow)"

Question 3: Scope and Naming (Q3/5)

Agent asks:

"What should we call this skill? I need two things:

a) A working name — lowercase-kebab-case, max 64 characters (e.g., feature-investment-advisor, user-story, discovery-process)

b) A one-sentence description — What it does + when to use it. Must fit in 200 characters and start with a verb or 'Use when...'

Give me your best attempt and I'll tighten it if needed. Or just describe the skill's purpose and I'll propose both."

Agent note: Validate the name format (kebab-case, ≤ 64 chars) and description length (≤ 200 chars) before proceeding. If either fails, suggest a fix.


Question 4: Key Content (Q4/5)

This question adapts based on skill type from Q2:

For component skills:

"What are the core elements of this artifact or framework? I need:

  1. The template or structure — What sections/fields does it contain?
  2. Quality criteria — What separates a good one from a bad one?
  3. One concrete example — A filled-in version showing it done well

Give me whatever you have — bullet points, rough notes, or a full draft."

For interactive skills:

"Walk me through the conversation flow:

  1. What's the opening question? — What does the user need to tell you first?
  2. What are the 2-4 branching paths? — How do answers change what comes next?
  3. What recommendations emerge? — What are the 3-5 outcomes you'd offer?

Give me the decision tree as you see it — even if it's rough."

For workflow skills:

"Map out the phases:

  1. What are the major steps? (Usually 3-6 phases)
  2. What's the input and output of each phase?
  3. Which existing skills does this reference? (Check with scripts/find-a-skill.sh --keyword <topic>)
  4. Where are the decision points?

Give me the flow — sequential, branching, or both."


Question 5: Pitfalls and Edge Cases (Q5/5)

Agent asks:

"What goes wrong when people do this badly? I need 2-3 failure modes:

  1. Name the failure — Give it a label (e.g., 'Metrics Theater', 'Hero Syndrome')
  2. Describe the consequence — What happens when someone falls into this trap?
  3. State the fix — What's the corrective action?

If you're not sure, tell me the most common mistake you've seen and I'll help structure it."


Draft Generation

After collecting answers to Q1-Q5, the agent generates a complete SKILL.md draft including:

  1. YAML frontmattername, description, intent, type, best_for, scenarios, estimated_time
  2. Purpose — Synthesized from Q1 + Q3
  3. Input — Derived from Q2/Q3: what the user provides, an example invocation, and the inline-input rule (use what's supplied, don't re-ask)
  4. Key Concepts — Structured from Q4 content
  5. Application — Step-by-step instructions derived from Q4
  6. Examples — Concrete example from Q4 (or generated if not provided)
  7. Common Pitfalls — Structured from Q5
  8. References — Related skills identified during conversation + source material

Agent says after generating:

"Here's your draft SKILL.md. Before we call it done:

  1. Review the draft — Does it capture your intent?
  2. Run validationpython3 scripts/check-skill-metadata.py skills/<name>/SKILL.md
  3. Check triggerspython3 scripts/check-skill-triggers.py skills/<name>/SKILL.md --show-cases
  4. Smoke test./scripts/test-a-skill.sh --skill <name> --smoke

Want me to adjust anything, or are you ready to validate?"

Examples

Example: Framework → Component Skill

Q1: "1 — A framework. It's a 2x2 matrix for evaluating build-vs-buy decisions." Q2: "1 — Yes, component." Q3: "Name: build-vs-buy-matrix. Description: 'Evaluate build-vs-buy decisions using a 2x2 matrix of strategic value and implementation complexity. Use when choosing between building internally and buying a solution.'" Q4: "The axes are strategic differentiation (low/high) and implementation complexity (low/high). Four quadrants: Buy (low/low), Partner (low/high), Build (high/low), Invest (high/high). Quality criteria: each quadrant has a clear decision rule and one example." Q5: "Biggest mistake: treating it as a one-time decision. Consequence: you build something, market shifts, and you're stuck maintaining undifferentiated tech. Fix: revisit quarterly."

Output: Complete component skill with template, filled example, and the quarterly-review pitfall.


Example: Advisory Topic → Interactive Skill

Q1: "4 — Coaching topic. Helping PMs navigate their first pricing conversation with leadership." Q2: "1 — Yes, interactive." Q3: "Name: pricing-conversation-advisor. Description: 'Prepare for your first pricing conversation with leadership. Use when presenting pricing changes or new monetization to executives.'" Q4: "Opening question: What's the pricing change? Branches: new product pricing, price increase on existing, freemium-to-paid conversion, usage-based transition. Recommendations: data to bring, objection handling, framing strategies." Q5: "Failure mode: 'Leading with the Number.' Consequence: executives fixate on the price point instead of the strategy. Fix: always lead with the business case and customer impact before revealing the number."

Output: Complete interactive skill with 3-question flow, 4 branches, and enumerated recommendations per branch.


Anti-Pattern: Scope Creep

Q1: "I want a skill that covers all of product strategy — vision, roadmaps, OKRs, prioritization, stakeholder alignment, and metrics."

Agent response: "That's 4-6 separate skills, not one. Let's pick the one that matters most right now and build that. Which piece is most urgent?

  1. Vision → component skill
  2. Roadmap planning → workflow skill (already exists: roadmap-planning)
  3. Prioritization → interactive skill (already exists: prioritization-advisor)
  4. Something else

Start with one. We can build the others after."

Common Pitfalls

Pitfall 1: Type Confusion

Symptom: Calling something a "workflow" when it's really a template with numbered steps.

Consequence: Over-engineered skill that references non-existent sub-skills and confuses users.

Fix: Apply the type decision questions from Q2 honestly. If it doesn't orchestrate other skills or have distinct phases with different inputs/outputs, it's probably a component.

Pitfall 2: Description That Doesn't Trigger

Symptom: Description says what the skill is ("A framework for pricing decisions") but not when to use it.

Consequence: Claude can't match user requests to the skill. It sits unused.

Fix: Every description must answer "Use when..." — e.g., "Evaluate pricing decisions using a structured framework. Use when choosing between pricing models or preparing a pricing proposal."

Pitfall 3: Skipping Validation

Symptom: "The draft looks good, let's ship it."

Consequence: Broken frontmatter, missing sections, failed cross-references, inconsistent catalog counts.

Fix: Always run check-skill-metadata.py and check-skill-triggers.py before considering the skill done. No exceptions.

Pitfall 4: Kitchen Sink Scope

Symptom: Trying to pack an entire domain into one skill.

Consequence: A 500-line monster that does nothing well. Too broad to trigger accurately, too long to be useful.

Fix: One skill = one job. If you need more than 6 application steps or more than 4 branches, you probably need multiple skills.

References

Related Skills

Repo Tools

  • scripts/build-a-skill.sh — Terminal wizard for section-by-section skill creation
  • scripts/add-a-skill.sh — Content-first automated skill generator
  • scripts/check-skill-metadata.py — Structural validation
  • scripts/check-skill-triggers.py — Trigger-readiness audit
  • scripts/test-a-skill.sh — Full quality gate
  • scripts/find-a-skill.sh — Check for overlapping skills before creating

Documentation

  • CLAUDE.md — Master skill distillation protocol and quality standards
  • docs/Building PM Skills.md — Manual skill creation guide
  • docs/Add-a-Skill Utility Guide.md — Automated creation guide
指导产品经理根据假设、风险和资源选择最合适的生存证明(PoL)探针类型。通过匹配验证方法与学习目标,避免基于工具熟练度或内部政治做决定,确保以最低成本获取最真实的反馈,涵盖5种探针类型及反模式。
需要选择产品验证方法时 不确定哪种探针适合特定假设或风险时 输入包含待验证的假设、风险描述或资源限制信息时
skills/pol-probe-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill pol-probe-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "pol-probe-advisor",
    "type": "interactive",
    "intent": "Guide product managers through selecting the right **Proof of Life (PoL) probe** type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specific risk or test a narrow hypothesis, but aren't sure which validation method to use. This interactive skill ensures you match the cheapest prototype to the harshest truth—not the prototype you're most comfortable building.",
    "best_for": [
        "Choosing the cheapest useful validation method for a risky idea",
        "Matching a hypothesis to the right Proof of Life probe",
        "Avoiding overbuilding before learning the harsh truth"
    ],
    "scenarios": [
        "Which Proof of Life probe should I use to test demand for this idea?",
        "Help me pick the right validation method for an onboarding hypothesis",
        "I have a risky AI concept. What PoL probe should I run first?"
    ],
    "description": "Select the right Proof of Life (PoL) probe based on hypothesis, risk, and resources. Use this to match the validation method to the real learning goal, not tooling comfort.",
    "argument-hint": "[hypothesis or risk]"
}

Purpose

Guide product managers through selecting the right Proof of Life (PoL) probe type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specific risk or test a narrow hypothesis, but aren't sure which validation method to use. This interactive skill ensures you match the cheapest prototype to the harshest truth—not the prototype you're most comfortable building.

This is not a tool for deciding if you should validate (you should). It's a decision framework for choosing how to validate most effectively.

Input

Works best with: The hypothesis you want to validate or the risk you want to eliminate. Also useful: Your resources (time, budget, engineering access), audience access, and what failure would cost.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking what you're trying to learn, then matches you to one of the 5 probe flavors.

Example invocation: Which probe fits? Hypothesis: mid-market HR teams will trust AI-drafted job descriptions enough to publish them; 2 weeks, no eng support.

Key Concepts

The Core Problem: Method-Hypothesis Mismatch

Common failure mode: PMs choose validation methods based on tooling comfort ("I know Figma, so I'll design a prototype") rather than learning goal. Result: validate the wrong thing, miss the actual risk.

Solution: Work backwards from the hypothesis. Ask: "What specific risk am I eliminating? What's the cheapest path to harsh truth?"


The 5 PoL Probe Flavors (Quick Reference)

Type Core Question Best For Timeline
Feasibility Check "Can we build this?" Technical unknowns, API dependencies, data integrity 1-2 days
Task-Focused Test "Can users complete this job without friction?" Critical UI moments, field labels, decision points 2-5 days
Narrative Prototype "Does this workflow earn stakeholder buy-in?" Storytelling, explaining complex flows, alignment 1-3 days
Synthetic Data Simulation "Can we model this without production risk?" Edge cases, unknown-unknowns, statistical modeling 2-4 days
Vibe-Coded PoL Probe "Will this solution survive real user contact?" Workflow/UX validation with real interactions 2-3 days

Golden Rule: "Use the cheapest prototype that tells the harshest truth."


Anti-Patterns (What This Is NOT)

  • Not "build the prototype you're comfortable with": Match method to hypothesis, not skillset
  • Not "pick based on stakeholder preference": Optimize for learning, not internal politics
  • Not "choose the most impressive option": Impressive ≠ informative
  • Not "default to code": Writing code should be your last resort, not your first

When to Use This Skill

Use this when:

  • You have a clear hypothesis but don't know which validation method to use
  • You're unsure whether to build code, create a video, or run a simulation
  • You need to eliminate a specific risk quickly (within days)
  • You want to avoid prototype theater

Don't use this when:

  • You don't have a hypothesis yet (use problem-statement.md or problem-framing-canvas.md first)
  • You're trying to impress executives (that's not validation)
  • You already know the answer (confirmation bias)
  • You need to ship an MVP (this is for pre-MVP reconnaissance)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill uses adaptive questioning to recommend the right PoL probe type based on your context.


Step 0: Gather Context

Agent asks:

Let's figure out which PoL probe type is right for your validation needs. First, I need some context:

1. What hypothesis are you testing? (Describe in one sentence, or use "If [we do X] for [persona], then [outcome]" format)

2. What specific risk are you trying to eliminate? Examples:

  • Technical feasibility ("Can our API handle real-time data?")
  • User task completion ("Can users find the 'export' button?")
  • Stakeholder alignment ("Will leadership approve this direction?")
  • Edge case behavior ("How does the system handle duplicate entries?")
  • Workflow validation ("Will users complete the 3-step onboarding?")

3. What's your timeline?

  • Hours (same-day validation)
  • 1-2 days (quick spike)
  • 3-5 days (moderate effort)
  • 1 week+ (too long—consider breaking into smaller probes)

4. What resources do you have available? Examples:

  • Engineering capacity (1 dev for 1 day)
  • Design tools (Figma, Loom, Sora)
  • AI/no-code tools (ChatGPT Canvas, Replit, Airtable)
  • User access (10 users from waitlist, 5 beta customers, etc.)
  • Budget (for UsabilityHub, Optimal Workshop, etc.)

Step 1: Identify the Core Question

Agent synthesizes user input and asks:

Based on your hypothesis and risk, which of these core questions are you really trying to answer?

Offer 5 options (aligned to probe types):

  1. "Can we build this?" — You're uncertain about technical feasibility, API integration, data availability, or third-party dependencies
  2. "Can users complete this job without friction?" — You're validating critical UI moments, field labels, navigation, or decision points
  3. "Does this workflow earn stakeholder buy-in?" — You need to explain a complex flow, align leadership, or "tell vs. test" the story
  4. "Can we model this without production risk?" — You need to explore edge cases, simulate user behavior, or test prompt logic safely
  5. "Will this solution survive real user contact?" — You need users to interact with a semi-functional workflow to catch UX/workflow issues

User response: [Select one number, or describe if none fit]


Step 2: Recommend PoL Probe Type

Based on user selection, agent recommends the matching probe type:


Option 1 Selected: "Can we build this?"

Recommended Probe: Feasibility Check

What it is: A 1-2 day spike-and-delete test to surface technical risk. Not meant to impress anyone—meant to reveal blockers fast.

Methods:

  • GenAI prompt chains (test if AI can handle your use case)
  • API sniff tests (verify third-party integrations work)
  • Data integrity sweeps (check if your data supports the feature)
  • Third-party tool evaluation (test if Zapier/Stripe/Twilio does what you think)

Timeline: 1-2 days

Tools:

  • ChatGPT/Claude (prompt testing)
  • Postman/Insomnia (API testing)
  • Jupyter notebooks (data exploration)
  • Proof-of-concept scripts (throwaway code)

Success Criteria Example:

  • Pass: API returns expected data format in <200ms
  • Fail: API times out, or data structure incompatible with our schema
  • Learn: Identify specific technical blocker

Disposal Plan: Delete all spike code after documenting findings.

Next Step: Would you like me to generate a pol-probe artifact documenting this feasibility check?


Option 2 Selected: "Can users complete this job without friction?"

Recommended Probe: Task-Focused Test

What it is: Validate critical moments—field labels, decision points, navigation, drop-off zones—using specialized testing tools. Focus on observable task completion, not opinions.

Methods:

  • Optimal Workshop (tree testing, card sorting)
  • UsabilityHub (5-second tests, click tests, preference tests)
  • Maze (prototype testing with heatmaps)
  • Loom-recorded task walkthroughs (ask users to "think aloud")

Timeline: 2-5 days

Tools:

  • Optimal Workshop ($200/month)
  • UsabilityHub ($100-300/month)
  • Maze (free tier available)
  • Loom (free for basic)

Success Criteria Example:

  • Pass: 80%+ users complete task in <2 minutes
  • Fail: <60% completion, or 3+ users get stuck on same step
  • Learn: Identify exact friction point (specific field, button, etc.)

Disposal Plan: Archive session recordings, document learnings, delete test prototype.

Next Step: Would you like me to generate a pol-probe artifact documenting this task-focused test?


Option 3 Selected: "Does this workflow earn stakeholder buy-in?"

Recommended Probe: Narrative Prototype

What it is: Tell the story, don't test the interface. Use video walkthroughs or slideware storyboards to explain workflows and measure interest. This is "tell vs. test"—you're validating the narrative, not the UI.

Methods:

  • Loom walkthroughs (screen recording with voiceover)
  • Sora/Synthesia/Veo3 (AI-generated explainer videos)
  • Slideware storyboards (PowerPoint/Keynote with illustrations)
  • Storyboard sketches (use storyboard.md component skill)

Timeline: 1-3 days

Tools:

  • Loom (free, fast)
  • Sora/Synthesia (text-to-video, paid)
  • PowerPoint/Keynote (slideware animation)
  • Figma (static storyboard frames)

Success Criteria Example:

  • Pass: 8/10 stakeholders say "I'd use this" or "This solves the problem"
  • Fail: Stakeholders ask "Why would I use this?" or suggest alternative approaches
  • Learn: Identify which part of the narrative resonates (or doesn't)

Disposal Plan: Archive video, document feedback, delete supporting files.

Next Step: Would you like me to generate a pol-probe artifact documenting this narrative prototype?


Option 4 Selected: "Can we model this without production risk?"

Recommended Probe: Synthetic Data Simulation

What it is: Use simulated users, synthetic data, or prompt logic testing to explore edge cases and unknown-unknowns without touching production. Think "wind tunnel testing, cheaper than postmortem."

Methods:

  • Synthea (synthetic patient data generation)
  • DataStax LangFlow (test prompt logic without real users)
  • Monte Carlo simulations (model probabilistic outcomes)
  • Synthetic user behavior scripts (simulate click patterns, load testing)

Timeline: 2-4 days

Tools:

  • Synthea (open-source, healthcare)
  • DataStax LangFlow (prompt chain testing)
  • Python + Faker library (generate synthetic data)
  • Locust/k6 (load testing with synthetic users)

Success Criteria Example:

  • Pass: System handles 10,000 synthetic users with <1% error rate
  • Fail: Edge cases cause crashes or incorrect outputs
  • Learn: Identify which edge cases break the system

Disposal Plan: Delete synthetic data, archive findings, document edge cases.

Next Step: Would you like me to generate a pol-probe artifact documenting this synthetic data simulation?


Option 5 Selected: "Will this solution survive real user contact?"

Recommended Probe: Vibe-Coded PoL Probe

What it is: A Frankensoft stack (ChatGPT Canvas + Replit + Airtable) that creates just enough illusion for users to interact with a semi-functional workflow. Not production-grade—just enough to catch UX/workflow signals in 48 hours.

⚠️ Warning: This is the riskiest probe type. It looks real enough to confuse momentum with maturity. Use only when you need real user contact and other methods won't suffice.

Methods:

  • ChatGPT Canvas (quick UI generation)
  • Replit (host throwaway code)
  • Airtable (fake database)
  • Carrd/Webflow (landing page + workflow mockup)

Timeline: 2-3 days

Stack Example:

  • ChatGPT Canvas: Generate form UI
  • Replit: Host simple Flask/Node app
  • Airtable: Capture form submissions
  • Loom: Record user sessions for post-mortem analysis

Success Criteria Example:

  • Pass: 8/10 users complete workflow, 0 critical confusion moments
  • Fail: Users get stuck, ask "Is this broken?", or abandon mid-flow
  • Learn: Identify exact step where users lose confidence

Disposal Plan: Delete all code after user sessions, archive Loom recordings, document learnings.

Next Step: Would you like me to generate a pol-probe artifact documenting this vibe-coded probe?


Step 3: Apply Component Skill

Agent offers:

I recommend using [selected probe type] for your hypothesis. Would you like me to:

  1. Generate a complete pol-probe artifact (using the pol-probe.md template) with your hypothesis, success criteria, timeline, and disposal plan?
  2. Walk through the execution steps for this probe type (tools, methods, user recruitment)?
  3. Refine the hypothesis before proceeding (if it seems too broad or ambiguous)?

User selects option, and agent executes accordingly.


Step 4: Refine or Iterate (Optional)

If user is uncertain or hypothesis is too broad:

Agent asks:

Your hypothesis seems broad or tests multiple things at once. PoL probes work best when they're narrow and falsifiable. Let me ask a few clarifying questions:

Clarifying Questions:

  1. What's the smallest thing you could test first? (Isolate one variable)
  2. What would "failure" look like? (If you can't describe failure, you can't measure success)
  3. Is this testing user behavior, technical feasibility, or stakeholder alignment? (Pick one focus)

Agent then re-recommends probe type based on refined hypothesis.


Examples

Example 1: Choosing Task-Focused Test

User Context:

  • Hypothesis: "Users can complete our checkout flow in under 3 minutes"
  • Risk: High cart abandonment on mobile
  • Timeline: 3 days
  • Resources: UsabilityHub account, 20 users from waitlist

Agent Reasoning:

  • Core question: "Can users complete this job without friction?"
  • Risk is task completion (observable behavior), not technical feasibility
  • Timeline fits Task-Focused Test (2-5 days)

Recommendation: Task-Focused Test using UsabilityHub

  • Method: Maze prototype testing with mobile users
  • Success criteria: 80%+ complete checkout in <3 minutes
  • Disposal: Delete prototype after analyzing heatmaps

Example 2: Choosing Feasibility Check

User Context:

  • Hypothesis: "We can auto-tag support tickets using GPT-4 with <5% error rate"
  • Risk: Unknown if AI can handle industry-specific jargon
  • Timeline: 1 day
  • Resources: 100 past support tickets, ChatGPT API access

Agent Reasoning:

  • Core question: "Can we build this?"
  • Risk is technical feasibility (AI capability), not user behavior
  • Timeline is short (1 day = spike territory)

Recommendation: Feasibility Check using prompt engineering spike

  • Method: Run 100 tickets through GPT-4 prompt chain, measure error rate
  • Success criteria: <5% misclassified tickets
  • Disposal: Delete spike code after documenting findings

Outcome: Error rate was 18%. Decided NOT to build feature. Saved 6 weeks of development.


Example 3: Choosing Narrative Prototype (NOT Vibe-Coded)

User Context:

  • Hypothesis: "Enterprise buyers will understand our multi-tenant security model"
  • Risk: Complex technical concept needs explanation
  • Timeline: 2 days
  • Resources: Loom, 5 enterprise prospects

Agent Reasoning:

  • Core question: "Does this workflow earn stakeholder buy-in?"
  • Risk is comprehension/alignment, not task completion
  • Building a functional prototype would over-invest (2 days = just explain it)

Recommendation: Narrative Prototype using Loom walkthrough

  • Method: 5-minute Loom explaining security model with diagrams
  • Success criteria: 4/5 prospects say "I understand this" without follow-up questions
  • Disposal: Archive video after 5 sessions

Why NOT Vibe-Coded Probe: You don't need users to interact with security settings—you need them to understand the concept. Narrative is cheaper and faster.


Example 4: Avoiding Prototype Theater

User Context:

  • Hypothesis: "Executives will approve budget if we show a polished demo"
  • Risk: Internal politics
  • Timeline: 3 weeks
  • Resources: Full design team

Agent Response:

⚠️ This is prototype theater, not a PoL probe.

You're testing internal politics, not user behavior or technical feasibility. PoL probes eliminate product risk, not organizational risk.

Recommendation: Skip the prototype entirely. Instead:

  1. Use a Narrative Prototype (1-day Loom walkthrough) to explain the concept
  2. Test with 5 target users (not executives) to validate the hypothesis
  3. Present user feedback to executives, not a polished demo

If executives need a demo, build it after you've validated the hypothesis with real users.


Common Pitfalls

1. Choosing Based on Tooling Comfort

Failure Mode: "I know Figma, so I'll design a UI prototype" (even if design isn't the risk).

Consequence: Validate the wrong thing; miss the actual risk.

Fix: Answer the core question first, then pick the method. If you need a Feasibility Check but only know design tools, pair with an engineer for 1 day.


2. Defaulting to Code

Failure Mode: "Let's just build it and see what happens."

Consequence: 2 weeks of development before learning you tested the wrong hypothesis.

Fix: Ask: "What's the cheapest prototype that tells the harshest truth?" Usually it's NOT code.


3. Confusing Vibe-Coded Probes with MVPs

Failure Mode: Vibe-Coded probe "looks real," so team treats it like production code.

Consequence: Scope creep, technical debt, resistance to disposal.

Fix: Set disposal date before building. Vibe-Coded probes are Frankensoft by design—celebrate the jank, delete after learning.


4. Testing Multiple Things at Once

Failure Mode: "Let's test the workflow, the pricing, and the UI in one probe."

Consequence: Ambiguous results—you won't know which variable caused failure.

Fix: One probe, one hypothesis. If you have 3 hypotheses, run 3 probes.


5. Skipping Success Criteria

Failure Mode: "We'll know it when we see it."

Consequence: No harsh truth—just opinions and vanity metrics.

Fix: Write success criteria before building. Define "pass," "fail," and "learn" thresholds.


References

Related Skills

External Frameworks

  • Jeff PattonUser Story Mapping (lean validation principles)
  • Marty CaganInspired (2014 prototype flavors framework)
  • Dean PetersVibe First, Validate Fast, Verify Fit (Dean Peters' Substack, 2025)

Tools by Probe Type

  • Feasibility: ChatGPT/Claude, Postman, Jupyter
  • Task-Focused: Optimal Workshop, UsabilityHub, Maze
  • Narrative: Loom, Sora, Synthesia, PowerPoint
  • Synthetic Data: Synthea, DataStax LangFlow, Faker
  • Vibe-Coded: ChatGPT Canvas, Replit, Airtable, Carrd
定义低成本、一次性验证实验(PoL探针),用于在开发前以最小资源测试高风险假设,揭示残酷真相。防止原型表演,强制匹配验证方法与学习目标,避免沉没成本谬误。
需要低成本测试高风险假设 构建产品前需验证核心风险 消除特定不确定性
skills/pol-probe/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill pol-probe -g -y
SKILL.md
Frontmatter
{
    "name": "pol-probe",
    "type": "component",
    "intent": "Define and document a **Proof of Life (PoL) probe**—a lightweight, disposable validation artifact designed to surface harsh truths before expensive development. Use this when you need to eliminate a specific risk or test a narrow hypothesis **without building production-quality software**. PoL probes are reconnaissance missions, not MVPs—they're meant to be deleted, not scaled.",
    "best_for": [
        "Documenting a lightweight validation artifact before build",
        "Testing a narrow hypothesis without shipping production software",
        "Reducing risk before spending engineering time"
    ],
    "scenarios": [
        "Define a Proof of Life probe for a new workflow automation idea",
        "Help me write a PoL probe for this pricing hypothesis",
        "Create a low-cost validation probe before we build this feature"
    ],
    "description": "Define a Proof of Life probe to test a risky hypothesis cheaply. Use when you need harsh truth before building real product.",
    "argument-hint": "[hypothesis to test]"
}

Purpose

Define and document a Proof of Life (PoL) probe—a lightweight, disposable validation artifact designed to surface harsh truths before expensive development. Use this when you need to eliminate a specific risk or test a narrow hypothesis without building production-quality software. PoL probes are reconnaissance missions, not MVPs—they're meant to be deleted, not scaled.

This framework prevents prototype theater (expensive demos that impress stakeholders but teach nothing) and forces you to match validation method to actual learning goal.

Input

Works best with: The hypothesis or risk you need to test. Also useful: What evidence would change your mind, available time/resources, and what you've validated already.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the hypothesis and the riskiest assumption inside it before designing the probe.

Example invocation: Define a PoL probe: we believe restaurant managers will photograph invoices daily if it auto-updates food costs.

Key Concepts

What is a PoL Probe?

A Proof of Life (PoL) probe is a deliberate, disposable validation experiment designed to answer one specific question as cheaply and quickly as possible. It's not a product, not an MVP, not a pilot—it's a targeted truth-seeking mission.

Origin: Coined by Dean Peters (Productside), building on Marty Cagan's 2014 work on prototype flavors and Jeff Patton's principle: "The most expensive way to test your idea is to build production-quality software."


The 5 Essential Characteristics

Every PoL probe must satisfy these criteria:

Characteristic What It Means Why It Matters
Lightweight Minimal resource investment (hours/days, not weeks) If it's expensive, you'll avoid killing it when the data says to
Disposable Explicitly planned for deletion, not scaling Prevents sunk-cost fallacy and scope creep
Narrow Scope Tests one specific hypothesis or risk Broad experiments yield ambiguous results
Brutally Honest Surfaces harsh truths, not vanity metrics Polite data is useless data
Tiny & Focused Reconnaissance missions, never MVPs Small surface area = faster learning cycles

Anti-Pattern: If your "prototype" feels too polished to delete, it's not a PoL probe—it's prototype theater.


PoL Probe vs. MVP

Dimension PoL Probe MVP
Purpose De-risk decisions through narrow hypothesis testing Justify ideas or defend roadmap direction
Scope Single question, single risk Smallest shippable product increment
Lifespan Hours to days, then deleted Weeks to months, then iterated
Audience Internal team + narrow user sample Real customers in production
Fidelity Just enough illusion to catch signals Production-quality (or close)
Outcome Learn what doesn't work Learn what does work (and ship it)

Key Distinction: PoL probes are pre-MVP reconnaissance. You run probes to decide if you should build an MVP, not to launch something.


The 5 Prototype Flavors

Match the probe type to your hypothesis, not your tooling comfort.

Type Core Question Timeline Tools/Methods When to Use
1. Feasibility Checks "Can we build this?" 1-2 days GenAI prompt chains, API tests, data integrity sweeps, spike-and-delete code Technical risk is unknown; third-party dependencies unclear
2. Task-Focused Tests "Can users complete this job without friction?" 2-5 days Optimal Workshop, UsabilityHub, task flows Critical moments (field labels, decision points, drop-off zones) need validation
3. Narrative Prototypes "Does this workflow earn stakeholder buy-in?" 1-3 days Loom walkthroughs, Sora/Synthesia videos, slideware storyboards You need to "tell vs. test"—share the story, measure interest
4. Synthetic Data Simulations "Can we model this without production risk?" 2-4 days Synthea (user simulation), DataStax LangFlow (prompt logic testing) Edge case exploration; unknown-unknown surfacing
5. Vibe-Coded PoL Probes "Will this solution survive real user contact?" 2-3 days ChatGPT Canvas + Replit + Airtable = "Frankensoft" You need user feedback on workflow/UX, but not production-grade code

Golden Rule: "Use the cheapest prototype that tells the harshest truth. If it doesn't sting, it's probably just theater."


When to Use a PoL Probe

Use a PoL probe when:

  • You have a specific, falsifiable hypothesis to test
  • A particular risk blocks your next decision (technical feasibility, user task completion, stakeholder support)
  • You need harsh truth fast (within days, not weeks)
  • Building production software would be premature or wasteful
  • You can articulate what "failure" looks like before you start

Don't use a PoL probe when:

  • You're trying to impress executives (that's prototype theater)
  • You already know the answer and just want validation (that's confirmation bias)
  • You can't articulate a clear hypothesis or disposal plan
  • The learning goal is too broad ("Will customers like this?")
  • You're using it to avoid making a hard decision

Application

Use template.md for the full fill-in structure.

PoL Probe Template

Use this structure to document your probe:

# PoL Probe: [Descriptive Name]

## Hypothesis
[One-sentence statement of what you believe to be true]
Example: "If we reduce the onboarding form to 3 fields, completion rate will exceed 80%."

## Risk Being Eliminated
[What specific risk or unknown are you addressing?]
Example: "We don't know if users will abandon signup due to form length."

## Prototype Type
[Select one of the 5 flavors]
- [ ] Feasibility Check
- [ ] Task-Focused Test
- [ ] Narrative Prototype
- [ ] Synthetic Data Simulation
- [x] Vibe-Coded PoL Probe

## Target Users / Audience
[Who will interact with this probe?]
Example: "10 users from our early access waitlist, non-technical SMB owners."

## Success Criteria (Harsh Truth)
[What truth are you seeking? What would prove you wrong?]
- **Pass:** 8+ users complete signup in under 2 minutes
- **Fail:** <6 users complete, or average time exceeds 5 minutes
- **Learn:** Identify specific drop-off fields

## Tools / Stack
[What will you use to build this?]
Example: "ChatGPT Canvas for form UI, Airtable for data capture, Loom for post-session interviews."

## Timeline
- **Build:** 2 days
- **Test:** 1 day (10 user sessions)
- **Analyze:** 1 day
- **Disposal:** Day 5 (delete all code, keep learnings doc)

## Disposal Plan
[When and how will you delete this?]
Example: "After user sessions complete, archive recordings, delete Frankensoft code, document learnings in Notion."

## Owner
[Who is accountable for running and disposing of this probe?]

## Status
- [ ] Hypothesis defined
- [ ] Probe built
- [ ] Users recruited
- [ ] Testing complete
- [ ] Learnings documented
- [ ] Probe disposed

Quality Checklist

Before launching your PoL probe, verify:

  • Lightweight: Can you build this in 1-3 days?
  • Disposable: Have you committed to a disposal date?
  • Narrow Scope: Does it test ONE hypothesis?
  • Brutally Honest: Will the data hurt if you're wrong?
  • Tiny & Focused: Is this smaller than an MVP?
  • Falsifiable: Can you describe what "failure" looks like?
  • Clear Owner: Is one person accountable for executing and disposing of this?

If any answer is "no," revise your probe or reconsider whether you need one.


Examples

See examples/sample.md for full PoL probe examples.

Mini example excerpt:

**Hypothesis:** Users can distinguish "archive" vs "delete"
**Probe Type:** Task-Focused Test
**Pass:** 80%+ correct interpretation

Common Pitfalls

  • Running a broad "will users like this?" experiment instead of testing one falsifiable hypothesis
  • Treating a PoL probe as a proto-MVP and refusing to dispose of it
  • Using vanity metrics that avoid uncomfortable truth
  • Skipping a pre-defined failure threshold before testing begins
  • Choosing tools first and hypothesis second

References

Related Skills

External Frameworks

  • Jeff PattonUser Story Mapping (lean validation principles)
  • Marty CaganInspired (2014 prototype flavors framework)
  • Dean PetersVibe First, Validate Fast, Verify Fit (Dean Peters' Substack, 2025)

Tools Mentioned

  • Feasibility: GenAI (ChatGPT, Claude), API testing tools
  • Task-Focused: Optimal Workshop, UsabilityHub
  • Narrative: Loom, Sora, Synthesia, Veo3 (text-to-video)
  • Synthetic Data: Synthea (patient simulation), DataStax LangFlow
  • Vibe-Coded: ChatGPT Canvas, Replit, Airtable, Carrd
基于Geoffrey Moore框架生成定位声明,明确目标客户、未满足需求、产品类别、核心利益及差异化优势。适用于战略对齐、价值主张测试及新品发布,强制聚焦具体结果与真实差异,避免空泛描述。
需要澄清产品服务对象和解决的问题 制定产品战略或营销信息以对齐团队 验证价值主张是否清晰且具有防御性 新产品定义或重大转型期
skills/positioning-statement/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill positioning-statement -g -y
SKILL.md
Frontmatter
{
    "name": "positioning-statement",
    "type": "component",
    "theme": "strategy-positioning",
    "intent": "Create a Geoffrey Moore-style positioning statement that clearly articulates who your product serves, what need it addresses, how it's categorized, what benefit it delivers, and how it differs from alternatives. Use this when you need to align stakeholders on product strategy, guide messaging, or test if your value proposition is crisp and defensible.",
    "best_for": [
        "Defining your product's market position clearly for the first time",
        "Differentiating from specific competitors in your messaging",
        "Aligning your team on who you serve, what problem you solve, and why you're different"
    ],
    "scenarios": [
        "I need to write a positioning statement for a new B2B SaaS product targeting mid-market HR teams",
        "Our positioning feels generic and I need to sharpen it against two specific competitors"
    ],
    "description": "Create a Geoffrey Moore-style positioning statement. Use when clarifying who you serve, what problem you solve, your category, and why you're different from alternatives.",
    "argument-hint": "[product] [target customer]",
    "estimated_time": "10-15 min"
}

Purpose

Create a Geoffrey Moore-style positioning statement that clearly articulates who your product serves, what need it addresses, how it's categorized, what benefit it delivers, and how it differs from alternatives. Use this when you need to align stakeholders on product strategy, guide messaging, or test if your value proposition is crisp and defensible.

This is not a tagline or elevator pitch—it's a strategic clarity tool that forces you to make hard choices about target, need, and differentiation.

Input

Works best with: The product and its target customer. Also useful: The unmet need, product category, primary benefit, and nearest alternative — the skill drafts from what you give and asks only for what's missing.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for product and target customer first, then works through the Moore template slots.

Example invocation: Positioning statement for LaunchDarkly-style feature flags aimed at platform engineering leads at 200+ eng orgs.

Key Concepts

The Geoffrey Moore Framework

From Crossing the Chasm, Moore's framework splits positioning into two parts:

Value Proposition:

  • For [target customer]
  • that need [underserved need]
  • [product name]
  • is a [product category]
  • that [benefit statement]

Differentiation Statement:

  • Unlike [primary competitor or competitive alternative]
  • [product name]
  • provides [unique differentiation]

Why This Structure Works

  • Forces specificity: You can't say "for everyone" or "unlike all competitors"
  • Exposes assumptions: If you can't fill in "unlike X," you may not have defensible differentiation
  • Focuses on outcomes, not features: "That reduces churn by 40%" beats "that has analytics"
  • Category anchors perception: Saying "is a CRM" vs. "is a workflow tool" changes how buyers evaluate you

Anti-Patterns (What This Is NOT)

  • Not a tagline: "Positioning" ≠ "Nike: Just Do It"
  • Not a feature list: Don't say "that provides AI, automation, and integrations"
  • Not generic: "For businesses that need efficiency" = positioning theater
  • Not aspirational fluff: "That revolutionizes productivity" without specifics is noise

When to Use This

  • Defining a new product or major pivot
  • Aligning exec/founder/PM/marketing on strategy
  • Testing if your differentiation is real or imagined
  • Before writing PRDs, launch plans, or sales collateral

When NOT to Use This

  • For internal tools with captive users (positioning is for markets)
  • When you're still in problem validation (position after you know the problem)
  • As a substitute for customer research (this synthesizes insights, doesn't create them)

Application

Use template.md for the full fill-in structure.

Step 1: Gather Context

Before drafting, ensure you have:

  • Target customer segment: Demographics, behaviors, role (not just "SMBs" or "developers")
  • Underserved need: Pains, gains, jobs-to-be-done (reference skills/jobs-to-be-done/SKILL.md if needed)
  • Product category: How buyers mentally file your solution (CRM, analytics platform, etc.)
  • Competitive landscape: Direct competitors AND substitute behaviors (e.g., "Excel" is often the real competitor)

If missing context: Use discovery interviews, market research, or customer interviews to fill gaps. Don't guess.


Step 2: Draft the Value Proposition

Fill in the template:

## Value Proposition

**For** [specific target customer/persona]
- **that need** [statement of underserved need—focus on pains, gains, JTBD]
- [product or service name]
- **is a** [product category]
- **that** [benefit statement—focus on outcomes, not features]

Quality checks:

  • Target specificity: Could you describe this person to a recruiter? If not, narrow it.
  • Need clarity: Does this need resonate emotionally? Or is it generic ("need efficiency")?
  • Category fit: Does this category help or hurt you? (Sometimes creating a new category is strategic, but risky.)
  • Outcome focus: Are you saying what the user gets, not what the product has?

Step 3: Draft the Differentiation Statement

Fill in the template:

## Differentiation Statement

- **Unlike** [primary competitor or competitive alternative]
- [product or service name]
- **provides** [unique differentiation—outcomes, not features]

Quality checks:

  • Competitor honesty: Is this the real alternative buyers consider? (Not just who you wish they compared you to.)
  • Differentiation substance: Could a competitor copy this in 6 months? If yes, it's not durable differentiation.
  • Outcome framing: Are you saying what users achieve differently, not just what you do differently?

Step 4: Stress-Test the Positioning

Ask these questions:

  1. Would a customer recognize themselves? Read the "For [target]" aloud. Does it feel specific or generic?
  2. Is the need defensible? Can you point to research, interviews, or data that validates this need?
  3. Does the category help or hurt? Does it anchor you against the right competitors? Or does it box you in?
  4. Is differentiation believable? Could you prove this claim with a demo, case study, or data?
  5. Does this guide decisions? If someone asked "Should we build feature X?" would this positioning help answer it?

If any answer is "no" or "sort of," revise.


Step 5: Socialize and Iterate

  • Share with stakeholders: Founders, execs, product, marketing, sales
  • Test with customers: Read it aloud. Do they nod or look confused?
  • Refine ruthlessly: Positioning is never done on the first draft. Cut words, sharpen specificity, test alternatives.

Examples

See examples/sample.md for full positioning examples.

Mini example excerpt:

**For** software development teams
- **that need** to reduce email overload and improve real-time collaboration
- Slack
- **is a** team messaging platform
- **that** centralizes communication and makes conversations searchable

Common Pitfalls

Pitfall 1: "For Everyone"

Symptom: "For businesses that want to grow" or "For anyone who uses software"

Consequence: No one feels like it's for them. Positioning becomes invisible.

Fix: Pick the first customer segment you'll serve. You can expand later, but positioning works when it's narrow.


Pitfall 2: Feature Creep in Benefit Statement

Symptom: "That provides AI, automation, analytics, and integrations"

Consequence: Sounds like a feature list, not a benefit. Buyers tune out.

Fix: Lead with the outcome: "That reduces churn by 30% through predictive analytics." The features are how, not why.


Pitfall 3: Imaginary Competitor

Symptom: "Unlike outdated legacy systems" or "Unlike traditional approaches"

Consequence: You're positioning against a straw man. Real buyers don't recognize this alternative.

Fix: Name the actual competitor or substitute behavior. If buyers use Excel, say "Unlike Excel." If they use a competitor, name them.


Pitfall 4: Differentiation Without Proof

Symptom: "Provides revolutionary AI" or "Delivers unmatched speed"

Consequence: Claims without evidence = marketing fluff. Buyers ignore it.

Fix: Make it falsifiable: "Provides 10x faster query performance than Snowflake on datasets under 1TB" (can be tested).


Pitfall 5: Category Confusion

Symptom: "Is a next-generation platform for digital transformation"

Consequence: Buyers don't know how to evaluate you. Category = mental shelf. No shelf = no sale.

Fix: Pick a category buyers already understand (CRM, analytics, messaging) OR commit to category creation (requires $$$ and time).


References

Related Skills

  • skills/problem-statement/SKILL.md — Defines the problem positioning addresses
  • skills/jobs-to-be-done/SKILL.md — Informs the "that need" statement
  • skills/proto-persona/SKILL.md — Defines the "For [target]" segment
  • skills/press-release/SKILL.md — Positioning informs press release messaging

External Frameworks

  • Geoffrey Moore, Crossing the Chasm (1991) — Origin of this framework
  • April Dunford, Obviously Awesome (2019) — Modern positioning playbook
  • Al Ries & Jack Trout, Positioning: The Battle for Your Mind (1981) — Foundational positioning theory

Dean's Work

  • [Link to relevant Dean Peters' Substack articles if applicable]

Provenance

  • Adapted from prompts/positioning-statement.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: positioning-statement.md Suggested placement: /skills/components/ Dependencies: References skills/problem-statement/SKILL.md, skills/jobs-to-be-done/SKILL.md, skills/proto-persona/SKILL.md

引导产品经理通过结构化问答明确目标客户、未满足需求及差异化优势,输出Geoffrey Moore定位陈述。适用于产品定位模糊或需对齐战略时,避免泛泛而谈。
产品宣传语模糊或通用 定义新产品定位 重新定位现有产品 利益相关者对齐策略 撰写PRD或发布计划前
skills/positioning-workshop/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill positioning-workshop -g -y
SKILL.md
Frontmatter
{
    "name": "positioning-workshop",
    "type": "interactive",
    "intent": "Guide product managers through discovering and articulating product positioning by asking adaptive questions about target customers, unmet needs, product category, benefits, and competitive differentiation. Use this to align stakeholders on strategic positioning before writing PRDs, launch plans, or marketing materials—ensuring you've made deliberate choices about who you serve, what need you address, and how you differ from alternatives.",
    "best_for": [
        "Running a workshop to sharpen product positioning",
        "Clarifying target customer, category, and differentiation",
        "Fixing fuzzy or generic messaging before launch"
    ],
    "scenarios": [
        "Help me run a positioning workshop for our B2B analytics product",
        "Our messaging feels generic. Facilitate a positioning session.",
        "We need to define who we serve and why we're different"
    ],
    "description": "Run a positioning workshop that surfaces target customer, unmet need, category, benefits, and differentiation. Use when your product messaging feels fuzzy, generic, or misaligned.",
    "argument-hint": "[product]"
}

Purpose

Guide product managers through discovering and articulating product positioning by asking adaptive questions about target customers, unmet needs, product category, benefits, and competitive differentiation. Use this to align stakeholders on strategic positioning before writing PRDs, launch plans, or marketing materials—ensuring you've made deliberate choices about who you serve, what need you address, and how you differ from alternatives.

This is not a brainstorming session—it's a structured discovery process that outputs a Geoffrey Moore positioning statement backed by evidence and strategic choices.

Input

Works best with: The product (or feature) whose positioning feels fuzzy. Also useful: Current messaging, who you think the customer is, competitors, and where positioning breaks down today (sales calls, website, launch).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workshop opens by asking about your target customer and proceeds one question at a time.

Example invocation: Run a positioning workshop for our API monitoring tool — we keep getting compared to Datadog and losing.

Key Concepts

The Positioning Workshop Flow

An interactive discovery process that:

  1. Gathers product context (marketing materials, competitor intel)
  2. Identifies target customer segment through questioning
  3. Uncovers underserved needs via Jobs-to-be-Done lens
  4. Defines product category and benefits
  5. Establishes competitive differentiation
  6. Outputs a complete positioning statement (uses positioning-statement.md)

Why This Works

  • Structured discovery: Prevents "positioning by committee" (too vague)
  • Evidence-based: Uses real marketing materials, customer feedback, competitive intel
  • Adaptive: Questions adjust based on B2B vs. B2C, new product vs. repositioning, etc.
  • Actionable output: Generates a Geoffrey Moore positioning statement ready for stakeholder review

Anti-Patterns (What This Is NOT)

  • Not a tagline generator: Positioning ≠ marketing copy
  • Not feature-first: Starts with customer problems, not product capabilities
  • Not consensus-driven: Forces hard choices (can't be "for everyone")

When to Use This

  • Defining positioning for a new product
  • Repositioning an existing product (pivot, market shift)
  • Aligning stakeholders on product strategy
  • Preparing for launch or major release
  • Before writing positioning-dependent artifacts (PRD, press release, sales deck)

When NOT to Use This

  • Before customer research (positioning requires validated insights)
  • For internal tools with captive users (no market positioning needed)
  • When positioning is already clear and validated

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 5 adaptive questions, offering 3-4 enumerated context-aware options at each step.

Interaction pattern: Pair with skills/workshop-facilitation/SKILL.md when you want a one-step-at-a-time flow with numbered recommendations at decision points and quick-select options for regular questions. If the user asks for a single-shot output, skip the multi-turn facilitation.


Step 0: Gather Context (Before Questions)

Agent suggests:

Before we begin, let's gather product context to ground our positioning work:

For Your Own Product:

  • Current website copy (homepage, product pages, value prop)
  • Existing positioning statements or messaging docs
  • Customer testimonials or case studies
  • Sales objections or competitive win/loss analysis
  • Product descriptions or feature lists

For Repositioning an Existing Product:

  • Current positioning (what are you saying today?)
  • Customer feedback or support tickets (what problems do they report?)
  • Competitive intel (how do competitors position themselves?)

If You Don't Have a Product Yet (or Want to Benchmark):

  • Find 2-3 competitor or analog products
  • Copy their website homepage, positioning statements, or value props
  • We'll use these as reference points

You can paste this content directly, or we can proceed with a brief description.


Question 1: Target Customer Segment

Agent asks: "Based on the context provided, who is the primary customer segment you're serving?"

Offer 4 enumerated options (adapted based on product context):

  1. B2B: SMB decision-makers — E.g., "Small business owners (10-50 employees) managing operations" (like Gusto, QuickBooks)
  2. B2B: Enterprise buyers — E.g., "IT/Product leaders at companies with 500+ employees" (like Salesforce, Workday)
  3. B2C: Mass market consumers — E.g., "Gen Z users (18-25) seeking budgeting tools" (like Mint, Venmo)
  4. B2C: Niche enthusiasts — E.g., "Fitness enthusiasts tracking macros and workouts" (like MyFitnessPal, Strava)

Or describe your own target customer segment (be specific: demographics, role, company size, behaviors).

Adaptation tip: If marketing materials mention "enterprises," "SMBs," "consumers," or specific personas, suggest those.

User response: [Selection or custom]


Question 2: Underserved Need (Jobs-to-be-Done)

Agent asks: "What underserved need or pain point does your target customer experience that your product addresses?"

Offer 4 enumerated options (adapted based on Question 1):

Example (if Q1 = B2B SMB decision-makers):

  1. Time-consuming manual work — E.g., "Spend 10+ hours/week on tasks that should be automated" (invoice processing, payroll, reporting)
  2. Lack of visibility or control — E.g., "Can't see real-time status of projects, causing missed deadlines" (project tracking, dashboards)
  3. Compliance or risk burden — E.g., "Fear of tax penalties or legal issues due to manual errors" (accounting, HR compliance)
  4. Costly inefficiency — E.g., "Losing revenue due to slow processes or customer friction" (sales ops, customer onboarding)

Or describe the specific pain point/unmet need based on customer research, support tickets, or competitive gaps.

Adaptation tip: Use language from customer testimonials or case studies in the provided materials.

User response: [Selection or custom]


Question 3: Product Category

Agent asks: "What product category does your solution fit into? (This anchors how buyers evaluate you.)"

Offer 4 enumerated options (adapted based on Q1 + Q2):

Example (if Q1 = B2B SMB, Q2 = Time-consuming manual work):

  1. Workflow automation platform — E.g., "Automates repetitive tasks across apps" (like Zapier, Integromat)
  2. Business management software — E.g., "All-in-one platform for operations (invoicing, payroll, CRM)" (like HubSpot, Zoho)
  3. Vertical SaaS — E.g., "Purpose-built for a specific industry (e.g., HVAC, legal, dental)" (like Jobber, Clio)
  4. AI-powered assistant — E.g., "AI tool that automates workflows via natural language" (like Notion AI, Jasper)

Or define your own category. Note: Creating a new category is risky—pick an existing one unless you have strong rationale.

Adaptation tip: If competitors are in a clear category, default to that unless you're deliberately creating a new one.

User response: [Selection or custom]


Question 4: Key Benefit (Outcome, Not Features)

Agent asks: "What's the primary benefit or outcome your product delivers? (Focus on what the customer gets, not what the product has.)"

Offer 3 enumerated options (adapted based on Q2 need):

Example (if Q2 = Time-consuming manual work):

  1. Time savings — E.g., "Reduces manual work from 10 hours/week to 1 hour" (measurable efficiency)
  2. Error reduction — E.g., "Eliminates 95% of manual data entry errors" (accuracy/risk mitigation)
  3. Cost savings — E.g., "Saves $500/month in labor costs by automating invoicing" (direct ROI)

Or describe the specific, measurable outcome your product delivers.

Quality check: Avoid features ("has AI," "includes dashboards"). Focus on outcomes ("makes decisions 3x faster," "prevents compliance violations").

User response: [Selection or custom]


Question 5: Competitive Differentiation

Agent asks: "What's your primary competitor or competitive alternative, and how do you differ?"

Offer 4 enumerated options (adapted based on Q3 category):

Example (if Q3 = Workflow automation platform):

  1. Incumbent SaaS leader — E.g., "Unlike Zapier (which requires technical setup), we offer no-code visual workflows accessible to non-technical users"
  2. Spreadsheets/manual processes — E.g., "Unlike Excel (which requires manual updates), we provide real-time automated sync across tools"
  3. Vertical competitor — E.g., "Unlike generic automation tools, we're pre-built for [industry] with templates and compliance features"
  4. Enterprise-only solutions — E.g., "Unlike enterprise tools (complex, expensive), we're designed for SMBs with simple pricing and 10-minute setup"

Or describe your primary competitive alternative and your unique differentiation (focus on outcomes, not features).

Adaptation tip: Use competitive intel from provided materials (win/loss analysis, sales objections).

User response: [Selection or custom]


Output: Generate Positioning Statement

After collecting responses, the agent generates a positioning statement using the positioning-statement.md format:

# Positioning Statement

**Based on your responses, here's your positioning statement:**

---

## Value Proposition

**For** [Target customer from Q1]
- **that need** [Underserved need from Q2]
- [Product name]
- **is a** [Product category from Q3]
- **that** [Key benefit from Q4]

---

## Differentiation Statement

- **Unlike** [Primary competitor from Q5]
- [Product name]
- **provides** [Unique differentiation from Q5]

---

## Positioning Summary (One-Sentence Version)

[Product name] is a [category] for [target] that [benefit], unlike [competitor] which [limitation].

**Example:** "Acme Workflows is a no-code automation platform for small business owners that reduces manual work from 10 hours/week to 1 hour, unlike Zapier which requires technical setup and coding knowledge."

---

## Next Steps

1. **Stress-test this positioning:**
   - Read it aloud to 5 target customers. Do they recognize themselves?
   - Share with stakeholders (product, marketing, sales). Does it align?
   - Check if differentiation is defensible (can competitors copy this in 6 months?).

2. **Refine based on feedback:**
   - If target feels too broad → Narrow further (e.g., "SMB owners" → "SMB owners in service industries")
   - If need isn't resonating → Validate with more customer research
   - If category confuses → Pick a clearer category or commit to category creation

3. **Apply to artifacts:**
   - Update website homepage and product pages
   - Revise sales deck and pitch materials
   - Use in PRD, press release, or roadmap planning (reference `press-release.md`, `positioning-statement.md`)

---

**Would you like to refine any part of this positioning, or shall we document it as final?**

Examples

Example 1: Good Positioning Workshop (B2B SaaS Automation)

Step 0 - Context Provided: User shares current website copy:

"Acme Workflows helps small businesses automate repetitive tasks. Connect your apps and save time."

Question 1 Response: "B2B: SMB decision-makers — Small business owners (10-50 employees) managing operations"

Question 2 Response: "Time-consuming manual work — Spend 10+ hours/week on invoice processing, data entry, reporting"

Question 3 Response: "Workflow automation platform — Automates repetitive tasks across apps"

Question 4 Response: "Time savings — Reduces manual work from 10 hours/week to 1 hour"

Question 5 Response: "Incumbent SaaS leader — Unlike Zapier (which requires technical setup), we offer no-code visual workflows accessible to non-technical users"


Generated Positioning Statement:

## Value Proposition

**For** small business owners (10-50 employees) managing daily operations
- **that need** to eliminate 10+ hours/week spent on manual tasks like invoice processing, data entry, and reporting
- Acme Workflows
- **is a** no-code workflow automation platform
- **that** reduces manual work from 10 hours/week to 1 hour by automating repetitive tasks across apps

## Differentiation Statement

- **Unlike** Zapier, which requires technical setup and coding knowledge
- Acme Workflows
- **provides** visual, no-code workflows that non-technical business owners can set up in 10 minutes

## Positioning Summary

Acme Workflows is a no-code automation platform for small business owners that reduces manual work from 10 hours/week to 1 hour, unlike Zapier which requires technical setup and coding knowledge.

Why this works:

  • Target is specific (SMB owners, 10-50 employees, operations focus)
  • Need is measurable (10+ hours/week on manual tasks)
  • Category is clear (workflow automation)
  • Benefit is outcome-focused (10 hours → 1 hour)
  • Differentiation is defensible (no-code vs. technical setup)

Example 2: Bad Positioning Workshop (Vague)

Question 1 Response: "Businesses" Question 2 Response: "Need better tools" Question 3 Response: "Software" Question 4 Response: "Productivity" Question 5 Response: "We're better than competitors"

Generated Positioning Statement:

**For** businesses
- **that need** better tools
- ProductX
- **is a** software
- **that** improves productivity

**Unlike** competitors
- ProductX
- **provides** better features

Why this fails:

  • Target is too broad ("businesses" = everyone)
  • Need is vague ("better tools" = meaningless)
  • Category is not specific ("software" says nothing)
  • Benefit is unmeasurable ("productivity" = how much?)
  • Differentiation is empty ("better features" = unverifiable)

How to fix: Go back and answer with specificity. Use customer research, not guesses.


Common Pitfalls

Pitfall 1: "For Everyone"

Symptom: Target is "all businesses" or "anyone who wants to be productive"

Consequence: Positioning becomes invisible—no one feels it's for them.

Fix: Narrow ruthlessly. Pick the first customer segment. You can expand later.


Pitfall 2: Need is a Feature Request

Symptom: "Need better dashboards" or "Need AI-powered analytics"

Consequence: You've jumped to solution, not problem.

Fix: Ask "Why do they need that?" Keep asking until you hit the root need.


Pitfall 3: Category Confusion

Symptom: "We're a next-generation platform for digital transformation"

Consequence: Buyers don't know how to evaluate you.

Fix: Pick a category buyers understand. If creating a new one, budget for category education.


Pitfall 4: Differentiation is a Feature

Symptom: "Unlike competitors, we have AI"

Consequence: Features are copiable. Not durable differentiation.

Fix: Focus on outcomes: "Unlike competitors, we reduce setup time from 2 hours to 10 minutes."


Pitfall 5: No Customer Validation

Symptom: Positioning created in a vacuum, never tested with customers

Consequence: It sounds good internally but doesn't resonate externally.

Fix: Read positioning statement to 5 target customers. If they don't say "Yes, that's me," revise.


References

Related Skills

  • positioning-statement.md — The output format this workshop generates
  • proto-persona.md — Defines the "For [target]" segment
  • jobs-to-be-done.md — Informs the "that need" statement
  • problem-statement.md — Problem framing supports positioning
  • press-release.md — Positioning informs press release messaging

External Frameworks

  • Geoffrey Moore, Crossing the Chasm (1991) — Origin of positioning statement format
  • April Dunford, Obviously Awesome (2019) — Modern positioning methodology

Dean's Work

  • Positioning Statement Prompt Template

Skill type: Interactive Suggested filename: positioning-workshop.md Suggested placement: /skills/interactive/ Dependencies: Uses positioning-statement.md, references proto-persona.md, jobs-to-be-done.md, problem-statement.md

引导产品经理将碎片化发现转化为结构化PRD,涵盖问题定义、用户研究、解决方案及成功标准。旨在对齐利益相关者,提供工程上下文,避免范围蔓延和模糊性,作为项目唯一事实来源。
需要编写或重构产品需求文档 将探索笔记整理为工程就绪文档 明确功能的问题陈述与成功指标
skills/prd-development/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill prd-development -g -y
SKILL.md
Frontmatter
{
    "name": "prd-development",
    "type": "workflow",
    "theme": "pm-artifacts",
    "intent": "Guide product managers through structured PRD (Product Requirements Document) creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document. Use this to move from scattered notes and Slack threads to a clear, comprehensive PRD that aligns stakeholders, provides engineering context, and serves as a source of truth—avoiding ambiguity, scope creep, and the \"build what's in my head\" trap.",
    "best_for": [
        "Writing a complete PRD from scratch",
        "Structuring product requirements for an engineering handoff",
        "Documenting a major new feature before development begins"
    ],
    "scenarios": [
        "I need a PRD for a new AI-powered recommendation feature in our e-commerce platform",
        "I've completed a discovery sprint and need to turn the findings into a PRD my engineers can act on"
    ],
    "description": "Build a structured PRD that connects problem, users, solution, and success criteria. Use when turning discovery notes into an engineering-ready document for a major initiative.",
    "argument-hint": "[feature or initiative]",
    "estimated_time": "60-120 min"
}

Purpose

Guide product managers through structured PRD (Product Requirements Document) creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document. Use this to move from scattered notes and Slack threads to a clear, comprehensive PRD that aligns stakeholders, provides engineering context, and serves as a source of truth—avoiding ambiguity, scope creep, and the "build what's in my head" trap.

This is not a waterfall spec—it's a living document that captures strategic context, customer problems, proposed solutions, and success criteria, evolving as you learn through delivery.

Input

Works best with: The feature or initiative the PRD covers. Also useful: Discovery notes, problem statements, user research, success metrics, and constraints — paste whatever exists; the workflow slots it into the right phases and skips what's already answered.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workflow starts at problem definition and builds up from there.

Example invocation: Build a PRD for self-serve workspace provisioning — here are my discovery notes and the OKR it ladders to.

Key Concepts

What is a PRD?

A PRD (Product Requirements Document) is a structured document that answers:

  1. What problem are we solving? (Problem statement)
  2. For whom? (Target users/personas)
  3. Why now? (Strategic context, business case)
  4. What are we building? (Solution overview)
  5. How will we measure success? (Metrics, success criteria)
  6. What are the requirements? (User stories, acceptance criteria, constraints)
  7. What are we NOT building? (Out of scope)

PRD Structure (Standard Template)

# [Feature/Product Name] PRD

## 1. Executive Summary
- One-paragraph overview (problem + solution + impact)

## 2. Problem Statement
- Who has this problem?
- What is the problem?
- Why is it painful?
- Evidence (customer quotes, data, research)

## 3. Target Users & Personas
- Primary persona(s)
- Secondary persona(s)
- Jobs-to-be-done

## 4. Strategic Context
- Business goals (OKRs)
- Market opportunity (TAM/SAM/SOM)
- Competitive landscape
- Why now?

## 5. Solution Overview
- High-level description
- User flows or wireframes
- Key features

## 6. Success Metrics
- Primary metric (what we're optimizing for)
- Secondary metrics
- Targets (current → goal)

## 7. User Stories & Requirements
- Epic hypothesis
- User stories with acceptance criteria
- Edge cases, constraints

## 8. Out of Scope
- What we're NOT building (and why)

## 9. Dependencies & Risks
- Technical dependencies
- External dependencies (integrations, partnerships)
- Risks and mitigations

## 10. Open Questions
- Unresolved decisions
- Areas requiring discovery

Why This Works

  • Alignment: Ensures everyone (PM, design, eng, stakeholders) understands the "why"
  • Context preservation: Captures research and strategic rationale for future reference
  • Decision log: Documents what's in scope, out of scope, and why
  • Execution clarity: Provides engineering with user stories and acceptance criteria

Anti-Patterns (What This Is NOT)

  • Not a detailed spec: PRDs frame the problem and solution; they don't specify UI pixel-by-pixel
  • Not waterfall: PRDs evolve as you learn; they're not frozen contracts
  • Not a substitute for collaboration: PRDs complement conversation, not replace it

When to Use This

  • Starting a major feature or product initiative
  • Aligning cross-functional teams on scope and requirements
  • Documenting decisions for future reference
  • Onboarding new team members to a project

When NOT to Use This

  • For small bug fixes or trivial features (overkill)
  • When problem and solution are already clear and aligned (just write user stories)
  • For continuous discovery experiments (use Lean UX Canvas instead)

Facilitation Source of Truth

When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.

Application

Use template.md as the fill-in document. The template includes:

  • Per-section coaching blocks — each section has its own Instructions, Steps, Contributing Skills, and Activities so the template is self-guiding even without this workflow.
  • Inline gap tagging — tag every gap as 🔶 Assumption (plausible but unvalidated) or 🔵 Open Question (unknown, needs discovery). Tag inline where the gap appears, not just at the end.
  • Cross-section recommendation prompts — after completing each section, a "Before moving on" block checks consistency with prior sections and warns about what the next section will need.
  • Self-assessment — after Section 10, a diagnostic captures the strongest section, weakest section, top assumptions to validate, and the recommended next step before sharing the PRD.
  • Skill cross-reference table — maps 15 skills to the specific sections they feed (e.g., problem-framing-canvas → Section 2, epic-breakdown-advisor → Section 7).

This workflow orchestrates 8 phases over 2-4 days, using multiple component and interactive skills. The phases below describe the facilitation sequence; the template captures the output.


Phase 1: Executive Summary (30 minutes)

Goal: Write a one-paragraph overview for skimmers.

Activities

1. Draft Executive Summary

  • Format: "We're building [solution] for [persona] to solve [problem], which will result in [impact]."

  • Example:

    "We're building a guided onboarding checklist for non-technical small business owners to solve the problem of 60% drop-off in the first 24 hours due to lack of guidance, which will increase activation rate from 40% to 60% and reduce churn by 10%."

  • Participants: PM

  • Duration: 30 minutes

  • Output: One-paragraph summary

Tip: Write this first (forces clarity), but refine it last (after other sections are complete).


Phase 2: Problem Statement (60 minutes)

Goal: Frame the customer problem with evidence.

Activities

1. Write Problem Statement

  • Use: skills/problem-statement/SKILL.md (component)
  • Input: Discovery insights from skills/discovery-process/SKILL.md or skills/problem-framing-canvas/SKILL.md
  • Participants: PM
  • Duration: 30 minutes
  • Output: Structured problem statement

Example Problem Statement:

## 2. Problem Statement

### Who has this problem?
Non-technical small business owners (solopreneurs, 1-10 employees) who sign up for our SaaS product.

### What is the problem?
60% of users abandon onboarding within the first 24 hours because they don't know what to do first. They see an empty dashboard with no guidance, get overwhelmed by options, and leave.

### Why is it painful?
- **User impact:** Wastes time (30-60 min trying to figure out product), never reaches "aha moment," churns before experiencing value
- **Business impact:** 60% activation rate → high churn, low LTV, poor word-of-mouth

### Evidence
- **Interviews:** 8/10 churned users said "I didn't know what to do first" (discovery interviews, Feb 2026)
- **Analytics:** 60% of signups complete 0 actions within 24 hours (Mixpanel, Jan 2026)
- **Support tickets:** "How do I get started?" is #1 support question (350 tickets/month)
- **Customer quote:** "I logged in, saw an empty dashboard, and thought 'now what?' I gave up and went back to my spreadsheet."

2. Add Supporting Context (Optional)

  • Customer journey map: If problem spans multiple touchpoints
  • Use: skills/customer-journey-mapping-workshop/SKILL.md output
  • Jobs-to-be-done: If motivations are key
  • Use: skills/jobs-to-be-done/SKILL.md output

Outputs from Phase 2

  • Problem statement: Who, what, why, evidence
  • Supporting artifacts: Journey map, JTBD (if relevant)

Phase 3: Target Users & Personas (30 minutes)

Goal: Define who you're building for.

Activities

1. Document Personas

  • Use: skills/proto-persona/SKILL.md (component) output
  • Participants: PM
  • Duration: 30 minutes
  • Format: Include persona name, role, goals, pain points, behaviors

Example:

## 3. Target Users & Personas

### Primary Persona: Solo Entrepreneur Sam
- **Role:** Freelance consultant, solopreneur
- **Company size:** 1 person (no IT support)
- **Tech savviness:** Low (uses email, spreadsheets, basic SaaS)
- **Goals:** Get value from software fast without technical expertise
- **Pain points:** Overwhelmed by complex UIs, no time to watch tutorials, needs immediate value
- **Current behavior:** Signs up for products, tries for 1 day, churns if not immediately useful

### Secondary Persona: Small Business Owner (5-10 employees)
- **Role:** Owner-operator, manages team
- **Needs:** Onboard team members quickly
- **Differs from primary:** More tolerant of complexity, willing to invest setup time

Outputs from Phase 3

  • Primary persona: Detailed profile
  • Secondary personas: (if applicable)

Phase 4: Strategic Context (45 minutes)

Goal: Explain why this matters to the business and why now.

Activities

1. Document Business Goals

  • Source: Company OKRs, strategic memos, roadmap
  • Format: Link feature to business outcomes
  • Example:

    "This initiative supports our Q1 OKR: Reduce churn from 15% to 8%. Improving onboarding activation directly impacts retention."

2. Size Market Opportunity (Optional)

  • Use: skills/tam-sam-som-calculator/SKILL.md (interactive) output
  • When: For major initiatives, new products, exec presentations
  • Example:

    "TAM: 50M small businesses globally. SAM: 5M using SaaS tools. SOM: 500K solopreneurs in our target segments. Improving onboarding could unlock 30% of SAM (1.5M potential customers)."

3. Document Competitive Landscape (Optional)

  • Source: Competitor research, G2/Capterra reviews
  • Example:

    "Competitors (Competitor A, B) have guided onboarding. Our lack of guidance is cited as a churn reason in exit surveys."

4. Explain "Why Now?"

  • Rationale: Why prioritize this now vs. later?
  • Example:

    "Churn spiked 15% in Q4. Onboarding is the #1 driver (60% churn in first 30 days). Fixing this is critical to hitting retention OKR."

Outputs from Phase 4

  • Business goals: OKRs or strategic initiatives
  • Market opportunity: TAM/SAM/SOM (if applicable)
  • Competitive context: How competitors address this
  • Why now: Urgency rationale

Phase 5: Solution Overview (60 minutes)

Goal: Describe what you're building (high-level, not detailed spec).

Activities

1. Write Solution Description

  • Format: High-level overview, 2-3 paragraphs
  • Example:
## 5. Solution Overview

We're building a **guided onboarding checklist** that walks new users through core workflows step-by-step when they first log in.

**How it works:**
1. User signs up and logs in for the first time
2. Modal appears: "Let's get you set up! Complete these 3 steps to get started."
3. Checklist shows:
   - ☐ Create your first project
   - ☐ Invite a teammate (optional)
   - ☐ Complete a sample task
4. As user completes each step, checklist updates with checkmarks
5. After completion, celebration modal: "You're all set! Here's what to do next."

**Key features:**
- Minimal: Only 3 core steps (not overwhelming)
- Dismissible: Users can skip if they prefer to explore
- Progress tracking: Visual progress bar (1/3, 2/3, 3/3)
- Celebration: Positive reinforcement when complete

2. Add User Flows or Wireframes (Optional)

  • Use: Design tools (Figma, Sketch), or hand-drawn sketches
  • When: For complex features requiring visual explanation
  • Output: Embedded in PRD or linked

3. Reference Story Map (Optional)

  • Use: skills/user-story-mapping-workshop/SKILL.md output
  • When: For complex features with multiple release slices
  • Output: Link to story map

Outputs from Phase 5

  • Solution description: High-level overview
  • User flows/wireframes: (if applicable)
  • Story map: (if applicable)

Phase 6: Success Metrics (30 minutes)

Goal: Define how you'll measure success.

Activities

1. Define Primary Metric

  • Question: What is the ONE metric this feature must move?
  • Example: "Activation rate (% of users completing first action within 24 hours)"
  • Target: "Increase from 40% to 60%"

2. Define Secondary Metrics

  • Question: What else should we monitor (but not optimize for)?
  • Examples:
    • Time-to-first-action (reduce from 3 days to 1 day)
    • Completion rate of onboarding checklist (target: 80%)
    • Support ticket volume (reduce "How do I get started?" tickets by 50%)

3. Define Guardrail Metrics

  • Question: What should NOT get worse?
  • Example: "Sign-up conversion rate (don't add friction to signup flow)"

Example:

## 6. Success Metrics

### Primary Metric
**Activation rate** (% of users completing first action within 24 hours)
- **Current:** 40%
- **Target:** 60%
- **Timeline:** Measure 30 days after launch

### Secondary Metrics
- **Time-to-first-action:** Reduce from 3 days to 1 day
- **Onboarding checklist completion rate:** 80% of users complete all 3 steps
- **Support tickets:** Reduce "How do I get started?" tickets from 350/month to 175/month

### Guardrail Metrics
- **Sign-up conversion rate:** Maintain at 10% (don't add friction to signup)

Outputs from Phase 6

  • Primary metric: What you're optimizing for
  • Secondary metrics: Additional success indicators
  • Guardrail metrics: What shouldn't regress

Phase 7: User Stories & Requirements (90-120 minutes)

Goal: Break solution into user stories with acceptance criteria.

Activities

1. Write Epic Hypothesis

  • Use: skills/epic-hypothesis/SKILL.md (component)
  • Participants: PM
  • Duration: 30 minutes
  • Output: Epic hypothesis statement

Example:

"We believe that adding a guided onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance. We'll measure success by activation rate 30 days post-launch."

2. Break Down Epic into User Stories

  • Use: skills/epic-breakdown-advisor/SKILL.md (interactive - with Richard Lawrence's 9 patterns)
  • Participants: PM, design, engineering
  • Duration: 90 minutes
  • Output: User stories split by patterns (workflow, CRUD, business rules, etc.)

3. Write User Stories

  • Use: skills/user-story/SKILL.md (component)
  • Participants: PM
  • Duration: 30 minutes per story
  • Format: User story + acceptance criteria

Example User Stories:

## 7. User Stories & Requirements

### Epic Hypothesis
We believe that adding a guided onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.

### User Stories

**Story 1: Display onboarding checklist on first login**
As a new user, I want to see a guided checklist when I first log in, so I know what to do first.

**Acceptance Criteria:**
- [ ] When user logs in for the first time, modal appears with checklist
- [ ] Checklist shows 3 steps: "Create project," "Invite teammate," "Complete task"
- [ ] Modal is dismissible (close button)
- [ ] If dismissed, checklist doesn't reappear (user preference saved)

**Story 2: Track checklist progress**
As a new user, I want to see my progress as I complete checklist steps, so I feel a sense of accomplishment.

**Acceptance Criteria:**
- [ ] When user completes step 1, checkmark appears next to "Create project"
- [ ] Progress bar updates (1/3 → 2/3 → 3/3)
- [ ] Checklist persists across sessions (if user logs out and back in)

**Story 3: Celebrate checklist completion**
As a new user, I want to receive positive feedback when I complete the checklist, so I feel confident using the product.

**Acceptance Criteria:**
- [ ] When user completes all 3 steps, celebration modal appears
- [ ] Message: "You're all set! Here's what to do next: [suggested next actions]"
- [ ] Confetti animation (optional, nice-to-have)

4. Document Constraints & Edge Cases

  • Technical constraints: Platform limitations, browser support, etc.
  • Edge cases: What if user skips step 2? What if they complete steps out of order?

Outputs from Phase 7

  • Epic hypothesis: Testable statement
  • User stories: 3-10 stories with acceptance criteria
  • Constraints: Technical limitations, edge cases

Phase 8: Out of Scope & Dependencies (30 minutes)

Goal: Define what you're NOT building and what you depend on.

Activities

1. Document Out of Scope

  • Format: List features/requests explicitly excluded
  • Rationale: Why not building now?

Example:

## 8. Out of Scope

**Not included in this release:**
- **Advanced onboarding personalization** (e.g., different checklists per persona) — Adds complexity, test simple version first
- **Video tutorials embedded in checklist** — Resource-intensive, validate checklist concept first
- **Gamification (badges, points)** — Nice-to-have, focus on core workflow guidance

**Future consideration:**
- Mobile-optimized onboarding (desktop-first for now)

2. Document Dependencies

  • Technical dependencies: Platform upgrades, API changes required
  • External dependencies: Third-party integrations, partnerships
  • Team dependencies: Design handoff, data pipeline work

Example:

## 9. Dependencies & Risks

### Dependencies
- **Design:** Wireframes for checklist UI (ETA: Week 1)
- **Engineering:** No technical dependencies (uses existing modals framework)

### Risks & Mitigations
- **Risk:** Users dismiss checklist immediately, never see it
  - **Mitigation:** Track dismissal rate; if >50%, iterate on messaging or timing
- **Risk:** Checklist steps are too generic, don't resonate with all personas
  - **Mitigation:** Start with primary persona (Solo Entrepreneur Sam), personalize later

3. Document Open Questions

  • Unresolved decisions: Areas requiring discovery or discussion

Example:

## 10. Open Questions

- Should checklist be mandatory or optional? (Decision: Optional, dismissible)
- Should we A/B test checklist vs. no checklist? (Decision: Yes, show to 50% of new users)
- What happens if user completes steps out of order? (Decision: Allow any order, update checklist dynamically)

Outputs from Phase 8

  • Out of scope: What we're NOT building
  • Dependencies: What we need before starting
  • Risks: Potential blockers and mitigations
  • Open questions: Unresolved decisions

Complete Workflow: End-to-End Summary

Day 1:
├─ Phase 1: Executive Summary (30 min)
├─ Phase 2: Problem Statement (60 min)
│  └─ Use: skills/problem-statement/SKILL.md
├─ Phase 3: Target Users & Personas (30 min)
│  └─ Use: skills/proto-persona/SKILL.md
└─ Phase 4: Strategic Context (45 min)
   └─ Use: skills/tam-sam-som-calculator/SKILL.md (optional)

Day 2:
├─ Phase 5: Solution Overview (60 min)
│  └─ Use: skills/user-story-mapping-workshop/SKILL.md (optional)
├─ Phase 6: Success Metrics (30 min)
└─ Phase 7: User Stories & Requirements (90-120 min)
   ├─ Use: skills/epic-hypothesis/SKILL.md
   ├─ Use: skills/epic-breakdown-advisor/SKILL.md
   └─ Use: skills/user-story/SKILL.md

Day 3:
├─ Phase 8: Out of Scope & Dependencies (30 min)
└─ Review & Refine (60 min)
   └─ Read full PRD, polish, get feedback

Day 4 (Optional):
└─ Stakeholder Review & Approval
   └─ Present PRD to stakeholders, incorporate feedback

Total Time Investment:

  • Fast track: 1.5-2 days (straightforward feature, clear requirements)
  • Typical: 2-3 days (includes discovery synthesis, stakeholder review)
  • Complex: 3-4 days (major initiative, multiple personas, extensive user stories)

Examples

See examples/sample.md for full PRD examples.

Mini example excerpt:

## 2. Problem Statement
- 60% of trial users drop off in first 24 hours
## 6. Success Metrics
- Activation rate: 40% → 60%

Common Pitfalls

Pitfall 1: PRD Written in Isolation

Symptom: PM writes PRD alone, presents finished doc to team

Consequence: No buy-in, team doesn't understand rationale

Fix: Collaborate on Phase 7 (user stories) with design + eng; review draft PRD before finalizing


Pitfall 2: No Evidence in Problem Statement

Symptom: "We believe users have this problem" (no data, no quotes)

Consequence: Team questions whether problem is real

Fix: Use discovery insights from skills/discovery-process/SKILL.md; include customer quotes, analytics, support tickets


Pitfall 3: Solution Too Prescriptive

Symptom: PRD specifies exact UI, pixel dimensions, button colors

Consequence: Removes design collaboration, becomes waterfall spec

Fix: Keep Phase 5 high-level; let design own UI details


Pitfall 4: No Success Metrics

Symptom: PRD defines problem + solution but no metrics

Consequence: Can't validate if feature succeeded

Fix: Always define primary metric in Phase 6 (what you're optimizing for)


Pitfall 5: Out of Scope Not Documented

Symptom: No section on what's NOT being built

Consequence: Scope creep, stakeholders expect features not planned

Fix: Explicitly document out of scope in Phase 8


References

Related Skills (Orchestrated by This Workflow)

Phase 2:

  • skills/problem-statement/SKILL.md (component)
  • skills/problem-framing-canvas/SKILL.md (interactive, for context)
  • skills/customer-journey-mapping-workshop/SKILL.md (interactive, optional)

Phase 3:

  • skills/proto-persona/SKILL.md (component)
  • skills/jobs-to-be-done/SKILL.md (component, optional)

Phase 4:

  • skills/tam-sam-som-calculator/SKILL.md (interactive, optional)

Phase 5:

  • skills/user-story-mapping-workshop/SKILL.md (interactive, optional)

Phase 7:

  • skills/epic-hypothesis/SKILL.md (component)
  • skills/epic-breakdown-advisor/SKILL.md (interactive)
  • skills/user-story/SKILL.md (component)

External Frameworks

  • Martin Eriksson, "How to Write a Good PRD" (2012) — PRD structure
  • Marty Cagan, Inspired (2017) — Product spec principles
  • Amazon, "Working Backwards" (PR/FAQ format) — Alternative to PRD

Dean's Work

  • [If Dean has PRD templates, link here]

Skill type: Workflow Suggested filename: prd-development.md Suggested placement: /skills/workflows/ Dependencies: Orchestrates 8+ component and interactive skills across 8 phases

基于亚马逊“逆向工作法”,在开发前撰写愿景型新闻稿。用于明确客户价值、对齐利益相关者,通过模拟发布测试产品故事吸引力,聚焦问题解决而非功能罗列,确保以客户为中心的产品规划。
需要定义新产品或功能的客户价值主张 需要在开发前对齐利益相关者 使用亚马逊逆向工作法进行产品规划
skills/press-release/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill press-release -g -y
SKILL.md
Frontmatter
{
    "name": "press-release",
    "type": "component",
    "intent": "Create a visionary press release following Amazon's \"Working Backwards\" methodology to define and communicate a product or feature before building it. Use this to align stakeholders on the customer value proposition, clarify the problem being solved, and test if the product story resonates—treating the press release as a forcing function for clarity and customer-centricity.",
    "description": "Write an Amazon-style press release that defines customer value before building. Use when aligning stakeholders on a new product, feature, or strategic bet.",
    "argument-hint": "[product or feature idea]"
}

Purpose

Create a visionary press release following Amazon's "Working Backwards" methodology to define and communicate a product or feature before building it. Use this to align stakeholders on the customer value proposition, clarify the problem being solved, and test if the product story resonates—treating the press release as a forcing function for clarity and customer-centricity.

This is not a marketing artifact for launch day—it's a planning tool that asks "If we shipped this perfectly, how would we explain it to the world?"

Input

Works best with: The product or feature idea, plus who it's for. Also useful: The customer problem, the headline benefit, and an internal quote-worthy point of view.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks who the customer is and what changes for them on launch day — the two things a working-backwards press release cannot fake.

Example invocation: Amazon-style press release: instant expense approval for field technicians, launching Q3.

Key Concepts

The Amazon Working Backwards Framework

Popularized by Amazon, the Working Backwards process starts with a press release and FAQ before any code is written. The press release must:

  • Be written from the customer's perspective
  • Focus on the problem solved, not the features built
  • Be short (1-1.5 pages)
  • Be compelling enough that customers would want the product

Press Release Structure

A standard press release follows this format:

  1. Headline: Clear, benefit-focused product announcement
  2. Dateline: City, state, date
  3. Introduction paragraph: What's being launched, who it's for, key benefit
  4. Problem paragraph: Customer problem the product solves
  5. Solution paragraph: How the product addresses the problem (outcomes, not features)
  6. Quote from company leader: Vision, customer commitment
  7. Additional details: Supporting benefits or data
  8. Boilerplate: Company background
  9. Call to action: How to learn more
  10. Media contact: Press contact information

Why This Works

  • Customer-first thinking: Forces you to articulate value from the customer's perspective
  • Clarity forcing function: If you can't write a compelling press release, the product idea may be weak
  • Alignment tool: Stakeholders can read and react to the vision before engineering starts
  • Decision filter: If a feature wouldn't make it into the press release, question its priority

Anti-Patterns (What This Is NOT)

  • Not feature-centric: Don't list specs—focus on customer outcomes
  • Not internal jargon: Write for customers, not engineers
  • Not vague: "Revolutionizes productivity" is fluff; "Reduces report generation time from 8 hours to 10 minutes" is real
  • Not marketing spin: Be honest about what the product does

When to Use This

  • Defining a new product or major feature
  • Aligning stakeholders on vision before development
  • Testing if a product idea is compelling
  • Pitching to execs or securing buy-in

When NOT to Use This

  • For trivial features (don't over-engineer small tweaks)
  • After you've already built the product (too late)
  • As actual launch-day press release (this is a planning doc, not final marketing copy)

Application

Use template.md for the full fill-in structure.

Step 1: Gather Context

Before drafting, ensure you have:

  • Product/feature description: What are you building?
  • Target customer/persona: Who is this for? (reference skills/proto-persona/SKILL.md)
  • Problem statement: What customer problem does this solve? (reference skills/problem-statement/SKILL.md)
  • Key benefits: What outcomes does it deliver?
  • Competitive context: How is this different from alternatives? (reference skills/positioning-statement/SKILL.md)
  • Company mission/values: How does this fit the company's vision?

If missing context: Run discovery, define the problem statement, or clarify positioning first.


Step 2: Draft the Headline

Create a clear, benefit-focused headline:

"[Product/Feature Name] by [Company] Aims to [Main Benefit/Goal]"

Quality checks:

  • Benefit-focused: Does it say what the customer gets, not just what you built?
  • Specific: "Aims to simplify workflows" is vague; "Aims to cut invoice processing time by 60%" is specific
  • Memorable: Can someone repeat this headline in a conversation?

Examples:

  • ✅ "Acme Workflows Launches Invoice Automation to Cut Processing Time by 60% for Small Businesses"
  • ❌ "Acme Launches New Product with AI Features"

Step 3: Write the Dateline and Introduction

[City], [State], [Country], [Date] —

Today, [Company], a [type of organization], announced [key news], a [brief description]. This [product/feature] is set to [main benefit], addressing [key customer problem].

Quality checks:

  • Concise: 2-3 sentences max
  • Customer problem mentioned: Don't jump to solution—name the problem first

Step 4: Explain the Problem

[Product/feature] solves [specific customer problem]. According to [source or customer insight], [supporting data or quote that validates the problem].

Quality checks:

  • Specific problem: Not "inefficiency" but "manual invoice processing takes 8 hours per month"
  • Validated: Include data, customer quotes, or research to prove the problem is real

Step 5: Describe the Solution (Outcome-Focused)

[Product/feature] addresses this by [how it solves the problem—focus on outcomes]. [Quote from company leader]: "[Insert quote that emphasizes customer value, not features]."

Quality checks:

  • Outcome-first: "Reduces processing time" not "includes OCR technology"
  • Quote is visionary: Should reflect customer empathy and company values

Step 6: Add Supporting Details

In addition to [key benefit], [product/feature] also [additional benefits]. According to [statistic or source], [supporting data].

Quality checks:

  • Data-driven: Use numbers where possible (time savings, cost reduction, etc.)
  • Customer-centric: Still focused on "what they get," not "what we built"

Step 7: Include Boilerplate

[Company], founded in [year], is a [type of company] known for [main products/services]. With a focus on [company mission or values], [Company] has [achievements or milestones].

Step 8: Add Call to Action and Media Contact

For more information about [product/feature], visit [website] or contact [media contact name] at [contact info].

**Media Contact Information:**
[Name]
Title: [Title]
Phone: [Phone]
Email: [Email]

Step 9: Test the Press Release

Ask these questions:

  1. Would a customer care? If you sent this to a target customer, would they want to learn more?
  2. Is the problem clear? Can someone who's never heard of your product understand the pain point?
  3. Are benefits measurable? Can you prove the claims (time savings, cost reduction, etc.)?
  4. Is it jargon-free? Could your mom understand it?
  5. Does it pass the "so what?" test? If someone reads this and says "so what?" you haven't articulated value.

If any answer is "no," revise.


Examples

See examples/sample.md for full press release examples.

Mini example excerpt:

**Headline:** "Acme Launches SmartInvoice to Cut Processing Time by 60%"
**Problem:** Small businesses spend 8 hours/month on manual invoices
**Solution:** Automates extraction and approvals to save time

Common Pitfalls

Pitfall 1: Feature List Instead of Benefits

Symptom: "Includes AI, ML, OCR, NLP, and real-time sync"

Consequence: Customers don't care about features—they care about outcomes.

Fix: Translate features to benefits: "AI-powered automation reduces invoice processing time by 60%."


Pitfall 2: Vague Problem Statement

Symptom: "Solves inefficiency in workflows"

Consequence: No one recognizes themselves in this problem.

Fix: Be specific: "Small business owners spend 8 hours/month manually entering invoice data."


Pitfall 3: Jargon-Heavy Language

Symptom: "Leverages cutting-edge ML models to optimize enterprise-grade workflows"

Consequence: Customers can't understand what you're saying.

Fix: Write like you're explaining it to a friend: "Automatically handles invoices so you don't have to."


Pitfall 4: Generic Executive Quote

Symptom: "We're excited to bring innovation to market"

Consequence: Quote adds no value. Could apply to any product.

Fix: Make it customer-focused: "Business owners shouldn't spend weekends processing invoices—they should spend that time with family."


Pitfall 5: No Data or Validation

Symptom: "Customers will love this revolutionary new solution"

Consequence: Unsubstantiated claims = marketing fluff.

Fix: Add data: "Beta users saved an average of 5 hours per month" or "68% of SMBs cite invoice processing as their top admin burden."


References

Related Skills

  • skills/problem-statement/SKILL.md — Defines the customer problem the press release highlights
  • skills/positioning-statement/SKILL.md — Informs the differentiation and value proposition
  • skills/proto-persona/SKILL.md — Defines the target customer mentioned in the press release
  • skills/jobs-to-be-done/SKILL.md — Informs the customer benefits and outcomes

External Frameworks

  • Amazon's Working Backwards process — Origin of the press release-first methodology
  • Ian McAllister's Quora answer on Amazon's press release template (2012) — Widely cited explanation
  • Colin Bryar & Bill Carr, Working Backwards (2021) — Book on Amazon's product development process

Dean's Work

  • Visionary Press Release Prompt (inspired by Amazon's Working Backwards methodology)

Provenance

  • Adapted from prompts/visionary-press-release.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: press-release.md Suggested placement: /skills/components/ Dependencies: References skills/problem-statement/SKILL.md, skills/positioning-statement/SKILL.md, skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md

指导产品经理根据产品阶段、团队背景和利益相关者需求,选择最合适的优先级排序框架(如RICE、ICE等),避免框架滥用或误用,提供定制化实施建议。
需要选择优先级排序框架时 当前框架不适用需切换时 新产品阶段确定优先策略时
skills/prioritization-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill prioritization-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "prioritization-advisor",
    "type": "interactive",
    "intent": "Guide product managers in choosing the right prioritization framework by asking adaptive questions about product stage, team context, decision-making needs, and stakeholder dynamics. Use this to avoid \"framework whiplash\" (switching frameworks constantly) or applying the wrong framework (e.g., using RICE for strategic bets or ICE for data-driven decisions). Outputs a recommended framework with implementation guidance tailored to your context.",
    "best_for": [
        "Choosing the right prioritization framework for a team or stage",
        "Deciding between RICE, ICE, value\/effort, and similar models",
        "Reducing debate about how to prioritize competing work"
    ],
    "scenarios": [
        "Which prioritization framework should my startup use right now?",
        "Help me choose between RICE and value\/effort for roadmap planning",
        "We keep arguing about prioritization. Recommend a framework."
    ],
    "description": "Choose a prioritization framework based on stage, team context, and stakeholder needs. Use when deciding between RICE, ICE, value\/effort, or another scoring approach.",
    "argument-hint": "[decision context]"
}

Purpose

Guide product managers in choosing the right prioritization framework by asking adaptive questions about product stage, team context, decision-making needs, and stakeholder dynamics. Use this to avoid "framework whiplash" (switching frameworks constantly) or applying the wrong framework (e.g., using RICE for strategic bets or ICE for data-driven decisions). Outputs a recommended framework with implementation guidance tailored to your context.

This is not a scoring calculator—it's a decision guide that matches prioritization frameworks to your specific situation.

Input

Works best with: What you're trying to prioritize and why now (sprint planning, roadmap, stakeholder fight). Also useful: Product stage, team size, data availability, and frameworks you've tried that failed.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking about your product stage and the decision you need the framework to make.

Example invocation: Help me pick a framework: seed-stage B2B startup, 40-item backlog, zero usage data, loud enterprise prospect.

Key Concepts

The Prioritization Framework Landscape

Common frameworks and when to use them:

Scoring frameworks:

  • RICE (Reach, Impact, Confidence, Effort) — Data-driven, requires metrics
  • ICE (Impact, Confidence, Ease) — Lightweight, gut-check scoring
  • Value vs. Effort (2x2 matrix) — Quick wins vs. strategic bets
  • Weighted Scoring — Custom criteria with stakeholder input

Strategic frameworks:

  • Kano Model — Classify features by customer delight (basic, performance, delight)
  • Opportunity Scoring — Rate importance vs. satisfaction gap
  • Buy-a-Feature — Customer budget allocation exercise
  • Moscow (Must, Should, Could, Won't) — Forcing function for hard choices

Contextual frameworks:

  • Cost of Delay — Urgency-based (time-sensitive features)
  • Impact Mapping — Goal-driven (tie features to outcomes)
  • Story Mapping — User journey-based (narrative flow)

Why This Works

  • Context-aware: Matches framework to product stage, team maturity, data availability
  • Anti-dogmatic: No single "best" framework—it depends on your situation
  • Actionable: Provides implementation steps, not just framework names

Anti-Patterns (What This Is NOT)

  • Not a universal ranking: Frameworks aren't "better" or "worse"—they fit different contexts
  • Not a replacement for strategy: Frameworks execute strategy; they don't create it
  • Not set-it-and-forget-it: Reassess frameworks as your product matures

When to Use This

  • Choosing a prioritization framework for the first time
  • Switching frameworks (current one isn't working)
  • Aligning stakeholders on prioritization process
  • Onboarding new PMs to team practices

When NOT to Use This

  • When you already have a working framework (don't fix what isn't broken)
  • For one-off decisions (frameworks are for recurring prioritization)
  • As a substitute for strategic vision (frameworks can't tell you what to build)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 4 adaptive questions, offering 3-4 enumerated options at each step.


Question 1: Product Stage

Agent asks: "What stage is your product in?"

Offer 4 enumerated options:

  1. Pre-product/market fit — "Searching for PMF; experimenting rapidly; unclear what customers want" (High uncertainty, need speed)
  2. Early PMF, scaling — "Found initial PMF; growing fast; adding features to retain/expand" (Moderate uncertainty, balancing speed + quality)
  3. Mature product, optimization — "Established market; incremental improvements; competing on quality/features" (Low uncertainty, data-driven decisions)
  4. Multiple products/platform — "Portfolio of products; cross-product dependencies; complex stakeholder needs" (Coordination complexity)

Or describe your product stage (new idea, growth mode, established, etc.).

User response: [Selection or custom]


Question 2: Team Context

Agent asks: "What's your team and stakeholder environment like?"

Offer 4 enumerated options:

  1. Small team, limited resources — "3-5 engineers, 1 PM, need to focus ruthlessly" (Need simple, fast framework)
  2. Cross-functional team, aligned — "Product, design, engineering aligned; clear goals; good collaboration" (Can use data-driven frameworks)
  3. Multiple stakeholders, misaligned — "Execs, sales, customers all have opinions; need transparent process" (Need consensus-building framework)
  4. Large org, complex dependencies — "Multiple teams, shared roadmap, cross-team dependencies" (Need coordination framework)

Or describe your team/stakeholder context.

User response: [Selection or custom]


Question 3: Decision-Making Needs

Agent asks: "What's the primary challenge you're trying to solve with prioritization?"

Offer 4 enumerated options:

  1. Too many ideas, unclear which to pursue — "Backlog is 100+ items; need to narrow to top 10" (Need filtering framework)
  2. Stakeholders disagree on priorities — "Sales wants features, execs want strategic bets, engineering wants tech debt" (Need alignment framework)
  3. Lack of data-driven decisions — "Prioritizing by gut feel; want metrics-based process" (Need scoring framework)
  4. Hard tradeoffs between strategic bets vs. quick wins — "Balancing long-term vision vs. short-term customer needs" (Need value/effort framework)

Or describe your specific challenge.

User response: [Selection or custom]


Question 4: Data Availability

Agent asks: "How much data do you have to inform prioritization?"

Offer 3 enumerated options:

  1. Minimal data — "New product, no usage metrics, few customers to survey" (Gut-based frameworks)
  2. Some data — "Basic analytics, customer feedback, but no rigorous data collection" (Lightweight scoring frameworks)
  3. Rich data — "Usage metrics, A/B tests, customer surveys, clear success metrics" (Data-driven frameworks)

Or describe your data situation.

User response: [Selection or custom]


Output: Recommend Prioritization Framework

After collecting responses, the agent recommends a framework:

# Prioritization Framework Recommendation

**Based on your context:**
- **Product Stage:** [From Q1]
- **Team Context:** [From Q2]
- **Decision-Making Need:** [From Q3]
- **Data Availability:** [From Q4]

---

## Recommended Framework: [Framework Name]

**Why this framework fits:**
- [Rationale 1 based on Q1-Q4]
- [Rationale 2]
- [Rationale 3]

**When to use it:**
- [Context where this framework excels]

**When NOT to use it:**
- [Limitations or contexts where it fails]

---

## How to Implement

### Step 1: [First implementation step]
- [Detailed guidance]
- [Example: "Define scoring criteria: Reach, Impact, Confidence, Effort"]

### Step 2: [Second step]
- [Detailed guidance]
- [Example: "Score each feature on 1-10 scale"]

### Step 3: [Third step]
- [Detailed guidance]
- [Example: "Calculate RICE score: (Reach × Impact × Confidence) / Effort"]

### Step 4: [Fourth step]
- [Detailed guidance]
- [Example: "Rank by score; review top 10 with stakeholders"]

---

## Example Scoring Template

[Provide a concrete example of how to use the framework]

**Example (if RICE):**

| Feature | Reach (users/month) | Impact (1-3) | Confidence (%) | Effort (person-months) | RICE Score |
|---------|---------------------|--------------|----------------|------------------------|------------|
| Feature A | 10,000 | 3 (massive) | 80% | 2 | 12,000 |
| Feature B | 5,000 | 2 (high) | 70% | 1 | 7,000 |
| Feature C | 2,000 | 1 (medium) | 50% | 0.5 | 2,000 |

**Priority:** Feature A > Feature B > Feature C

---

## Alternative Framework (Second Choice)

**If the recommended framework doesn't fit, consider:** [Alternative framework name]

**Why this might work:**
- [Rationale]

**Tradeoffs:**
- [What you gain vs. what you lose]

---

## Common Pitfalls with This Framework

1. **[Pitfall 1]** — [Description and how to avoid]
2. **[Pitfall 2]** — [Description and how to avoid]
3. **[Pitfall 3]** — [Description and how to avoid]

---

## Reassess When

- Product stage changes (e.g., PMF → scaling)
- Team grows or reorganizes
- Stakeholder dynamics shift
- Current framework feels broken (e.g., too slow, ignoring important factors)

---

**Would you like implementation templates or examples for this framework?**

Examples

Example 1: Good Framework Match (Early PMF, RICE)

Q1 Response: "Early PMF, scaling — Found initial PMF; growing fast; adding features to retain/expand"

Q2 Response: "Cross-functional team, aligned — Product, design, engineering aligned; clear goals"

Q3 Response: "Lack of data-driven decisions — Prioritizing by gut feel; want metrics-based process"

Q4 Response: "Some data — Basic analytics, customer feedback, but no rigorous data collection"


Recommended Framework: RICE (Reach, Impact, Confidence, Effort)

Why this fits:

  • You have some data (analytics, customer feedback) to estimate Reach and Impact
  • Cross-functional team alignment means you can agree on scoring criteria
  • Transitioning from gut feel to data-driven = RICE provides structure without overwhelming complexity
  • Early PMF stage = need speed, but also need to prioritize high-impact features for retention/expansion

When to use it:

  • Quarterly or monthly roadmap planning
  • When backlog exceeds 20-30 items
  • When stakeholders debate priorities

When NOT to use it:

  • For strategic, multi-quarter bets (RICE favors incremental wins)
  • When you lack basic metrics (Reach requires usage data)
  • For single-feature decisions (overkill)

Implementation:

Step 1: Define Scoring Criteria

  • Reach: How many users will this feature affect per month/quarter?
  • Impact: How much will it improve their experience? (1 = minimal, 2 = high, 3 = massive)
  • Confidence: How confident are you in your Reach/Impact estimates? (50% = low data, 80% = good data, 100% = certain)
  • Effort: How many person-months to build? (Include design, engineering, QA)

Step 2: Score Each Feature

  • Use a spreadsheet or Airtable
  • Involve PM, design, engineering in scoring (not just PM solo)
  • Be honest about Confidence (don't inflate scores)

Step 3: Calculate RICE Score

  • Formula: (Reach × Impact × Confidence) / Effort
  • Higher score = higher priority

Step 4: Review and Adjust

  • Sort by RICE score
  • Review top 10-20 with stakeholders
  • Adjust for strategic priorities (RICE doesn't capture everything)

Example Scoring:

Feature Reach Impact Confidence Effort RICE Score
Email reminders 5,000 2 70% 1 7,000
Mobile app 10,000 3 60% 6 3,000
Dark mode 8,000 1 90% 0.5 14,400

Priority: Dark mode > Email reminders > Mobile app (despite mobile app having high Reach/Impact, Effort is too high)


Alternative Framework: ICE (Impact, Confidence, Ease)

Why this might work:

  • Simpler than RICE (no Reach calculation)
  • Faster to score (good if you need quick decisions)

Tradeoffs:

  • Less data-driven (no Reach metric = can't compare features affecting different user bases)
  • More subjective (Impact/Ease are gut-feel, not metrics)

Common Pitfalls:

  1. Overweighting Effort — Don't avoid hard problems just because they score low. Some strategic bets require high effort.
  2. Inflating Confidence — Be honest. 50% confidence is okay if data is scarce.
  3. Ignoring strategy — RICE doesn't capture strategic importance. Adjust for vision/goals.

Example 2: Bad Framework Match (Pre-PMF + RICE = Wrong Fit)

Q1 Response: "Pre-product/market fit — Searching for PMF; experimenting rapidly"

Q2 Response: "Small team, limited resources — 3 engineers, 1 PM"

Q3 Response: "Too many ideas, unclear which to pursue"

Q4 Response: "Minimal data — New product, no usage metrics"


Recommended Framework: ICE (Impact, Confidence, Ease) or Value/Effort Matrix

Why NOT RICE:

  • You don't have usage data to estimate Reach
  • Pre-PMF = you need speed, not rigorous scoring
  • Small team = overhead of RICE scoring is too heavy

Why ICE instead:

  • Lightweight, gut-check framework
  • Can score 20 ideas in 30 minutes
  • Good for rapid experimentation phase

Or Value/Effort Matrix:

  • Visual 2x2 matrix (high value/low effort = quick wins)
  • Even faster than ICE
  • Good for stakeholder alignment (visual, intuitive)

Common Pitfalls

Pitfall 1: Using the Wrong Framework for Your Stage

Symptom: Pre-PMF startup using weighted scoring with 10 criteria

Consequence: Overhead kills speed. You need experiments, not rigorous scoring.

Fix: Match framework to stage. Pre-PMF = ICE or Value/Effort. Scaling = RICE. Mature = Opportunity Scoring or Kano.


Pitfall 2: Framework Whiplash

Symptom: Switching frameworks every quarter

Consequence: Team confusion, lost time, no consistency.

Fix: Stick with one framework for 6-12 months. Reassess only when stage/context changes.


Pitfall 3: Treating Scores as Gospel

Symptom: "Feature A scored 8,000, Feature B scored 7,999, so A wins"

Consequence: Ignores strategic context, judgment, and vision.

Fix: Use frameworks as input, not automation. PM judgment overrides scores when needed.


Pitfall 4: Solo PM Scoring

Symptom: PM scores features alone, presents to team

Consequence: Lack of buy-in, engineering/design don't trust scores.

Fix: Collaborative scoring sessions. PM, design, engineering score together.


Pitfall 5: No Framework at All

Symptom: "We prioritize by who shouts loudest"

Consequence: HiPPO (Highest Paid Person's Opinion) wins, not data or strategy.

Fix: Pick any framework. Even imperfect structure beats chaos.


References

Related Skills

  • user-story.md — Prioritized features become user stories
  • epic-hypothesis.md — Prioritized epics validated with experiments
  • recommendation-canvas.md — Business outcomes inform prioritization

External Frameworks

  • Intercom, RICE Prioritization (2016) — Origin of RICE framework
  • Sean McBride, ICE Scoring (2012) — Lightweight prioritization
  • Luke Hohmann, Innovation Games (2006) — Buy-a-Feature and other collaborative methods
  • Noriaki Kano, Kano Model (1984) — Customer satisfaction framework

Dean's Work

  • [If Dean has prioritization resources, link here]

Skill type: Interactive Suggested filename: prioritization-advisor.md Suggested placement: /skills/interactive/ Dependencies: None (standalone, but informs roadmap and backlog decisions)

引导产品经理使用MITRE问题定义画布,通过向内审视假设、向外理解利益相关者及重构问题三个阶段,产出清晰的行动型问题陈述与“我们如何能”提问,避免先入为主和确认偏误。
需要明确问题定义而非直接寻求解决方案时 团队陷入确认偏误或解决方案思维时 需要结构化梳理假设和偏见时
skills/problem-framing-canvas/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill problem-framing-canvas -g -y
SKILL.md
Frontmatter
{
    "name": "problem-framing-canvas",
    "type": "interactive",
    "intent": "Guide product managers through the MITRE Problem Framing Canvas process by asking structured questions across three phases: Look Inward (examine your own assumptions and biases), Look Outward (understand who experiences the problem and who doesn't), and Reframe (synthesize insights into an actionable problem statement and \"How Might We\" question). Use this to ensure you're solving the right problem before jumping to solutions—avoiding confirmation bias, overlooked stakeholders, and solution-first thinking.",
    "best_for": [
        "Clarifying a messy problem before solutioning",
        "Surfacing assumptions and overlooked stakeholders",
        "Creating a bias-resistant problem statement in a workshop"
    ],
    "scenarios": [
        "Run a Problem Framing Canvas for our mobile retention issue",
        "Help me reframe this stakeholder request before we build anything",
        "We need a clearer problem statement for onboarding drop-off"
    ],
    "description": "Guide teams through MITRE's Problem Framing Canvas. Use when you need a clearer problem statement before jumping to solutions.",
    "argument-hint": "[problem area]"
}

Purpose

Guide product managers through the MITRE Problem Framing Canvas process by asking structured questions across three phases: Look Inward (examine your own assumptions and biases), Look Outward (understand who experiences the problem and who doesn't), and Reframe (synthesize insights into an actionable problem statement and "How Might We" question). Use this to ensure you're solving the right problem before jumping to solutions—avoiding confirmation bias, overlooked stakeholders, and solution-first thinking.

This is not a solution brainstorm—it's a problem framing tool that broadens perspective, challenges assumptions, and produces a clear, equity-driven problem statement.

Input

Works best with: The problem area — however roughly you currently understand it. Also useful: Who you believe experiences it, evidence so far, and the solution everyone is already anchored on (naming it helps the canvas de-bias it).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill opens with the Look Inward phase: what do you assume about this problem?

Example invocation: Frame this problem: field sales reps 'don't use the CRM' and leadership wants gamification.

Key Concepts

What is the MITRE Problem Framing Canvas?

The Problem Framing Canvas (MITRE Innovation Toolkit, v3) is a structured framework that helps teams explore a problem space comprehensively before proposing solutions. It's partitioned into three areas:

  1. Look Inward — Examine your own assumptions, biases, and how you might be part of the problem
  2. Look Outward — Understand who experiences the problem, who benefits from it, and who's been left out
  3. Reframe — Synthesize insights into a clear, actionable problem statement and "How Might We" question

Canvas Structure

┌─────────────────────────────────────────────────────────────────┐
│ LOOK INWARD                                                     │
│ - What is the problem? (symptoms)                              │
│ - Why haven't we solved it? (new, hard, low priority, etc.)   │
│ - How are we part of the problem? (assumptions, biases)       │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│ LOOK OUTWARD                                                    │
│ - Who experiences the problem? When/where/consequences?        │
│ - Who else has it? Who doesn't have it?                       │
│ - Who's been left out?                                        │
│ - Who benefits when problem exists/doesn't exist?             │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│ REFRAME                                                         │
│ - Stated another way, the problem is: [restatement]           │
│ - How might we [action] as we aim to [objective]?             │
└─────────────────────────────────────────────────────────────────┘

Why This Works

  • Broadens perspective: Forces you to look beyond your own assumptions
  • Equity-driven: Centers marginalized voices and asks "who's been left out?"
  • Challenges biases: Requires explicit examination of assumptions before framing problem
  • Actionable output: Produces HMW statement ready for solution exploration

Anti-Patterns (What This Is NOT)

  • Not a solution brainstorm: Canvas frames the problem; solutions come later
  • Not a feature request list: Focuses on underlying problems, not surface symptoms
  • Not a one-person exercise: Requires diverse perspectives to challenge groupthink

When to Use This

  • Starting discovery for a new initiative
  • Reframing an existing problem (suspect you're solving the wrong thing)
  • Challenging assumptions before building solutions
  • Aligning cross-functional teams on problem definition

When NOT to Use This

  • When the problem is already well-understood and validated
  • For tactical bug fixes or technical debt (no deep framing needed)
  • When stakeholders have already committed to a solution (address alignment first)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

Use template.md for the full fill-in structure.

This interactive skill follows a three-phase process, asking adaptive questions in each phase.


Step 0: Gather Context (Before Questions)

Agent suggests:

Before we frame your problem, let's gather context:

Problem Context:

  • Initial problem statement or stakeholder request
  • Symptoms you've observed (support tickets, churn data, user complaints)
  • Existing research (user interviews, surveys, analytics)
  • Assumptions you're making about the problem

Stakeholder Context:

  • Who's affected by this problem? (users, customers, internal teams)
  • Who's asking for this to be solved? (execs, sales, customers)
  • Who might have been overlooked?

You can paste this content directly, or describe the problem briefly.


Phase 1: Look Inward

Goal: Examine your own assumptions, biases, and how you might be part of the problem.


Question 1: What is the problem? (Describe symptoms)

Agent asks: "What is the problem as you currently understand it? Describe the symptoms."

Offer 4 enumerated options:

  1. Customer pain point — "Customers struggle with [specific task/outcome]" (e.g., "Customers can't find features they need")
  2. Business metric problem — "We're seeing [metric decline]" (e.g., "Churn increased 15% last quarter")
  3. Stakeholder request — "Stakeholders say we need [feature/change]" (e.g., "Sales team says we need better reporting")
  4. Observed behavior — "We've noticed [pattern/trend]" (e.g., "Users abandon onboarding at step 3")

Or describe your problem/symptoms.

User response: [Selection or custom]

Agent extracts:

  • Problem (initial framing): [Description from user]

Question 2: Why haven't we solved it?

Agent asks: "Why hasn't this problem been solved yet?"

Offer 6 enumerated options (can select multiple):

  1. It's new — "Problem recently emerged"
  2. It's hard — "Technically complex or resource-intensive"
  3. It's low priority — "Other initiatives took precedence"
  4. Lack of resources — "Not enough budget, people, or time"
  5. Lack of authority — "Can't make the decision or get buy-in"
  6. A systemic inequity — "Problem disproportionately affects marginalized groups, overlooked"

Or describe your own reason.

User response: [Selection or custom]

Agent captures:

  • Barriers to solving: [List of reasons]

Question 3: How are we part of the problem? (Assumptions & biases)

Agent asks: "How might you (or your team) be part of the problem? What assumptions or biases are you bringing?"

Offer 4 enumerated options:

  1. Assuming we know what customers want — "We haven't validated with real users" (Confirmation bias)
  2. Optimizing for ourselves, not users — "Building what's easy for us, not what's valuable for them" (Internal bias)
  3. Overlooking specific user segments — "Focused on majority users, ignored edge cases or marginalized groups" (Survivorship bias)
  4. Solution-first thinking — "Jumped to 'we need [feature X]' before understanding root problem" (Premature convergence)

Or describe your specific assumptions/biases.

User response: [Selection or custom]

Agent captures:

  • Assumptions to challenge: [List of biases]

Phase 2: Look Outward

Goal: Understand who experiences the problem, who benefits from it, and who's been left out.


Question 4: Who experiences the problem? (When, where, consequences)

Agent asks: "Who experiences this problem? When and where do they experience it? What consequences do they face?"

Agent prompts user to describe:

  • Who: Specific personas, user segments, or roles
  • When: Triggering events or contexts (e.g., "during onboarding," "at month-end close")
  • Where: Physical or digital locations (e.g., "mobile app," "enterprise deployments")
  • Consequences: Impact on users (e.g., "waste 2 hours/week," "miss deadlines," "churn")

Adaptation: Use personas from context (proto-personas, JTBD, customer research)

User response: [Detailed description]

Agent captures:

  • Who experiences it: [Personas/segments]
  • When/where: [Context]
  • Consequences: [Impact]

Question 5: Who else has this problem? Who doesn't have it?

Agent asks: "Who else has this problem? (Colleagues, competitors, other domains?) And who doesn't have it?"

Agent prompts:

  • Who else has it: Other companies, industries, or domains with similar problems
  • How do they deal with it: Workarounds, solutions, or adaptations
  • Who doesn't have it: Users/companies that avoid the problem (what's different about them?)

User response: [Detailed description]

Agent captures:

  • Who else has it: [Examples]
  • Who doesn't have it: [Counter-examples]

Question 6: Who's been left out? Who benefits?

Agent asks: "Who's been left out of the conversation so far? And who benefits when this problem exists or doesn't exist?"

Agent prompts:

  • Who's been left out: Marginalized voices, edge cases, overlooked stakeholders
  • Who benefits when problem exists: Who gains from the status quo?
  • Who benefits when problem doesn't exist: Who loses if problem is solved?

Example:

  • "Who benefits when onboarding is broken?" → "Sales team doesn't have to support complex workflows; engineering doesn't have to build guided flows"
  • "Who's been left out?" → "Non-technical users, international customers (onboarding in English only)"

User response: [Detailed description]

Agent captures:

  • Who's been left out: [List]
  • Who benefits (problem exists): [List]
  • Who benefits (problem solved): [List]

Phase 3: Reframe

Goal: Synthesize insights into a clear, actionable problem statement and "How Might We" question.


Question 7: Restate the problem

Agent says: "Based on everything we've explored, let's restate the problem in a new way."

Agent generates a refined problem statement using insights from Phases 1-2:

Template: "The problem is: [Who] struggles to [accomplish what] because [root cause], which leads to [consequence]. This affects [specific segments] and has been overlooked because [bias/assumption from Phase 1]."

Example (SaaS onboarding): "The problem is: Non-technical small business owners struggle to activate our product during onboarding because we use jargon-heavy UI and lack guided workflows, which leads to 60% abandonment within 24 hours. This disproportionately affects solopreneurs without technical support, and has been overlooked because our team optimizes for enterprise users who have IT departments."

Agent asks: "Does this restatement capture the core problem? Should we refine it?"

User response: [Approve or modify]


Question 8: Create "How Might We" statement

Agent says: "Now let's make it actionable with a 'How Might We' statement."

Template: "How might we [action that addresses the problem] as we aim to [objective/desired condition]?"

Example (SaaS onboarding): "How might we guide non-technical users through onboarding with plain-language prompts as we aim to increase activation from 40% to 70%?"

Agent asks: "Does this HMW statement set up the right solution space? Should we adjust?"

User response: [Approve or modify]


Output: Problem Framing Canvas + HMW Statement

After completing the flow, the agent outputs:

# Problem Framing Canvas: [Problem Name]

**Date:** [Today's date]

---

## Phase 1: Look Inward

### What is the problem? (Symptoms)
[Description from Q1]

### Why haven't we solved it?
- [Barrier 1 from Q2]
- [Barrier 2]
- [Barrier 3]

### How are we part of the problem? (Assumptions & biases)
- [Assumption 1 from Q3]
- [Assumption 2]
- [Assumption 3]

**Which of these might be redesigned, reframed, or removed?**
[Reflection on biases to challenge]

---

## Phase 2: Look Outward

### Who experiences the problem?
**Who:** [Personas/segments from Q4]
**When/Where:** [Context]
**Consequences:** [Impact on users]
**Lived experience varies:** [How different users experience it differently]

### Who else has this problem?
**Who else:** [Examples from Q5]
**How they deal with it:** [Workarounds]

### Who doesn't have it?
[Counter-examples from Q5]

### Who's been left out?
[Marginalized voices from Q6]

### Who benefits?
**When problem exists:** [Beneficiaries of status quo]
**When problem doesn't exist:** [Who loses if solved]

---

## Phase 3: Reframe

### Stated another way, the problem is:
[Refined problem statement from Q7]

### How Might We...
**How might we** [action from Q8] **as we aim to** [objective from Q8]?

---

## Next Steps

1. **Validate with users:** Use `skills/discovery-interview-prep/SKILL.md` to test reframed problem with customers
2. **Generate solutions:** Use `skills/opportunity-solution-tree/SKILL.md` to explore solution space
3. **Create problem statement:** Use `skills/problem-statement/SKILL.md` to formalize for PRD/roadmap
4. **Identify opportunities:** Use HMW statement to brainstorm solution ideas

---

**Ready to explore solutions? Let me know if you'd like to refine the problem framing or move to solution generation.**

Examples

See examples/sample.md for full problem framing examples.

Mini example excerpt:

**Look Inward:** Churn spiked after onboarding change
**Look Outward:** New SMB users are most affected
**Reframe:** How might we reduce onboarding friction for first-time users?

Common Pitfalls

Pitfall 1: Skipping "Look Inward" (Assuming You're Neutral)

Symptom: Team jumps straight to "Look Outward" without examining biases

Consequence: Groupthink persists, assumptions unchallenged

Fix: Force explicit discussion of assumptions and biases (Q2-Q3)


Pitfall 2: Ignoring "Who Benefits" Question

Symptom: Canvas completed without exploring who benefits from problem existing

Consequence: Miss political dynamics, resistance to change

Fix: Always ask "Who loses if this problem is solved?" (Q6)


Pitfall 3: Generic Problem Statement

Symptom: Reframed problem is vague ("Improve user experience")

Consequence: HMW statement isn't actionable

Fix: Make problem specific (who, what, when, consequence, root cause)


Pitfall 4: HMW Statement Is Too Narrow

Symptom: "How might we add a mobile app?"

Consequence: Constrains solution space to one idea

Fix: Keep HMW broad: "How might we enable mobile-first users to access core workflows on any device?"


Pitfall 5: Solo Exercise (No Diverse Perspectives)

Symptom: PM fills out canvas alone

Consequence: Biases persist, marginalized voices still left out

Fix: Facilitate canvas workshop with cross-functional team + customer input


References

Related Skills

  • skills/problem-statement/SKILL.md — Converts reframed problem into formal problem statement
  • skills/opportunity-solution-tree/SKILL.md — Uses HMW statement to generate solution options
  • skills/discovery-interview-prep/SKILL.md — Validates reframed problem with customers

External Frameworks

  • MITRE Innovation Toolkit, "Problem Framing Canvas v3" (2021) — Origin of canvas, equity-driven design thinking
  • Stanford d.school, "How Might We" statements — Actionable problem framing

Dean's Work

  • [If Dean has problem framing resources, link here]

Skill type: Interactive Suggested filename: problem-framing-canvas.md Suggested placement: /skills/interactive/ Dependencies: Uses skills/problem-statement/SKILL.md

以用户为中心撰写问题陈述,明确受阻人群、目标、阻碍原因及情感影响。用于对齐利益相关者、聚焦用户成果而非功能需求,适用于发现阶段、优先级排序或PRD制定,避免直接提出解决方案。
需要框定探索性研究或问题验证工作 在开始设计解决方案前对齐团队认知 面对模糊的功能请求需挖掘底层真实问题 向工程、设计或高管团队阐述为何该问题值得解决
skills/problem-statement/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill problem-statement -g -y
SKILL.md
Frontmatter
{
    "name": "problem-statement",
    "type": "component",
    "intent": "Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests.",
    "description": "Write a user-centered problem statement with who is blocked, what they are trying to do, why it matters, and how it feels. Use when framing discovery, prioritization, or a PRD.",
    "argument-hint": "[user and their struggle]"
}

Purpose

Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests.

This is not a requirements doc—it's a human-centered problem narrative that ensures you're solving a problem worth solving.

Input

Works best with: Who the user is and what they're struggling to do. Also useful: What's blocking them, why it matters, how it feels, and supporting evidence.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the user and their goal first — a problem statement without a specific 'who' is a solution looking for cover.

Example invocation: Problem statement: clinic schedulers double-book exam rooms because the calendar doesn't show equipment availability.

Key Concepts

The Problem Framing Framework

Based on Jobs-to-be-Done and empathy mapping, the framework structures problems as:

Problem Framing Narrative:

  • I am: [Describe the persona experiencing the problem]
  • Trying to: [Desired outcomes the persona cares about]
  • But: [Barriers preventing the outcomes]
  • Because: [Root cause of the problem]
  • Which makes me feel: [Emotional impact]

Context & Constraints:

  • [Geographic, technological, time-based, demographic factors]

Final Problem Statement:

  • [Single, concise, empathetic summary]

Why This Structure Works

  • Persona-centric: Forces you to see the problem through the user's eyes
  • Outcome-focused: "Trying to" emphasizes desired results, not tasks
  • Root cause analysis: "Because" pushes past symptoms to underlying issues
  • Emotional validation: "Makes me feel" humanizes the problem and builds empathy
  • Contextual: Constraints acknowledge real-world limitations

Anti-Patterns (What This Is NOT)

  • Not a solution in disguise: "The problem is we lack AI-powered analytics" = sneaking in a solution
  • Not a business problem: "Our revenue is down" isn't a user problem (it's a symptom)
  • Not a feature request: "Users need a dashboard" isn't a problem (what are they trying to do?)
  • Not generic: "Users want better UX" is too vague to be actionable

When to Use This

  • Kicking off discovery or problem validation work
  • Aligning stakeholders before solutioning
  • Socializing a problem with engineering, design, or exec teams
  • When you have feature requests but unclear underlying problems
  • Pitching why a problem is worth solving

When NOT to Use This

  • When you haven't done any user research yet (don't guess—interview first)
  • For internal operational problems (this is for user-facing problems)
  • As a substitute for a PRD (this frames the problem; PRD defines the solution)

Application

Use template.md for the full fill-in structure.

Step 1: Gather User Context

Before drafting, ensure you have:

  • User interviews or research: Direct quotes, observed behaviors, pain points
  • Jobs-to-be-Done insights: What users are "hiring" your product to do (reference skills/jobs-to-be-done/SKILL.md)
  • Persona clarity: Who specifically experiences this problem (reference skills/proto-persona/SKILL.md)
  • Constraints data: Geographic, tech, time, demographic limitations

If missing context: Run discovery interviews, contextual inquiries, or user shadowing. Don't fabricate problems.


Step 2: Draft the Problem Framing Narrative

Fill in the template from the persona's point of view:

## Problem Framing Narrative

**I am:** [Describe the key persona, highlighting 3-4 key characteristics]
- [Key pain point or characteristic 1]
- [Key pain point or characteristic 2]
- [Key pain point or characteristic 3]

**Trying to:**
- [Single sentence listing the desired outcomes the persona cares most about]

**But:**
- [Describe the barriers preventing the persona from achieving outcomes]
- [Job-to-be-done or outcome obstruction 1]
- [Job-to-be-done or outcome obstruction 2]
- [Job-to-be-done or outcome obstruction 3]

**Because:**
- [Describe the root cause empathetically]

**Which makes me feel:**
- [Describe the emotions from the persona's perspective]

Quality checks:

  • "I am" specificity: Can you picture this person? Or is it generic ("busy professionals")?
  • "Trying to" clarity: Is this an outcome (measurable) or a task (activity)?
  • "But" depth: Are these real barriers or just inconveniences?
  • "Because" honesty: Is this the root cause or just a symptom?
  • "Makes me feel" authenticity: Do these emotions come from research or assumptions?

Step 3: Document Context & Constraints

## Context & Constraints

- [Enumerate geographic, technological, time-based, or demographic factors]
- [e.g., "Must work offline in rural areas with limited connectivity"]
- [e.g., "Used by non-technical users unfamiliar with complex software"]
- [e.g., "Time-sensitive: decisions must be made within 24 hours"]

Quality checks:

  • Relevance: Do these constraints directly impact the problem?
  • Specificity: Are they concrete enough to inform design decisions?

Step 4: Craft the Final Problem Statement

Synthesize the narrative into one powerful sentence:

## Final Problem Statement

[Single, concise statement that provides a powerful and empathetic summary]

Formula: [Persona] needs a way to [desired outcome] because [root cause], which currently [emotional/practical impact].

Example: "Enterprise IT admins need a way to provision user accounts in under 5 minutes because current processes take 2+ hours with manual approvals, which causes project delays and frustrated end-users."

Quality checks:

  • One sentence: If it requires multiple sentences, the problem isn't crisp yet
  • Measurable: Can you tell if you've solved it?
  • Empathetic: Does it resonate emotionally?
  • Shareable: Could you say this in a meeting and have stakeholders nod?

Step 5: Validate and Socialize

  • Test with users: Read it aloud to people who experience the problem. Do they say "Yes, exactly!"?
  • Share with stakeholders: Product, engineering, design, exec. Does it align everyone?
  • Iterate based on feedback: If anyone says "I don't think that's the real problem," dig deeper.

Examples

See examples/sample.md for full examples (good and bad problem statements).

Mini example excerpt:

**I am:** A software developer on a distributed team
**Trying to:** Communicate in real-time with my team without losing context
**But:** Email is too slow and IM is ephemeral
**Because:** No tool combines real-time chat with searchable history
**Which makes me feel:** Frustrated and disconnected

Common Pitfalls

Pitfall 1: Solution Smuggling

Symptom: "The problem is we don't have [specific feature]"

Consequence: You've predetermined the solution without validating the problem.

Fix: Reframe around the user's desired outcome, not the feature. Ask "What are they trying to achieve?"


Pitfall 2: Business Problem Disguised as User Problem

Symptom: "Users want to increase our revenue" or "The problem is our churn rate"

Consequence: These are company problems, not user problems. Users don't care about your metrics.

Fix: Dig into why users churn or what would make them spend more. Frame it from their perspective.


Pitfall 3: Generic Personas

Symptom: "I am a busy professional trying to be more productive"

Consequence: Too broad to be actionable. Every product claims to help "busy professionals."

Fix: Get specific. "I am a sales rep managing 50+ leads manually in spreadsheets, trying to prioritize follow-ups without missing high-value opportunities."


Pitfall 4: Symptom Instead of Root Cause

Symptom: "Because the UI is confusing"

Consequence: You're describing a symptom, not the underlying issue.

Fix: Ask "Why is the UI confusing?" Keep asking "why" until you hit the root cause (e.g., "Because users have no mental model for how the system works").


Pitfall 5: Fabricated Emotions

Symptom: "Which makes me feel empowered and delighted"

Consequence: These sound like marketing copy, not real user emotions.

Fix: Use actual quotes from user interviews. Real emotions: "frustrated," "overwhelmed," "anxious," "stuck."


References

Related Skills

  • skills/jobs-to-be-done/SKILL.md — Informs the "Trying to" and "But" sections
  • skills/proto-persona/SKILL.md — Defines the "I am" persona
  • skills/positioning-statement/SKILL.md — Problem statement informs positioning
  • skills/user-story/SKILL.md — Problem statement guides story prioritization

External Frameworks

  • Clayton Christensen, Jobs to Be Done — Origin of outcome-focused problem framing
  • Osterwalder & Pigneur, Value Proposition Canvas — Customer pains/gains/jobs
  • Dave Gray, Empathy Mapping — Emotional framing techniques

Dean's Work

  • [Link to relevant Dean Peters' Substack articles if applicable]

Provenance

  • Adapted from prompts/framing-the-problem-statement.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: problem-statement.md Suggested placement: /skills/components/ Dependencies: References skills/jobs-to-be-done/SKILL.md, skills/proto-persona/SKILL.md

辅助产品经理候选人结构化回答产品思维面试题。通过六步框架(澄清、理由、目标、细分、痛点、方案)引导逻辑推理,避免直接罗列功能,确保答案清晰、有优先级且具备可讲述性,适用于练习改进或设计类问题。
练习如何改进现有产品 为特定用户群体设计新产品 规划产品的下一步开发方向 模拟产品经理面试中的产品思维问答
skills/product-sense-interview-answer/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill product-sense-interview-answer -g -y
SKILL.md
Frontmatter
{
    "name": "product-sense-interview-answer",
    "type": "component",
    "theme": "career-leadership",
    "intent": "Coach PM candidates through open-ended product-sense interviews using a repeatable six-part answer spine: clarify, rationale, goal, segmentation, pain points, and solution choice. Use this to practice product design and product improvement questions, avoid solution-first answers, and produce responses that sound thoughtful out loud rather than over-scripted on the page.",
    "best_for": [
        "Practicing product design and product improvement interview questions",
        "Coaching candidates who jump to solutions too quickly",
        "Turning messy ideation into a crisp spoken interview answer"
    ],
    "scenarios": [
        "How would you improve YouTube?",
        "Design a product for travelers with flight anxiety",
        "What would you build next for DoorDash?"
    ],
    "description": "Structure a spoken PM product-sense answer with assumptions, segmentation, pain-point prioritization, and MVP tradeoffs. Use when practicing design, improve, or build-next interview questions.",
    "argument-hint": "[interview prompt]",
    "estimated_time": "20-30 min"
}

Purpose

Help PM candidates and interview coaches structure product-sense answers that sound strong out loud, not just on paper. Use this when practicing prompts like "How would you improve X?", "Design a product for Y", or "What would you build next for Z?"

This is not a memorize-and-recite script. It is a reasoning scaffold that prevents solution-jumping, forces real prioritization, and leaves the interviewer with a clean story they can follow.

Input

Works best with: The interview prompt you're practicing (e.g., 'How would you improve X?', 'Design a product for Y'). Also useful: The company/role you're interviewing for and how much time the answer gets.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the prompt, then walks the reasoning scaffold with you out loud.

Example invocation: Practice this: 'How would you improve Google Maps for commuters?' — 25-minute answer, L5 PM loop.

Key Concepts

What Product Sense Interviews Actually Test

Strong product-sense answers do more than generate ideas. Interviewers are usually testing whether you can:

  • Clarify ambiguous prompts without getting stuck
  • Tie user value to market or business logic
  • Segment thoughtfully instead of talking about "everyone"
  • Prioritize one pain point instead of describing ten equally
  • Make tradeoffs explicit when choosing an MVP
  • Communicate clearly under time pressure

The Six-Part Answer Spine

  1. Clarify - Reduce ambiguity, define scope, and state assumptions.
  2. Rationale - Explain why the problem matters now for the market and, if relevant, the company.
  3. Product Goal - Define the user outcome you want to create before talking about features.
  4. Segmentation - Choose who to serve first and show why that target wins.
  5. Pain Points - Map the journey, name the main frictions, and pick the one worth solving first.
  6. Solution - Generate distinct options, compare them, and commit to one MVP with clear exclusions.

The order matters. If you skip from prompt to feature ideas, your answer sounds clever but ungrounded. If you establish the user, goal, and pain first, your solution feels earned.

Why This Works

  • Prevents feature dumping: You do not start with ideas before you know whose problem you are solving.
  • Balances user and business thinking: The answer includes demand, company fit, and strategic tradeoffs rather than pure UX talk.
  • Creates a speakable narrative: Each section becomes a short checkpoint the interviewer can follow.
  • Forces prioritization: Reach, impact, fit, frequency, severity, and effort all surface tradeoffs instead of hand-wavy optimism.

Anti-Patterns (What This Is NOT)

  • Not a feature brainstorm: Listing ideas without choosing a target user or problem is not product sense.
  • Not a TAM presentation: You do not need made-up market numbers to sound strategic.
  • Not a memorized monologue: Rigid scripts break as soon as the interviewer redirects or narrows scope.
  • Not a business-case-only answer: Product sense still requires empathy, behavior, and user context.

When to Use This

  • Product design questions
  • Product improvement questions
  • "What would you build next?" prompts
  • Mock interviews where you want a repeatable spoken structure

When NOT to Use This

  • Behavioral interviews that need STAR stories
  • Execution and analytics cases that revolve around metrics diagnosis
  • Go-to-market or pricing interviews where distribution or monetization is the main problem

Application

Use template.md as the working structure.

Delivery Rules

  • State your structure early so the interviewer knows where you are going.
  • Ask only 1-2 clarifying questions. More than that feels like stalling.
  • Keep lists MECE where possible: segments should be distinct, pain points should not overlap, and solutions should not be three versions of the same thing.
  • Speak in short sentences. Interview answers should sound conversational, not like a memo read aloud.
  • If the prompt does not name a company, use a startup assumption and skip fake company-mission talk.

Step 1: Clarify the Prompt

Start by surfacing the two ambiguities that change the answer most. Good clarifiers usually narrow:

  • Product or surface area
  • User group
  • Time horizon
  • Business model or operating constraints

If the interviewer does not answer, state your assumptions and move on. The goal is to unblock the rest of the answer, not to turn the interview into requirements gathering.

Quality bar: Ask questions that materially change the solution. "Are we talking mobile or desktop?" matters less than "Are we optimizing for viewers, creators, or advertisers?"

Step 2: Build the Rationale Before the Feature

Explain why the space matters now.

For the market view, cover:

  • Why the market is big or strategically important
  • Why the problem matters to real people
  • Why now is a good moment to act

If a company is named, then add:

  • Mission fit
  • Business objective
  • Competitive landscape
  • Market gap
  • Unique strength

End this section with a one-line thesis. That thesis should make the rest of the answer feel inevitable.

Quality bar: Use qualitative signals unless you know the numbers cold. Fake precision is worse than grounded judgment.

Step 3: Define the Product Goal

Write one sentence in this format:

Help [user] [achieve outcome], so that [broader impact].

Then describe what success looks like for the user in observable terms.

Good: "Help beginner YouTube learners find content they are glad they watched, so that the platform becomes an intentional learning destination."

Bad: "Build a personalized AI learning path feature." That is a solution disguised as a goal.

Step 4: Segment the Market and Pick a Target

Do not jump straight to persona. First identify the ecosystem players, then choose the player you want to serve. After that, choose two segmentation dimensions that actually change needs.

Good segmentation dimensions usually change:

  • Goal or job to be done
  • Stakes or consequence level
  • Expertise level
  • Workflow constraints
  • Frequency of the problem

Weak dimensions are often demographic cuts that do not change the product meaningfully.

After choosing your target segment:

  • Give a brief reach / impact / strategic-fit rationale
  • Write a two-sentence persona
  • Keep the persona free of pain points; pain comes next

Step 5: Map Pain Points and Prioritize One

Break the user journey into 4-6 stages. Then list the frictions across that journey.

Prioritize the top pain point using:

  • Frequency - how often the user hits it
  • Severity - how badly it blocks the job, how underserved it is, and the emotional cost

This is the fulcrum of the entire answer. If the pain point is vague or weak, the solution section becomes generic.

Quality bar: Pain points should describe user friction, not missing features. "No structured progression after each video" is a pain. "No AI learning path" is already a solution.

Step 6: Generate Options, Choose an MVP, and Close

List three distinct solutions. They should solve the same pain in different ways, not represent three feature line-items inside one idea.

Evaluate each option on:

  • User impact
  • Effort

Then choose one MVP and specify:

  • Core features
  • 1-2 explicit v1 exclusions
  • Top risks and mitigations

Close with a one-sentence recap that names:

  • Target segment
  • Top pain point
  • First bet

That final sentence is what the interviewer should remember.

Examples

Good Example: Improve YouTube for Beginner Learners

See examples/improve-youtube.md for a full worked example.

What makes it strong:

  • It chooses one player first: viewers, not "everyone in the ecosystem"
  • It segments by learning intent and expertise level, which both change needs materially
  • It picks one pain point: no structured progression across videos
  • It compares multiple solutions before choosing Learning Paths as the MVP

Good Example: Design a Fire Alarm for the Deaf

A strong answer to this prompt would explicitly state a startup assumption if no company is named, prioritize people who live alone, and choose the wake-up problem before discussing dispatch or smart-home integrations.

What makes this example useful:

  • The target segment is clear and high-stakes
  • Severity matters more than broad reach
  • Hardware, software, and ecosystem constraints are part of the reasoning

Anti-Pattern Example

"I would improve YouTube by adding AI summaries, better recommendations, creator analytics, and a study mode."

Why this fails:

  • No target user
  • No prioritized pain point
  • No business or market logic
  • Four ideas that were never compared against each other

This kind of answer can sound energetic in the moment, but it signals weak PM judgment.

Common Pitfalls

  • Solution-first thinking: You start pitching features before naming the user or problem. Fix it by forcing yourself to write the product goal and top pain point before brainstorming solutions.
  • Segmentation theater: You list many segments, then pick one with no tradeoff logic. Fix it by explicitly comparing reach, impact, and strategic fit.
  • Goal-as-feature: Your "goal" describes the thing you want to build. Fix it by rewriting it as a user outcome.
  • Pain points that are really solutions: "Users need a dashboard" is not a pain point. Rewrite in user-language first.
  • Three fake options: Your three solutions are really one solution with minor variations. Fix it by varying the product mechanism, not just the packaging.
  • Weak close: You end after listing features. Fix it by restating the target segment, the pain, and the first bet in one sentence.
  • Over-answering every branch: You try to prove breadth instead of making choices. Product-sense interviews reward focus more than exhaustiveness.

References

引导产品经理完成端到端产品战略会议,整合定位、发现与路线图规划。将模糊方向转化为经验证的具体策略,确保干系人一致后再执行。适用于新产品发布或战略重定,非一次性工作坊而是可重复流程。
需要制定或刷新产品战略 新产品发布前的方向验证 跨部门干系人对齐需求 年度或季度战略规划周期
skills/product-strategy-session/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill product-strategy-session -g -y
SKILL.md
Frontmatter
{
    "name": "product-strategy-session",
    "type": "workflow",
    "intent": "Guide product managers through a comprehensive product strategy session by orchestrating positioning, problem framing, customer discovery, and roadmap planning skills into a cohesive end-to-end process. Use this to move from vague strategic direction to concrete, validated product strategy with clear positioning, target customers, problem statements, and prioritized roadmap—ensuring alignment across stakeholders before committing to execution.",
    "description": "Run an end-to-end product strategy session across positioning, discovery, and roadmap planning. Use when a team needs validated direction before committing to execution.",
    "argument-hint": "[product or strategic question]"
}

Purpose

Guide product managers through a comprehensive product strategy session by orchestrating positioning, problem framing, customer discovery, and roadmap planning skills into a cohesive end-to-end process. Use this to move from vague strategic direction to concrete, validated product strategy with clear positioning, target customers, problem statements, and prioritized roadmap—ensuring alignment across stakeholders before committing to execution.

This is not a one-time workshop—it's a repeatable process for establishing or refreshing product strategy, typically spanning 2-4 weeks with multiple touchpoints.

Input

Works best with: The product (or product line) and the strategic question forcing the session. Also useful: Existing positioning, discovery artifacts, roadmap drafts, and who needs to align on the outcome.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workflow starts at positioning and orchestrates the phases from there — supplied artifacts let it skip ahead.

Example invocation: Run a strategy session for our analytics add-on: flat adoption, two competing roadmap visions, exec review in 4 weeks.

Key Concepts

What is a Product Strategy Session?

A product strategy session is a structured, multi-phase process that takes a product from strategic ambiguity to validated direction. It orchestrates:

  1. Positioning & Market Context — Define who you serve, what problem you solve, and how you're differentiated
  2. Problem Discovery & Validation — Frame and validate customer problems through research
  3. Solution Exploration — Generate opportunity solutions and prioritize based on impact
  4. Roadmap Planning — Sequence epics and releases based on strategy

Why This Works

  • Structured discovery: Prevents jumping to solutions before understanding problems
  • Stakeholder alignment: Creates shared mental model across exec, product, design, engineering
  • Validated strategy: Tests assumptions before committing resources
  • Executable roadmap: Connects high-level strategy to concrete work

Anti-Patterns (What This Is NOT)

  • Not a feature brainstorm: Strategy sessions frame problems, not just list features
  • Not waterfall planning: Builds in feedback loops and iteration
  • Not a solo PM exercise: Requires cross-functional participation

When to Use This

  • Launching a new product or major initiative
  • Annual/quarterly strategic planning cycles
  • Repositioning an existing product
  • Onboarding new product leaders (align on strategy)

When NOT to Use This

  • When strategy is already clear and validated
  • For tactical feature additions (no strategic shift needed)
  • When you lack executive sponsorship (strategy won't stick)

Facilitation Source of Truth

When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.

Application

Use template.md for the full fill-in structure.

This workflow orchestrates 6 phases over 2-4 weeks, using multiple component and interactive skills.


Phase 1: Positioning & Market Context (Week 1, Days 1-2)

Goal: Define target customer, problem space, and differentiation.

Activities

1. Run Positioning Workshop

  • Use: skills/positioning-workshop/SKILL.md (interactive)
  • Participants: PM, product leadership, marketing, sales
  • Duration: 90 minutes
  • Output: Draft positioning statement

2. Define Proto-Personas

  • Use: skills/proto-persona/SKILL.md (component)
  • Participants: PM, design, customer-facing teams
  • Duration: 60 minutes
  • Output: 1-3 proto-personas (hypothesis-driven)

3. Map Jobs-to-be-Done

  • Use: skills/jobs-to-be-done/SKILL.md (component)
  • Participants: PM, design
  • Duration: 60 minutes
  • Output: JTBD statements for each persona

Decision Point 1: Do we have enough customer context?

If YES: Proceed to Phase 2 (Problem Framing)

If NO: Run additional discovery:

  • Use: skills/discovery-interview-prep/SKILL.md (interactive)
  • Schedule 5-10 customer interviews
  • Validate positioning assumptions before proceeding
  • Time impact: +1 week

Phase 2: Problem Framing & Validation (Week 1, Days 3-5)

Goal: Frame the core customer problem and validate it's worth solving.

Activities

1. Run Problem Framing Canvas

  • Use: skills/problem-framing-canvas/SKILL.md (interactive - MITRE)
  • Participants: PM, design, engineering lead, customer success
  • Duration: 120 minutes
  • Output: Refined problem statement + "How Might We" question

2. Create Formal Problem Statement

  • Use: skills/problem-statement/SKILL.md (component)
  • Participants: PM
  • Duration: 30 minutes
  • Output: Structured problem statement for PRD/roadmap

3. Map Customer Journey (Optional)

  • Use: skills/customer-journey-mapping-workshop/SKILL.md (interactive)
  • When to use: If problem spans multiple touchpoints or phases
  • Participants: PM, design, customer success
  • Duration: 90 minutes
  • Output: Journey map with pain points and opportunities

Decision Point 2: Is the problem validated?

If YES: Proceed to Phase 3 (Solution Exploration)

If NO: Run customer discovery interviews:

  • Use: skills/discovery-interview-prep/SKILL.md (interactive)
  • Validate problem hypothesis with 5-10 customers
  • Iterate problem statement based on findings
  • Time impact: +1 week

Phase 3: Solution Exploration (Week 2, Days 1-3)

Goal: Generate solution options, prioritize based on feasibility/impact, and select POC.

Activities

1. Generate Opportunity Solution Tree

  • Use: skills/opportunity-solution-tree/SKILL.md (interactive)
  • Participants: PM, design, engineering lead
  • Duration: 90 minutes
  • Output: 3 opportunities, 3 solutions per opportunity, POC recommendation

Alternative: Use Lean UX Canvas

  • Use: skills/lean-ux-canvas/SKILL.md (interactive)
  • When to use: If you prefer hypothesis-driven approach over OST
  • Output: Business problem, hypotheses, experiments

2. Define Epic Hypotheses

  • Use: skills/epic-hypothesis/SKILL.md (component)
  • Participants: PM
  • Duration: 60 minutes per epic
  • Output: Epic hypothesis statements for top 3-5 initiatives

3. Create User Story Map (Optional)

  • Use: skills/user-story-mapping-workshop/SKILL.md (interactive)
  • When to use: For complex features requiring release planning
  • Participants: PM, design, engineering
  • Duration: 120 minutes
  • Output: Story map with backbone, release slices

Decision Point 3: Do we need to test solutions before committing?

If YES (high uncertainty): Run experiments:

  • Design POC experiments per skills/opportunity-solution-tree/SKILL.md output
  • Test with 10-20 customers (prototype, concierge, landing page test)
  • Time impact: +1-2 weeks

If NO (low uncertainty): Proceed to Phase 4 (Prioritization)


Phase 4: Prioritization & Roadmap Planning (Week 2, Days 4-5)

Goal: Prioritize initiatives and sequence into executable roadmap.

Activities

1. Choose Prioritization Framework

  • Use: skills/prioritization-advisor/SKILL.md (interactive)
  • Participants: PM
  • Duration: 30 minutes
  • Output: Recommended prioritization framework (RICE, ICE, Value/Effort, etc.)

2. Score & Prioritize Epics

  • Use: Prioritization framework from step 1
  • Participants: PM, engineering lead, product leadership
  • Duration: 90 minutes
  • Output: Ranked backlog of epics

3. Sequence Roadmap by Release

  • Participants: PM, engineering lead
  • Duration: 60 minutes
  • Output: Quarterly or release-based roadmap (Q1: Epics A, B; Q2: Epics C, D, E)

4. Map TAM/SAM/SOM (Optional)

  • Use: skills/tam-sam-som-calculator/SKILL.md (interactive)
  • When to use: For exec presentations, fundraising, or market sizing
  • Participants: PM, business ops
  • Duration: 60 minutes
  • Output: Market size projections with citations

Phase 5: Stakeholder Alignment & Communication (Week 3)

Goal: Present strategy to stakeholders, gather feedback, refine.

Activities

1. Create Visionary Press Release (Optional)

  • Use: skills/press-release/SKILL.md (component)
  • When to use: For major product launches or exec buy-in
  • Participants: PM, marketing
  • Duration: 60 minutes
  • Output: Amazon Working Backwards-style press release

2. Present Strategy to Stakeholders

  • Format: 60-min presentation covering:
    • Positioning statement (Phase 1)
    • Problem statement (Phase 2)
    • Solution options & prioritization (Phase 3-4)
    • Roadmap (Phase 4)
  • Participants: Execs, product leadership, key stakeholders
  • Output: Feedback, open questions, approval to proceed

3. Refine Based on Feedback

  • Duration: 1-2 days
  • Output: Updated strategy artifacts

Phase 6: Execution Planning (Week 4)

Goal: Break epics into user stories, plan first sprint/release.

Activities

1. Break Down Top Epic

  • Use: skills/epic-breakdown-advisor/SKILL.md (interactive - with Richard Lawrence's 9 patterns)
  • Participants: PM, design, engineering
  • Duration: 90 minutes
  • Output: User stories split by patterns (workflow, CRUD, business rules, etc.)

2. Write User Stories

  • Use: skills/user-story/SKILL.md (component)
  • Participants: PM
  • Duration: 30 minutes per story
  • Output: User stories with acceptance criteria

3. Plan First Sprint/Release

  • Participants: PM, engineering
  • Duration: 60 minutes
  • Output: Sprint backlog or release plan

Complete Workflow: End-to-End Summary

Week 1:
├─ Day 1-2: Positioning & Market Context
│  ├─ skills/positioning-workshop/SKILL.md (90 min)
│  ├─ skills/proto-persona/SKILL.md (60 min)
│  └─ skills/jobs-to-be-done/SKILL.md (60 min)
│
├─ Day 3-5: Problem Framing & Validation
│  ├─ skills/problem-framing-canvas/SKILL.md (120 min)
│  ├─ skills/problem-statement/SKILL.md (30 min)
│  └─ [Optional] skills/customer-journey-mapping-workshop/SKILL.md (90 min)
│
└─ Decision: Validate problem? (if NO, +1 week discovery)

Week 2:
├─ Day 1-3: Solution Exploration
│  ├─ skills/opportunity-solution-tree/SKILL.md (90 min)
│  ├─ skills/epic-hypothesis/SKILL.md (60 min per epic)
│  └─ [Optional] skills/user-story-mapping-workshop/SKILL.md (120 min)
│
├─ Decision: Test solutions? (if YES, +1-2 weeks experiments)
│
└─ Day 4-5: Prioritization & Roadmap
   ├─ skills/prioritization-advisor/SKILL.md (30 min)
   ├─ Score & prioritize epics (90 min)
   ├─ Sequence roadmap (60 min)
   └─ [Optional] skills/tam-sam-som-calculator/SKILL.md (60 min)

Week 3:
└─ Stakeholder Alignment
   ├─ [Optional] skills/press-release/SKILL.md (60 min)
   ├─ Present strategy (60 min)
   └─ Refine based on feedback (1-2 days)

Week 4:
└─ Execution Planning
   ├─ skills/epic-breakdown-advisor/SKILL.md (90 min)
   ├─ skills/user-story/SKILL.md (30 min per story)
   └─ Plan first sprint (60 min)

Total Time Investment:

  • Minimum: 2 weeks (no discovery/experiments)
  • Typical: 3 weeks (includes 1 round of validation)
  • Maximum: 4-6 weeks (includes discovery interviews + experiments)

Examples

See examples/sample.md for a full strategy session example.

Mini example excerpt:

**Target:** Non-technical SMB owners
**Problem:** Onboarding drop-off due to jargon
**Priority:** Guided onboarding (RICE)

Common Pitfalls

Pitfall 1: Skipping Problem Validation

Symptom: Jump from positioning to solution exploration without validating problem

Consequence: Build solutions to unvalidated problems

Fix: Force decision point after Phase 2: "Is problem validated?" If NO, run discovery interviews.


Pitfall 2: Solo PM Exercise

Symptom: PM runs strategy session alone, presents finished strategy to team

Consequence: No buy-in, team doesn't understand rationale

Fix: Include cross-functional participants in workshops (design, eng, sales, CS)


Pitfall 3: Strategy Session Without Executive Sponsorship

Symptom: Run full strategy session, execs don't show up for Phase 5 alignment

Consequence: Strategy doesn't get resourced or prioritized

Fix: Secure exec commitment upfront; schedule Phase 5 presentation before starting.


Pitfall 4: No Decision Points (Run All Phases Regardless)

Symptom: Blindly follow all 6 phases without checking if discovery/experiments are needed

Consequence: Waste time on low-uncertainty activities

Fix: Use decision points after Phase 2 and Phase 3 to adapt workflow.


Pitfall 5: Strategy Session Becomes Permanent Process

Symptom: Team spends 6 weeks in strategy mode, never executes

Consequence: Analysis paralysis, no delivery

Fix: Time-box strategy session to 2-4 weeks; after Phase 6, move to execution.


References

Related Skills (Orchestrated by This Workflow)

Phase 1:

  • skills/positioning-workshop/SKILL.md (interactive)
  • skills/proto-persona/SKILL.md (component)
  • skills/jobs-to-be-done/SKILL.md (component)

Phase 2:

  • skills/problem-framing-canvas/SKILL.md (interactive)
  • skills/problem-statement/SKILL.md (component)
  • skills/customer-journey-mapping-workshop/SKILL.md (interactive, optional)
  • skills/discovery-interview-prep/SKILL.md (interactive, if validation needed)

Phase 3:

  • skills/opportunity-solution-tree/SKILL.md (interactive)
  • skills/lean-ux-canvas/SKILL.md (interactive, alternative)
  • skills/epic-hypothesis/SKILL.md (component)
  • skills/user-story-mapping-workshop/SKILL.md (interactive, optional)

Phase 4:

  • skills/prioritization-advisor/SKILL.md (interactive)
  • skills/tam-sam-som-calculator/SKILL.md (interactive, optional)

Phase 5:

  • skills/press-release/SKILL.md (component, optional)

Phase 6:

  • skills/epic-breakdown-advisor/SKILL.md (interactive)
  • skills/user-story/SKILL.md (component)

External Frameworks

  • Teresa Torres, Continuous Discovery Habits (2021) — Opportunity solution tree framework
  • Jeff Gothelf, Lean UX (2016) — Hypothesis-driven product development
  • Marty Cagan, Inspired (2017) — Product discovery process

Dean's Work

  • Productside Blueprint — Strategic product discovery
  • [If Dean has strategy session resources, link here]

Skill type: Workflow Suggested filename: product-strategy-session.md Suggested placement: /skills/workflows/ Dependencies: Orchestrates 15+ component and interactive skills across 6 phases

基于现有研究、市场信号和团队知识快速构建假设性用户画像(原型)。适用于产品开发早期阶段,旨在统一团队认知、指导初步设计并明确待验证的假设,而非替代深度用户研究。
需要快速对齐目标用户画像 产品开发早期缺乏完整用户数据 启动新功能或战略转型时识别假设
skills/proto-persona/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill proto-persona -g -y
SKILL.md
Frontmatter
{
    "name": "proto-persona",
    "type": "component",
    "intent": "Create an initial, assumption-based persona profile that synthesizes available user research, market data, and stakeholder knowledge into a working hypothesis about your target user. Use this to align teams early in product development, guide initial design decisions, and identify gaps in understanding that require validation through research.",
    "description": "Create a proto-persona from current research, market signals, and team knowledge. Use when you need a working customer profile before deeper validation.",
    "argument-hint": "[target user or segment]"
}

Purpose

Create an initial, assumption-based persona profile that synthesizes available user research, market data, and stakeholder knowledge into a working hypothesis about your target user. Use this to align teams early in product development, guide initial design decisions, and identify gaps in understanding that require validation through research.

This is not a validated persona—it's a "proto" (prototype) persona that evolves as you learn more. Think of it as a structured placeholder that prevents design-by-committee while acknowledging you don't have all the answers yet.

Input

Works best with: The target user or segment you need a working profile for. Also useful: Whatever signal exists — support themes, sales anecdotes, analytics, prior research — plus the decision the persona will guide.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks who you think the user is and what you already know, then structures it and flags the assumptions needing validation.

Example invocation: Proto-persona for solo bookkeepers adopting our receipt-scanning app — signal: 30 support tickets and 4 sales call notes.

Key Concepts

What is a Proto-Persona?

A proto-persona is a lightweight, hypothesis-driven persona created from:

  • Existing research: User interviews, surveys, analytics (if available)
  • Market data: Industry reports, competitor analysis, demographic trends
  • Stakeholder knowledge: Sales, support, and team insights
  • Informed assumptions: Best guesses that need validation

Proto vs. Validated Persona

Proto-Persona Validated Persona
Created in hours/days Created over weeks/months
Based on assumptions + limited research Based on extensive user research
Used to align teams early Used to guide detailed design
Evolves rapidly Stable over time
Good enough to start High confidence

Why Use Proto-Personas?

  • Speed: Align teams quickly without waiting for months of research
  • Focus: Provides a shared reference point for "who we're building for"
  • Hypothesis framing: Makes assumptions explicit, which can then be validated
  • Prevents generic design: "Design for everyone" = design for no one

Anti-Patterns (What This Is NOT)

  • Not validated research: Don't treat it as fact—it's a hypothesis
  • Not a replacement for user research: Use it to guide research, not avoid it
  • Not demographic data alone: Age and location don't explain behavior
  • Not permanent: Proto-personas should evolve as you learn

When to Use This

  • Early-stage product development (before extensive user research)
  • Kicking off a new feature or pivot
  • Aligning stakeholders on target users
  • Identifying research gaps (who do we need to interview?)

When NOT to Use This

  • After you've done extensive user research (create a validated persona instead)
  • For mature products with known user segments (you should already have validated personas)
  • As a substitute for quantitative data (proto-personas inform research; research validates them)

Application

Use template.md for the full fill-in structure.

Step 1: Gather Available Context

Before creating a proto-persona, collect:

  • User research: Interview notes, survey results, support tickets
  • Analytics: Usage data, demographics, behavioral patterns
  • Market data: Industry reports, competitor user bases
  • Stakeholder insights: Sales/support/CS teams who interact with users
  • Product context: What problem are you solving? (reference skills/problem-statement/SKILL.md)

If missing context: Don't fabricate—note gaps and plan research to fill them.


Step 2: Define the Persona's Identity

Name

Give the persona an alliterative, memorable name (makes it easier to reference).

### Name
- [Alliterative name, e.g., "Manager Mike," "Startup Sarah," "Enterprise Emma"]

Quality checks:

  • Memorable: Can the team recall it easily?
  • Not generic: Avoid "User 1" or "Persona A"

Bio & Demographics

Describe who this person is in the real world.

### Bio & Demographics
- [Age range]
- [Geographic location]
- [Social status (married, single, family, etc.)]
- [Online presence (active on LinkedIn, avoids social media, etc.)]
- [Leisure activities]
- [Career status (job title, industry, seniority)]

Quality checks:

  • Behavioral, not just demographic: Don't stop at "30-40 years old, lives in SF"—add "Works remotely, active in Slack communities, juggles 3 side projects"
  • Context-relevant: Only include demographics that influence product decisions

Example:

  • "35-45 years old, lives in urban areas (NYC, SF, Austin)"
  • "Director-level at mid-sized tech companies (50-500 employees)"
  • "Active on LinkedIn and Twitter, attends 2-3 conferences per year"
  • "Married with young kids, values work-life balance"
  • "Plays rec sports on weekends, listens to business podcasts during commute"

Step 3: Capture Their Voice

Quotes

Use real or representative quotes that reveal how they think and speak.

### Quotes
- "[Quote 1 revealing what they say, feel, or think]"
- "[Quote 2 revealing frustrations or motivations]"
- "[Quote 3 revealing attitudes or beliefs]"

Quality checks:

  • Authentic: Use real quotes from interviews/support tickets if available
  • Revealing: Quotes should expose mindset, not just facts ("I need better tools" is weak; "I'm drowning in manual work and can't focus on strategy" is strong)

Example:

  • "I spend 10 hours a week in status meetings that could be emails."
  • "I'm tired of tools that promise automation but require a developer to set up."
  • "My team expects me to have answers immediately, but I'm constantly searching for data."

Step 4: Document Their Context

Pains

What problems or frustrations does this persona experience? (Reference skills/jobs-to-be-done/SKILL.md for structure.)

### Pains
- [Pain point 1 related to the problem space]
- [Pain point 2 related to the problem space]
- [Pain point 3 related to the problem space]

Quality checks:

  • Specific: "Frustrated with tools" is vague; "Spends 3 hours/week manually copying data between tools" is specific
  • Related to your product: Focus on pains your product could address

What is This Person Trying to Accomplish?

What behaviors, actions, or outcomes are they pursuing?

### What is This Person Trying to Accomplish?
- [Behavior or outcome 1]
- [Behavior or outcome 2]
- [Behavior or outcome 3]

Quality checks:

  • Observable: Can you see this behavior? ("Get promoted" is internal; "Deliver projects 2 weeks ahead of schedule" is observable)
  • Outcome-focused: Not tasks ("use dashboards") but results ("make data-driven decisions faster")

Goals

What are their wants, needs, dreams?

### Goals
- [Goal 1: want, need, or dream]
- [Goal 2: want, need, or dream]
- [Goal 3: want, need, or dream]

Quality checks:

  • Short-term and long-term: Include tactical goals ("ship feature by Q2") and aspirational goals ("become VP within 3 years")
  • Personal and professional: "Spend more time with family" can be as relevant as "increase team productivity"

Step 5: Understand Their Influences

Decision-Making Authority

Do they have the power to buy your solution?

### Attitudes & Influences

- **Decision-Making Authority:** [Yes/No + context (e.g., "Has budget authority up to $10k, needs exec approval above that")]

Quality checks:

  • Procurement reality: If they're a user but not a buyer, note who approves the purchase

Decision Influencers

Who influences their decisions?

- **Decision Influencers:** [Who influences this person? (e.g., "Boss, peers in industry Slack channels, analyst reports")]

Quality checks:

  • Specific: Not just "their manager"—name the types of influences (peer recommendations, Gartner reports, Twitter threads, etc.)

Beliefs & Attitudes

What beliefs and attitudes shape their decisions?

- **Beliefs & Attitudes:** [Beliefs/attitudes that impact decisions (e.g., "Skeptical of tools that require training," "Values data-driven decision making")]

Quality checks:

  • Relevant to adoption: Focus on beliefs that affect whether they'd use your product

Step 6: Validate and Iterate

  • Share with the team: Does this persona resonate? Do they recognize this person?
  • Identify gaps: What don't we know? (Add "[ASSUMPTION—VALIDATE]" tags where uncertain)
  • Plan research: Use the proto-persona to guide who to interview next
  • Evolve it: As you learn, update the proto-persona (or graduate it to a validated persona)

Examples

See examples/sample.md for full proto-persona examples.

Mini example excerpt:

### Name
- Manager Mike

### Quotes
- "I spend more time in status meetings than actually building product."

Common Pitfalls

Pitfall 1: Demographics Without Behavior

Symptom: "28 years old, lives in NYC, has a dog"

Consequence: Demographics don't explain why someone would use your product.

Fix: Add behavioral context: "Works remotely, active in 5 Slack communities, values async communication tools."


Pitfall 2: Treating Proto-Persona as Fact

Symptom: "Manager Mike would never use feature X because he hates complexity"

Consequence: You're treating an assumption as validated research.

Fix: Add "[ASSUMPTION—VALIDATE]" tags and plan interviews to test hypotheses.


Pitfall 3: Creating 10 Proto-Personas

Symptom: Trying to model every possible user type upfront

Consequence: Analysis paralysis. Teams can't focus on a primary user.

Fix: Start with 1-2 proto-personas (primary + secondary). Add more as you validate and expand.


Pitfall 4: Fabricating Quotes

Symptom: Quotes that sound like marketing copy: "I love products that delight me!"

Consequence: Fake personas lead to fake empathy.

Fix: Use real quotes from interviews, support tickets, or sales calls. If you don't have quotes yet, note "[PLACEHOLDER—NEEDS RESEARCH]."


Pitfall 5: Never Validating

Symptom: Proto-persona created 6 months ago, never updated

Consequence: You're designing for a hypothesis that may be wrong.

Fix: Plan research sprints to validate key assumptions. Evolve the proto-persona as you learn. Graduate it to a validated persona when confidence is high.


References

Related Skills

  • skills/problem-statement/SKILL.md — Persona informs the "I am" section
  • skills/jobs-to-be-done/SKILL.md — JTBD informs persona pains/goals
  • skills/positioning-statement/SKILL.md — Persona is the "For [target]"
  • skills/user-story/SKILL.md — Stories use "As a [persona]"

External Frameworks

  • Alan Cooper, The Inmates Are Running the Asylum (1998) — Origin of persona concept
  • Jeff Gothelf, Lean UX (2013) — Proto-personas as hypothesis-driven research tools
  • Indi Young, Mental Models (2008) — Behavior-driven persona development

Dean's Work

  • Proto-Persona Profile Prompt (inspired by Productside Product Manager's Playbook)

Provenance

  • Adapted from prompts/proto-persona-profile.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: proto-persona.md Suggested placement: /skills/components/ Dependencies: References skills/jobs-to-be-done/SKILL.md, skills/problem-statement/SKILL.md Used by: skills/positioning-statement/SKILL.md, skills/user-story/SKILL.md, skills/problem-statement/SKILL.md

用于评估AI产品创意的结构化推荐画布,涵盖业务/客户成果、假设、风险及定位。适用于决定AI方案是否值得投资、向高管提案或对齐跨部门利益相关者,强调战略框架而非详细需求文档。
评估AI产品创意是否值得投资 向高管或决策者提案以获取预算 制定AI功能的战略推荐方案
skills/recommendation-canvas/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill recommendation-canvas -g -y
SKILL.md
Frontmatter
{
    "name": "recommendation-canvas",
    "type": "component",
    "intent": "Evaluate and propose AI product solutions using a structured canvas that assesses business outcomes, customer outcomes, problem framing, solution hypotheses, positioning, risks, and value justification. Use this to build a comprehensive, defensible recommendation for stakeholders and decision-makers—especially when proposing AI-powered features or products that carry higher uncertainty and risk.",
    "description": "Evaluate an AI product idea across outcomes, hypotheses, risks, and positioning. Use when deciding whether an AI solution deserves investment or recommendation.",
    "argument-hint": "[AI product idea]"
}

Purpose

Evaluate and propose AI product solutions using a structured canvas that assesses business outcomes, customer outcomes, problem framing, solution hypotheses, positioning, risks, and value justification. Use this to build a comprehensive, defensible recommendation for stakeholders and decision-makers—especially when proposing AI-powered features or products that carry higher uncertainty and risk.

This is not a feature spec—it's a strategic proposal that articulates why this AI solution is worth building, what assumptions need validating, and how you'll measure success.

Input

Works best with: The AI product or feature idea being evaluated. Also useful: Target customer, expected business outcome, known risks, and who the recommendation must convince.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the idea and the decision-maker, then works through the canvas boxes.

Example invocation: Recommendation canvas: AI-suggested reorder quantities for warehouse managers — VP Ops wants a go/no-go next month.

Key Concepts

The Recommendation Canvas Framework

Created for Dean Peters' Productside "AI Innovation for Product Managers" class, the canvas synthesizes multiple PM frameworks into one strategic view:

Core Components:

  1. Business Outcome: What's in it for the business?
  2. Product Outcome: What's in it for the customer?
  3. Problem Statement: Persona-centric problem framing
  4. Solution Hypothesis: If/then hypothesis with experiments
  5. Positioning Statement: Value prop and differentiation
  6. Assumptions & Unknowns: What could invalidate this?
  7. PESTEL Risks: Political, Economic, Social, Technological, Environmental, Legal
  8. Value Justification: Why this is worth doing
  9. Success Metrics: SMART metrics to measure impact
  10. What's Next: Strategic next steps

Why This Works

  • Outcome-driven: Forces clarity on business AND customer value
  • Hypothesis-centric: Treats solution as a bet to validate, not a commitment
  • Risk-explicit: Makes assumptions and risks visible upfront
  • Executive-friendly: Comprehensive but structured for C-level review
  • AI-appropriate: Especially useful for AI features with high uncertainty

Anti-Patterns (What This Is NOT)

  • Not a PRD: This is strategic framing, not detailed requirements
  • Not a business case (yet): It informs the business case but needs validation first
  • Not a feature list: Focus on outcomes, not capabilities

When to Use This

  • Proposing a new AI-powered product or feature
  • Pitching to execs or securing budget/sponsorship
  • Evaluating whether an AI solution is worth pursuing
  • Aligning cross-functional stakeholders (product, engineering, data science, business)
  • After completing initial discovery (you need context to fill this out)

When NOT to Use This

  • For trivial features (don't over-engineer small tweaks)
  • Before any discovery work (you need user research and problem validation first)
  • As a replacement for experimentation (canvas informs experiments, not vice versa)

Application

Use template.md for the full fill-in structure.

Step 1: Gather Context

Before filling out the canvas, ensure you have:

  • Problem understanding: User research, pain points (reference skills/problem-statement/SKILL.md)
  • Persona clarity: Who experiences the problem? (reference skills/proto-persona/SKILL.md)
  • Market context: Competitive landscape, category positioning
  • Business constraints: Budget, timelines, strategic priorities

If missing context: Run discovery work first. This canvas synthesizes insights—it doesn't create them.


Step 2: Define Outcomes

Business Outcome

What's in it for the business? Use this format:

  • [Direction] [Metric] [Outcome] [Context] [Acceptance Criteria]
## Business Outcome
- [e.g., "Reduce by 25% the churn of existing customers using our existing product"]

Example:

  • "Increase by 15% the monthly recurring revenue from enterprise customers within 12 months"

Quality checks:

  • Measurable: Can you track this metric?
  • Time-bound: Within what timeframe?
  • Ambitious but realistic: Not "10x revenue in 1 month"

Product Outcome

What's in it for the customer? Use this format:

  • [Direction] [Metric] [Outcome] [Context from persona's POV] [Acceptance Criteria]
## Product Outcome
- [e.g., "Increase the speed of finding patients when I know the inclusion and exclusion criteria"]

Example:

  • "Reduce by 60% the time spent manually processing invoices for small business owners"

Quality checks:

  • Customer-centric: Written from user perspective ("I," not "we")
  • Outcome, not feature: "Reduce time spent" not "Use AI automation"

Step 3: Frame the Problem

Use the problem framing narrative from skills/problem-statement/SKILL.md:

## The Problem Statement

### Problem Statement Narrative
- [Persona description: 2-3 sentences telling the persona's story from their POV]
- [Example: "Sarah is a freelance designer managing 10 clients. She spends 8 hours/month manually tracking invoices and chasing late payments. By the time she follows up, some clients have already moved to other designers, costing her revenue and damaging relationships."]

Quality checks:

  • Empathetic: Does this sound like the user's voice?
  • Specific: Not "users want better tools" but "Sarah spends 8 hours/month..."
  • Validated: Based on real user research, not assumptions

Step 4: Define the Solution Hypothesis

Hypothesis Statement

Use the epic hypothesis format from skills/epic-hypothesis/SKILL.md:

## Solution Hypothesis

### Hypothesis Statement
**If we** [action or solution on behalf of target persona]
**for** [target persona]
**Then we will** [attain or achieve desirable outcome]

Example:

  • "If we provide AI-powered invoice reminders that auto-send at optimal times for freelance designers, then we will reduce time spent on payment follow-ups by 70%"

Tiny Acts of Discovery

Define lightweight experiments to validate the hypothesis:

### Tiny Acts of Discovery
**We will test our assumption by:**
- [Experiment 1: Prototype AI reminder system and test with 5 freelancers]
- [Experiment 2: A/B test manual vs. AI-timed reminders for 20 users]
- [Experiment 3: Survey users on perceived value after 2 weeks]

Quality checks:

  • Fast: Days/weeks, not months
  • Cheap: Prototypes, concierge tests, not full builds
  • Falsifiable: Could prove you wrong

Proof-of-Life

Define validation measures:

### Proof-of-Life
**We know our hypothesis is valid if within** [timeframe]
**we observe:**
- [Quantitative outcome: e.g., "80% of users send reminders via the AI system"]
- [Qualitative outcome: e.g., "8 out of 10 users report saving 5+ hours/month"]

Step 5: Define Positioning

Use the positioning statement format from skills/positioning-statement/SKILL.md:

## Positioning Statement

### Value Proposition
**For** [target customer/user persona]
**that need** [statement of underserved need]
[product name]
**is a** [product category]
**that** [statement of benefit, focusing on outcomes]

### Differentiation Statement
**Unlike** [primary competitor or competitive arena]
[product name]
**provides** [unique differentiation, focusing on outcomes]

Step 6: Document Assumptions & Unknowns

## Assumptions & Unknowns
- **[Assumption 1]** - [Description, e.g., "We assume users will trust AI-generated reminders"]
- **[Assumption 2]** - [Description, e.g., "We assume payment timing optimization increases response rates"]
- **[Unknown 1]** - [Description, e.g., "We don't know if users prefer email or SMS reminders"]

Quality checks:

  • Explicit: Make hidden assumptions visible
  • Testable: Each assumption can be validated via experiments

Step 7: Identify PESTEL Risks

Risks to Investigate (High Priority)

## Issues/Risks to Investigate
- **Political:** [e.g., "Regulatory changes to AI-generated communications"]
- **Economic:** [e.g., "Economic downturn reduces willingness to pay for premium features"]
- **Social:** [e.g., "Users may perceive AI reminders as impersonal or pushy"]
- **Technological:** [e.g., "AI model accuracy may degrade over time without retraining"]
- **Environmental:** [e.g., "Energy costs of AI processing"]
- **Legal:** [e.g., "GDPR compliance for storing customer email patterns"]

Risks to Monitor (Lower Priority)

## Issues/Risks to Monitor
- **Political:** [e.g., "Potential AI regulation in EU markets"]
- **Economic:** [e.g., "Exchange rate fluctuations affecting international customers"]
- **Social:** [e.g., "Changing norms around automated communication"]
- **Technological:** [e.g., "Emerging AI competitors with better models"]
- **Environmental:** [e.g., "Carbon footprint concerns from stakeholders"]
- **Legal:** [e.g., "Future data privacy laws"]

Step 8: Justify the Value

## Value Justification

### Is this Valuable?
- [Absolutely yes / Yes with caveats / No with suggested alternatives / Absolutely NO!]

### Solution Justification
<!-- Write these to convince C-level executives -->
We think this is a valuable idea. Here's why:
1. **[Justification 1]** - [Description, e.g., "Addresses the #1 pain point for our target segment"]
2. **[Justification 2]** - [Description, e.g., "Differentiates us from competitors who only offer manual reminders"]
3. **[Justification 3]** - [Description, e.g., "Low technical risk—leverages existing AI infrastructure"]

Step 9: Define Success Metrics

Use SMART metrics (Specific, Measurable, Attainable, Relevant, Time-Bound):

## Success Metrics
1. **[Metric 1]** - [e.g., "80% of active users adopt AI reminders within 3 months"]
2. **[Metric 2]** - [e.g., "Average time spent on payment follow-ups decreases by 50% within 6 months"]
3. **[Metric 3]** - [e.g., "Net Promoter Score for invoicing feature increases from 6 to 8 within 6 months"]

Step 10: Define Next Steps

## What's Next
1. **[Next step 1]** - [e.g., "Run 2-week prototype test with 10 beta users"]
2. **[Next step 2]** - [e.g., "Build lightweight AI model for reminder timing optimization"]
3. **[Next step 3]** - [e.g., "Conduct legal review of GDPR implications"]
4. **[Next step 4]** - [e.g., "Present findings to exec team for go/no-go decision"]
5. **[Next step 5]** - [e.g., "If validated, add to Q2 roadmap"]

Examples

See examples/sample.md for a full recommendation canvas example.

Mini example excerpt:

### Business Outcome
- Increase by 20% MRR from freelance users within 12 months

### Solution Hypothesis
**If we** provide AI-powered invoice reminders
**for** freelance designers
**Then we will** reduce time spent on follow-ups by 70%

Common Pitfalls

Pitfall 1: Vague Outcomes

Symptom: "Business outcome: increase revenue. Product outcome: improve UX."

Consequence: No measurability or accountability.

Fix: Use the outcome formula: [Direction] [Metric] [Outcome] [Context] [Acceptance Criteria]. Be specific.


Pitfall 2: Solution-First Thinking

Symptom: Problem statement is "We need AI-powered X"

Consequence: You've jumped to solution without validating the problem.

Fix: Frame problem from user perspective. Let the solution hypothesis emerge from validated pain points.


Pitfall 3: Skipping Tiny Acts of Discovery

Symptom: Hypothesis → straight to roadmap, no experiments

Consequence: High risk of building the wrong thing.

Fix: Define 2-3 lightweight experiments. Test before committing engineering resources.


Pitfall 4: Generic PESTEL Risks

Symptom: "Political: regulations might change"

Consequence: Risk analysis is theater, not actionable.

Fix: Be specific: "GDPR compliance for storing client email timing data requires legal review."


Pitfall 5: Weak Value Justification

Symptom: "This is valuable because customers will like it"

Consequence: Not convincing to execs.

Fix: Use data: "Addresses #1 pain point per user research. 20% churn reduction = $500k ARR. Low tech risk."


References

Related Skills

  • skills/problem-statement/SKILL.md — Informs the problem narrative
  • skills/epic-hypothesis/SKILL.md — Informs the solution hypothesis structure
  • skills/positioning-statement/SKILL.md — Informs positioning section
  • skills/proto-persona/SKILL.md — Defines target persona
  • skills/jobs-to-be-done/SKILL.md — Informs customer outcomes

External Frameworks

  • Osterwalder's Value Proposition Canvas — Influences problem/solution framing
  • PESTEL Analysis — Risk assessment framework
  • SMART Goals — Success metrics structure

Dean's Work

  • AI Recommendation Canvas Template (created for Productside "AI Innovation for Product Managers" class)

Provenance

  • Adapted from prompts/recommendation-canvas-template.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: recommendation-canvas.md Suggested placement: /skills/components/ Dependencies: References skills/problem-statement/SKILL.md, skills/epic-hypothesis/SKILL.md, skills/positioning-statement/SKILL.md, skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md

指导产品经理通过优先级排序、史诗定义、利益相关者对齐和发布序列,将战略转化为可执行的路线图。旨在避免功能工厂式规划,构建以结果为导向、逻辑连贯且具战略叙事能力的沟通工具,而非简单的甘特图。
制定季度或年度产品路线图 将战略目标转化为具体执行计划 需要协调多方利益相关者对齐预期 从分散的需求列表中梳理出结构化发布计划
skills/roadmap-planning/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill roadmap-planning -g -y
SKILL.md
Frontmatter
{
    "name": "roadmap-planning",
    "type": "workflow",
    "theme": "strategy-positioning",
    "intent": "Guide product managers through strategic roadmap planning by orchestrating prioritization, epic definition, stakeholder alignment, and release sequencing skills into a structured process. Use this to move from disconnected feature requests to a cohesive, outcome-driven roadmap that aligns stakeholders, sequences work logically, and communicates strategic intent—avoiding \"feature factory\" roadmaps that lack strategic narrative or customer-centric framing.",
    "best_for": [
        "Building a strategic roadmap that survives exec review",
        "Prioritizing competing initiatives across multiple teams",
        "Planning and sequencing work for the next quarter or half-year"
    ],
    "scenarios": [
        "I have 15 competing initiatives and need to build a Q2 roadmap my exec team will actually approve",
        "I'm planning our 6-month product roadmap and need to sequence work across 3 teams"
    ],
    "description": "Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.",
    "argument-hint": "[product and planning horizon]",
    "estimated_time": "45-90 min"
}

Purpose

Guide product managers through strategic roadmap planning by orchestrating prioritization, epic definition, stakeholder alignment, and release sequencing skills into a structured process. Use this to move from disconnected feature requests to a cohesive, outcome-driven roadmap that aligns stakeholders, sequences work logically, and communicates strategic intent—avoiding "feature factory" roadmaps that lack strategic narrative or customer-centric framing.

This is not a Gantt chart—it's a strategic communication tool that shows what you're building, why it matters, and how it ladders up to business outcomes.

Input

Works best with: The product and planning horizon (next quarter, next year). Also useful: Strategy or OKRs to ladder to, the candidate initiative list, team capacity, and known stakeholder pressures.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workflow starts by establishing strategic context, then moves through prioritization, epic definition, and sequencing.

Example invocation: Plan a 2-quarter roadmap for our mobile app: here are our 3 OKRs and a list of 12 candidate initiatives.

Key Concepts

What is Strategic Roadmap Planning?

Roadmap planning is the process of:

  1. Gathering inputs — Customer problems, business goals, technical constraints
  2. Defining initiatives — Epics with clear hypotheses and success metrics
  3. Prioritizing — Rank initiatives by impact, effort, strategic fit
  4. Sequencing — Organize into releases/quarters with logical dependencies
  5. Communicating — Present roadmap to stakeholders with strategic narrative

Types of Roadmaps

Now/Next/Later Roadmap:

  • Now: Current quarter (committed)
  • Next: Following quarter (high confidence)
  • Later: Future exploration (low confidence)
  • Best for: Agile teams, uncertainty, continuous discovery

Theme-Based Roadmap:

  • Organize by strategic themes (e.g., "Retention," "Enterprise Expansion," "Mobile Experience")
  • Best for: Communicating to execs, showing strategic intent

Timeline Roadmap (Quarters):

  • Q1: Epics A, B; Q2: Epics C, D; Q3: Epics E, F
  • Best for: Resource planning, stakeholder communication

Feature-Based Roadmap (Anti-Pattern):

  • Lists features without context (e.g., "Dark mode," "SSO," "Advanced reporting")
  • Why it fails: No strategic narrative, no customer problems framed

Why This Works

  • Outcome-driven: Ties initiatives to business/customer outcomes
  • Stakeholder alignment: Transparent process reduces political friction
  • Strategic clarity: Shows not just "what" but "why"
  • Flexible: Adapts as you learn from discovery/delivery

Anti-Patterns (What This Is NOT)

  • Not a commitment: Roadmaps are strategic plans, not contracts
  • Not a feature list: Roadmaps frame problems, not just solutions
  • Not waterfall: Roadmaps evolve quarterly based on learning

When to Use This

  • Annual or quarterly planning cycles
  • After product strategy session (translate strategy to roadmap)
  • Onboarding new stakeholders (align on direction)
  • Reframing existing roadmap (shift from feature-driven to outcome-driven)

When NOT to Use This

  • For tactical sprint planning (use backlog instead)
  • When strategy is unclear (run product-strategy-session first)
  • When stakeholders expect date commitments (address expectations first)

Facilitation Source of Truth

When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.

Application

Use template.md for the full fill-in structure.

This workflow orchestrates 5 phases over 1-2 weeks, using multiple component and interactive skills.


Phase 1: Gather Inputs (Day 1-2)

Goal: Collect business goals, customer problems, technical constraints, stakeholder requests.

Activities

1. Review Business Goals (OKRs, Strategic Initiatives)

  • Source: Company OKRs, exec strategy memos, board decks
  • Questions:
    • What are the company's top 3 priorities this year?
    • What metrics must we move? (revenue, retention, acquisition, efficiency)
    • Are there strategic bets? (new markets, partnerships, product lines)
  • Output: 3-5 business outcomes to optimize for

2. Review Customer Problems (Discovery Insights)

  • Source: Discovery interviews, support tickets, NPS feedback, churn surveys
  • Use: Insights from skills/discovery-process/SKILL.md (if recently completed)
  • Questions:
    • What are the top 3-5 customer pain points?
    • Which problems affect the most customers?
    • Which problems have highest intensity?
  • Output: 3-5 validated customer problems

3. Review Technical Constraints & Opportunities

  • Source: Engineering leadership, tech debt assessments
  • Questions:
    • Are there technical blockers? (scaling, performance, security)
    • Are there enabling investments? (platform upgrades, API rewrites)
    • What's the technical roadmap? (migrations, deprecations)
  • Output: List of technical investments required

4. Review Stakeholder Requests

  • Source: Sales, marketing, customer success, execs
  • Questions:
    • What are sales asking for? (enterprise features, integrations)
    • What's marketing requesting? (growth initiatives, positioning)
    • What's customer success flagging? (churn risks, expansion blockers)
  • Output: List of stakeholder requests (not yet committed)

Outputs from Phase 1

  • Business outcomes: 3-5 OKRs or strategic goals
  • Customer problems: 3-5 validated pain points
  • Technical investments: Platform/tech debt items
  • Stakeholder requests: Feature requests from internal teams

Phase 2: Define Initiatives (Epics) (Day 3-4)

Goal: Turn inputs into epics with hypotheses, success metrics, and effort estimates.

Activities

1. Define Epic Hypotheses

  • Use: skills/epic-hypothesis/SKILL.md (component)
  • For each initiative: Write hypothesis statement
  • Format: "We believe that [building X] for [persona] will achieve [outcome] because [assumption]."
  • Participants: PM
  • Duration: 60 minutes per epic
  • Output: 10-15 epic hypotheses

Example Epics (SaaS Product):

Epic 1: Guided Onboarding
Hypothesis: We believe that adding a step-by-step onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.

Success Metric: Activation rate (% completing first action within 24 hours)
Target: 40% → 60%

Epic 2: Enterprise SSO
Hypothesis: We believe that adding SSO for enterprise accounts will increase enterprise deals closed from 2/quarter to 5/quarter because enterprise buyers require SSO for security compliance.

Success Metric: Enterprise deals closed per quarter
Target: 2 → 5

Epic 3: Mobile-Optimized Workflows
Hypothesis: We believe that optimizing core workflows for mobile will increase mobile DAU from 5% to 20% because mobile-first users currently can't complete workflows on the go.

Success Metric: Mobile DAU as % of total DAU
Target: 5% → 20%

2. Estimate Effort (T-Shirt Sizing)

  • Participants: PM + engineering lead
  • Duration: 90 minutes
  • Method:
    • Small (S): 1-2 weeks (1-2 engineers)
    • Medium (M): 3-4 weeks (2-3 engineers)
    • Large (L): 2-3 months (3-5 engineers)
    • Extra Large (XL): 3+ months (5+ engineers)
  • Output: Effort estimate per epic

3. Map to Business Outcomes

  • For each epic: Tag with primary business outcome
  • Example:
    • Epic 1 (Guided Onboarding) → Retention
    • Epic 2 (Enterprise SSO) → Acquisition (enterprise)
    • Epic 3 (Mobile Workflows) → Engagement

Outputs from Phase 2

  • 10-15 epics: Each with hypothesis, success metric, effort estimate
  • Business outcome mapping: Which epics drive which OKRs

Phase 3: Prioritize Initiatives (Day 5)

Goal: Rank epics by impact, effort, and strategic fit.

Activities

1. Choose Prioritization Framework

  • Use: skills/prioritization-advisor/SKILL.md (interactive)
  • Participants: PM
  • Duration: 30 minutes
  • Output: Recommended framework (RICE, ICE, Value/Effort, etc.)

2. Score Epics

  • Participants: PM, engineering lead, product leadership
  • Duration: 120 minutes
  • Method: Apply framework to all epics
  • Example (RICE scoring):
Epic Reach Impact Confidence Effort RICE Score
Guided Onboarding 10,000 users 3 (massive) 80% 1 month 24,000
Enterprise SSO 500 users 3 (massive) 90% 2 months 675
Mobile Workflows 5,000 users 2 (high) 60% 3 months 2,000
Advanced Reporting 2,000 users 2 (high) 50% 2 months 1,000

3. Adjust for Strategic Fit

  • Review scores: Do they align with business goals?
  • Strategic overrides: Promote epics that align with strategic bets (even if score is lower)
  • Example: Enterprise SSO scores lower, but it's critical for enterprise expansion strategy → boost priority

Outputs from Phase 3

  • Ranked backlog: Epics sorted by priority (RICE score + strategic adjustments)
  • Top 10 epics: Highest-priority initiatives for roadmap

Phase 4: Sequence Roadmap (Day 6-7)

Goal: Organize epics into quarters/releases with logical dependencies.

Activities

1. Map Dependencies

  • Questions:
    • Does Epic B depend on Epic A? (e.g., "Advanced Reporting" requires "Data Pipeline Upgrade")
    • Are there technical blockers? (e.g., "Mobile App" requires "API Redesign")
  • Output: Dependency graph (Epic A → Epic B → Epic C)

2. Sequence by Quarter (or Release)

  • Now (Q1): Top 3-5 epics, no dependencies
  • Next (Q2): Next 3-5 epics, may depend on Q1 completion
  • Later (Q3+): Remaining epics, lower confidence

Example Roadmap (Timeline-Based):

Q1 2026 (Now - Committed):
├─ Guided Onboarding (Retention)
├─ Enterprise SSO (Acquisition)
└─ Mobile-Optimized Workflows (Engagement)

Q2 2026 (Next - High Confidence):
├─ Advanced Reporting (depends on Data Pipeline, Q1)
├─ Slack Integration (Engagement)
└─ Pricing Page Redesign (Acquisition)

Q3 2026 (Later - Lower Confidence):
├─ Mobile App (depends on API Redesign)
├─ AI-Powered Recommendations
└─ Multi-Language Support

Q4 2026 (Exploration):
├─ Marketplace/Plugin Ecosystem
└─ Enterprise Onboarding Concierge

Alternative: Now/Next/Later Roadmap

NOW (Current Quarter):
- Guided Onboarding
- Enterprise SSO
- Mobile-Optimized Workflows

NEXT (Following Quarter):
- Advanced Reporting
- Slack Integration
- Pricing Page Redesign

LATER (Future):
- Mobile App
- AI Recommendations
- Multi-Language Support

3. Validate with Engineering

  • Participants: PM + engineering lead
  • Questions:
    • Is sequencing realistic? (capacity, dependencies)
    • Are there hidden technical blockers?
    • Do we need to adjust scope?
  • Output: Validated roadmap sequence

Outputs from Phase 4

  • Sequenced roadmap: Epics organized by Q1, Q2, Q3
  • Dependency map: What depends on what
  • Capacity check: Engineering agrees sequence is feasible

Phase 5: Communicate Roadmap (Week 2)

Goal: Present roadmap to stakeholders, gather feedback, build alignment.

Activities

1. Create Roadmap Presentation

  • Format: 30-45 min presentation
  • Structure:
    • Slide 1: Strategic context (business goals, customer problems)
    • Slide 2-3: Roadmap overview (Q1, Q2, Q3)
    • Slide 4-6: Deep dive per quarter (epics, hypotheses, success metrics)
    • Slide 7: What's NOT on roadmap (and why)
    • Slide 8: Dependencies and risks
  • Participants: PM, design
  • Duration: 2-3 hours to prepare

2. Present to Stakeholders

  • Audience: Execs, product leadership, engineering, sales, marketing, CS
  • Duration: 45 min presentation + 15 min Q&A
  • Focus:
    • Strategic narrative: "Here's why we're prioritizing X over Y"
    • Outcome focus: "Each epic drives [business outcome]"
    • Flexibility: "This roadmap is a plan, not a commitment; we'll adjust as we learn"

3. Gather Feedback

  • Questions to ask:
    • Do these priorities align with business goals?
    • Are we missing critical customer problems?
    • Are dependencies clear?
    • What concerns do you have?
  • Output: List of feedback, concerns, questions

4. Refine Roadmap

  • Based on feedback: Adjust priorities, add missing epics, clarify dependencies
  • Duration: 1-2 days
  • Output: Final roadmap v1.0

5. Publish Roadmap

  • Internal: Share with team (Confluence, Notion, Productboard, etc.)
  • External (Optional): Public roadmap for customers (use Now/Next/Later format)
  • Format: Visual roadmap + narrative doc

Outputs from Phase 5

  • Roadmap presentation: 30-45 min deck
  • Stakeholder alignment: Feedback incorporated, concerns addressed
  • Published roadmap: Accessible to team (internal) or customers (external)

Complete Workflow: End-to-End Summary

Week 1:
├─ Day 1-2: Gather Inputs
│  ├─ Review business goals (OKRs)
│  ├─ Review customer problems (discovery insights)
│  ├─ Review technical constraints
│  └─ Review stakeholder requests
│
├─ Day 3-4: Define Initiatives (Epics)
│  ├─ skills/epic-hypothesis/SKILL.md (60 min per epic)
│  ├─ Estimate effort (90 min)
│  └─ Map to business outcomes
│
├─ Day 5: Prioritize Initiatives
│  ├─ skills/prioritization-advisor/SKILL.md (30 min)
│  ├─ Score epics (120 min)
│  └─ Adjust for strategic fit
│
└─ Day 6-7: Sequence Roadmap
   ├─ Map dependencies
   ├─ Sequence by quarter (Q1, Q2, Q3)
   └─ Validate with engineering

Week 2:
└─ Communicate Roadmap
   ├─ Create presentation (2-3 hours)
   ├─ Present to stakeholders (60 min)
   ├─ Gather feedback
   ├─ Refine roadmap (1-2 days)
   └─ Publish roadmap

Total Time Investment:

  • Fast track: 1 week (existing epics, quick alignment)
  • Typical: 1.5-2 weeks (define epics, stakeholder review)

Examples

See examples/sample.md for full roadmap examples.

Mini example excerpt:

Now: Guided onboarding (activation +20%)
Next: Enterprise SSO (deal velocity)
Later: Mobile workflows (DAU lift)

Common Pitfalls

Pitfall 1: Feature-Driven Roadmap (No Outcomes)

Symptom: Roadmap lists features ("Dark mode," "SSO," "Advanced filters") with no context

Consequence: No strategic clarity, stakeholders don't understand "why"

Fix: Frame epics as hypotheses with success metrics (not just feature names)


Pitfall 2: Prioritizing by HiPPO (Highest Paid Person's Opinion)

Symptom: Execs dictate roadmap, no data-driven prioritization

Consequence: Build wrong things, ignore customer problems

Fix: Use prioritization framework (RICE, ICE) to transparently score epics


Pitfall 3: Roadmap as Commitment (Waterfall Thinking)

Symptom: Roadmap treated as contract, no flexibility to adjust

Consequence: Can't pivot when you learn new information

Fix: Communicate roadmap as "strategic plan, subject to change based on learning"


Pitfall 4: No Dependencies Mapped

Symptom: Sequence epics without checking technical dependencies

Consequence: Q2 epic blocked because Q1 dependency didn't finish

Fix: Map dependencies explicitly in Phase 4, validate with engineering


Pitfall 5: Solo PM Roadmap (No Stakeholder Input)

Symptom: PM creates roadmap alone, presents finished plan

Consequence: No buy-in, stakeholders feel excluded

Fix: Gather inputs (Phase 1) from all stakeholders, present draft (Phase 5) for feedback


References

Related Skills (Orchestrated by This Workflow)

Phase 2:

  • skills/epic-hypothesis/SKILL.md (component)

Phase 3:

  • skills/prioritization-advisor/SKILL.md (interactive)

Phase 4:

  • (Dependencies mapped manually, no specific skill)

Phase 5:

  • (Presentation created manually, no specific skill)

Optional/Related:

  • skills/product-strategy-session/SKILL.md (workflow) — Run before roadmap planning to establish strategy
  • skills/discovery-process/SKILL.md (workflow) — Provides customer problem inputs for Phase 1
  • skills/user-story-mapping-workshop/SKILL.md (interactive) — For complex epics requiring release planning

External Frameworks

  • Bruce McCarthy, Product Roadmaps Relaunched (2017) — Outcome-driven roadmaps
  • C. Todd Lombardo, Product Roadmaps Relaunched (2017) — Now/Next/Later framework
  • Intercom, "RICE Prioritization" (2016) — Prioritization framework

Dean's Work

  • [If Dean has roadmap planning resources, link here]

Skill type: Workflow Suggested filename: roadmap-planning.md Suggested placement: /skills/workflows/ Dependencies: Orchestrates skills/epic-hypothesis/SKILL.md, skills/prioritization-advisor/SKILL.md, plus manual activities

评估SaaS单位经济与资本效率,判断业务是否具备可扩展性及盈利基础。涵盖CAC、LTV、毛利率等核心指标计算与基准对比,辅助PM在增长与优化间做决策,适用于融资、董事会汇报及投资权衡。
询问SaaS业务是否具备规模化扩展能力 需要评估客户获取成本(CAC)与生命周期价值(LTV)比率 决定融资或优化现金流策略 分析产品功能对毛利率的影响
skills/saas-economics-efficiency-metrics/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill saas-economics-efficiency-metrics -g -y
SKILL.md
Frontmatter
{
    "name": "saas-economics-efficiency-metrics",
    "type": "component",
    "intent": "Determine whether your SaaS business model is fundamentally viable and capital-efficient. Use this to calculate unit economics, assess profitability, manage cash runway, and decide when to scale vs. optimize. Essential for fundraising, board reporting, and making smart investment trade-offs.",
    "best_for": [
        "Checking whether a SaaS model is financially viable",
        "Reviewing CAC, LTV, payback, burn, and Rule of 40 together",
        "Preparing efficiency analysis for a board or leadership review"
    ],
    "scenarios": [
        "Evaluate our SaaS unit economics before we scale paid acquisition",
        "Help me analyze CAC payback, LTV, and burn for our product",
        "I need a SaaS efficiency check for our board deck"
    ],
    "description": "Evaluate SaaS unit economics and capital efficiency. Use when deciding whether the business can scale efficiently or needs correction.",
    "argument-hint": "[metrics or question]"
}

Purpose

Determine whether your SaaS business model is fundamentally viable and capital-efficient. Use this to calculate unit economics, assess profitability, manage cash runway, and decide when to scale vs. optimize. Essential for fundraising, board reporting, and making smart investment trade-offs.

This is not a finance reporting tool—it's a framework for PMs to understand whether the business can sustain growth, when to prioritize efficiency over growth, and which investments have positive returns.

Input

Works best with: The question you're answering (can we scale? raise? extend runway?) or the metrics you want evaluated. Also useful: Your numbers — CAC, gross margin, burn, runway, magic number — partial data is workable.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. Use it as a reference: read the metric sections relevant to your stage and decision.

Example invocation: Are we efficient enough to scale? CAC $9K, gross margin 72%, burn multiple 2.1, magic number 0.6.

Key Concepts

Unit Economics Family

Metrics that measure profitability at the customer level—the foundation of sustainable SaaS.

Gross Margin — Percentage of revenue remaining after direct costs (COGS).

  • Why PMs care: A feature that generates $1M revenue at 80% margin is worth far more than $1M at 30% margin. Margin determines which features to prioritize.
  • Formula: (Revenue - COGS) / Revenue × 100
  • COGS includes: Hosting, infrastructure, payment processing, customer onboarding costs
  • Benchmark: SaaS 70-85% good; <60% concerning

CAC (Customer Acquisition Cost) — Total cost to acquire one customer.

  • Why PMs care: Shapes entire go-to-market strategy. Determines which channels are viable and how much you can invest in product-led growth.
  • Formula: Total Sales & Marketing Spend / New Customers Acquired
  • Benchmark: Varies by model—Enterprise $10K+ ok; SMB <$500 target
  • Include: Marketing spend, sales salaries, tools, commissions

LTV (Lifetime Value) — Total revenue expected from one customer over their lifetime.

  • Why PMs care: Tells you what you can afford to spend on acquisition. Higher LTV enables premium channels and longer payback periods.
  • Formula (simple): ARPU × Average Customer Lifetime (months)
  • Formula (better): ARPU × Gross Margin % / Churn Rate
  • Formula (advanced): Account for expansion, discount rates, cohort-specific retention
  • Benchmark: Must be 3x+ CAC; varies by segment

LTV:CAC Ratio — Efficiency of customer acquisition spending.

  • Why PMs care: Is growth sustainable or are you buying revenue at a loss? Determines when to scale vs. optimize.
  • Formula: LTV / CAC
  • Benchmark: 3:1 healthy; <1:1 unsustainable; >5:1 might be underinvesting
  • Note: This ratio alone doesn't tell the full story—also need payback period

Payback Period — Months to recover CAC from customer revenue.

  • Why PMs care: Cash efficiency. Faster payback = reinvest sooner. Slow payback can kill growth even with good LTV:CAC.
  • Formula: CAC / (Monthly ARPU × Gross Margin %)
  • Benchmark: <12 months great; 12-18 ok; >24 months concerning
  • Critical: Must have cash to sustain payback period

Contribution Margin — Revenue remaining after ALL variable costs (not just COGS).

  • Why PMs care: True unit profitability. Includes support, processing fees, variable OpEx.
  • Formula: (Revenue - All Variable Costs) / Revenue × 100
  • Variable costs: COGS + support + payment processing + variable customer success
  • Benchmark: 60-80% good for SaaS; <40% concerning

Gross Margin Payback — Payback period using actual profit, not revenue.

  • Why PMs care: More accurate than simple payback. Shows true cash recovery time.
  • Formula: CAC / (Monthly ARPU × Gross Margin %)
  • Benchmark: Typically 1.5-2x longer than simple revenue payback

CAC Payback by Channel — Compare payback across acquisition channels.

  • Why PMs care: Not all channels are created equal. Optimize channel mix based on payback efficiency.
  • Formula: Calculate CAC and payback separately for each channel
  • Use: Allocate budget to faster-payback channels when cash-constrained

Capital Efficiency Family

Metrics that measure how efficiently you use cash to grow the business.

Burn Rate — Cash consumed per month.

  • Why PMs care: Determines what you can build and when you need funding. High burn requires aggressive revenue growth.
  • Formula (Gross Burn): Monthly Cash Spent (all expenses)
  • Formula (Net Burn): Monthly Cash Spent - Monthly Revenue
  • Benchmark: Net burn <$200K manageable for early stage; >$500K needs clear path to revenue

Runway — Months until cash runs out.

  • Why PMs care: Literal survival metric. Dictates timeline for milestones, fundraising, profitability.
  • Formula: Cash Balance / Monthly Net Burn
  • Benchmark: 12+ months good; 6-12 manageable; <6 months crisis mode
  • Rule: Raise when you have 6-9 months runway, not 3 months

OpEx (Operating Expenses) — Costs to run the business (excluding COGS).

  • Why PMs care: Your team's salaries live here. Where "efficiency" cuts happen during downturns.
  • Categories: Sales & Marketing (S&M), Research & Development (R&D), General & Administrative (G&A)
  • Benchmark: Should grow slower than revenue as you scale (operating leverage)

Net Income (Profit Margin) — Actual profit or loss after all expenses.

  • Why PMs care: True bottom line. Are you making money? Can you self-fund growth?
  • Formula: Revenue - All Expenses (COGS + OpEx)
  • Benchmark: Early SaaS often negative (growth mode); mature should be 10-20%+ margin

Working Capital Impact — Cash timing differences between revenue recognition and cash collection.

  • Why PMs care: Annual contracts paid upfront boost cash. Monthly billing delays cash. Affects runway calculations.
  • Example: $1M annual contract paid upfront = $1M cash now, not $83K/month
  • Use: Understand cash vs. revenue timing when planning runway

Efficiency Ratios Family

Composite metrics that measure growth vs. profitability trade-offs.

Rule of 40 — Growth rate + profit margin should exceed 40%.

  • Why PMs care: Framework for balancing growth vs. efficiency. Guides when to prioritize profitability over growth.
  • Formula: Revenue Growth Rate % + Profit Margin %
  • Benchmark: >40 healthy; 25-40 acceptable; <25 concerning
  • Example: 60% growth + (-20%) margin = 40 (healthy growth-mode SaaS)
  • Example: 20% growth + 25% margin = 45 (healthy mature SaaS)

Magic Number — Sales & marketing efficiency.

  • Why PMs care: Is your GTM engine working? Should you scale spend or optimize first?
  • Formula: (Current Quarter Revenue - Previous Quarter Revenue) × 4 / Previous Quarter S&M Spend
  • Benchmark: >0.75 efficient; 0.5-0.75 ok; <0.5 fix before scaling
  • Note: "× 4" annualizes quarterly revenue change

Operating Leverage — How revenue growth compares to cost growth.

  • Why PMs care: Are you scaling efficiently? Revenue should grow faster than costs.
  • Measure: Revenue growth rate vs. OpEx growth rate over time
  • Good: Revenue growth 50%, OpEx growth 30% (positive leverage)
  • Bad: Revenue growth 20%, OpEx growth 40% (negative leverage)

Unit Economics — General term for profitability of each "unit" (customer, seat, transaction).

  • Why PMs care: Is the business model fundamentally viable at the unit level?
  • Calculate: Revenue per unit - Cost per unit
  • Requirement: Positive contribution required; aim for >$0 after all variable costs

Anti-Patterns (What This Is NOT)

  • Not vanity metrics: High LTV means nothing if payback takes 4 years and customers churn at 3 years.
  • Not static benchmarks: "Good" CAC varies wildly by business model (PLG vs. enterprise sales).
  • Not isolated numbers: LTV:CAC ratio without payback period can mislead (great ratio, terrible cash efficiency).
  • Not just finance's problem: PMs must own unit economics—every feature decision impacts margins and CAC.

When to Use These Metrics

Use these when:

  • Evaluating whether to scale acquisition (LTV:CAC, payback, magic number)
  • Deciding feature investments (margin impact, contribution to LTV)
  • Planning runway and fundraising (burn rate, runway, Rule of 40)
  • Comparing customer segments or channels (unit economics by segment)
  • Board/investor reporting (Rule of 40, magic number, LTV:CAC)
  • Choosing between growth and profitability (Rule of 40 trade-offs)

Don't use these when:

  • Making decisions without revenue context (pair with saas-revenue-growth-metrics)
  • Comparing across wildly different business models without normalization
  • Early product discovery (pre-revenue focus on PMF, not unit economics)
  • Short-term tactical decisions (use engagement metrics, not LTV)

Application

Step 1: Calculate Unit Economics

Use the templates in template.md to calculate your unit economics metrics.

Gross Margin

Gross Margin = (Revenue - COGS) / Revenue × 100

COGS includes:
- Hosting & infrastructure costs
- Payment processing fees
- Customer onboarding costs
- Direct delivery costs

Example:

  • Revenue: $1,000,000
  • COGS: $200,000 (hosting $120K, processing $50K, onboarding $30K)
  • Gross Margin = ($1M - $200K) / $1M = 80%

Quality checks:

  • Is gross margin improving as you scale? (Should benefit from economies of scale)
  • Which products/features have highest margins? (Prioritize those)
  • Are margins >70%? (SaaS should be high-margin)

CAC (Customer Acquisition Cost)

CAC = Total Sales & Marketing Spend / New Customers Acquired

Include in S&M spend:
- Marketing salaries & tools
- Sales salaries & commissions
- Advertising & paid channels
- SDR/BDR team costs

Example:

  • Sales & Marketing Spend: $500,000/month
  • New Customers: 100/month
  • CAC = $500,000 / 100 = $5,000

Quality checks:

  • Is CAC consistent across channels? (Calculate by channel)
  • Is CAC increasing or decreasing over time? (Should decrease with scale)
  • Does CAC vary by customer segment? (SMB vs. Enterprise)

LTV (Lifetime Value)

LTV (Simple) = ARPU × Average Customer Lifetime (months)

LTV (Better) = ARPU × Gross Margin % / Monthly Churn Rate

LTV (Advanced) = Account for expansion, cohort-specific retention, discount rate

Example (Simple):

  • ARPU: $500/month
  • Average Lifetime: 36 months
  • LTV = $500 × 36 = $18,000

Example (Better):

  • ARPU: $500/month
  • Gross Margin: 80%
  • Monthly Churn: 2%
  • LTV = ($500 × 80%) / 2% = $400 / 0.02 = $20,000

Quality checks:

  • Is LTV growing over time? (From expansion, improved retention)
  • Does LTV vary by cohort? (Are new customers more/less valuable?)
  • Does LTV vary by segment? (Enterprise vs. SMB)

LTV:CAC Ratio

LTV:CAC Ratio = LTV / CAC

Example:

  • LTV: $20,000
  • CAC: $5,000
  • LTV:CAC = $20,000 / $5,000 = 4:1

Quality checks:

  • Is ratio >3:1? (Minimum for sustainable growth)
  • Is ratio >5:1? (Might be underinvesting in growth)
  • Is ratio improving or degrading over time?

Interpretation:

  • <1:1 = Losing money on every customer (unsustainable)
  • 1-3:1 = Marginal economics (optimize before scaling)
  • 3-5:1 = Healthy (scale confidently)
  • >5:1 = Potentially underinvesting (could grow faster)

Payback Period

Payback Period (months) = CAC / (Monthly ARPU × Gross Margin %)

Example:

  • CAC: $5,000
  • Monthly ARPU: $500
  • Gross Margin: 80%
  • Payback = $5,000 / ($500 × 80%) = $5,000 / $400 = 12.5 months

Quality checks:

  • Is payback <12 months? (Excellent)
  • Is payback <18 months? (Acceptable)
  • Do you have cash runway to sustain payback period?

Critical insight: 4:1 LTV:CAC with 36-month payback is a cash trap. 3:1 LTV:CAC with 8-month payback is better for growth.


Contribution Margin

Contribution Margin = (Revenue - All Variable Costs) / Revenue × 100

Variable Costs include:
- COGS
- Support costs (variable component)
- Payment processing
- Variable customer success costs

Example:

  • Revenue: $1,000,000
  • COGS: $200,000
  • Variable Support: $50,000
  • Payment Processing: $30,000
  • Contribution Margin = ($1M - $280K) / $1M = 72%

Quality checks:

  • Is contribution margin >60%? (Good for SaaS)
  • Are certain products/segments lower margin? (Consider sunsetting)
  • Does margin improve with scale?

Step 2: Calculate Capital Efficiency

Burn Rate

Gross Burn Rate = Total Monthly Cash Spent
Net Burn Rate = Total Monthly Cash Spent - Monthly Revenue

Example:

  • Monthly Expenses: $800,000
  • Monthly Revenue: $400,000
  • Gross Burn: $800,000/month
  • Net Burn: $400,000/month

Quality checks:

  • Is net burn decreasing over time? (Path to profitability)
  • Is burn rate sustainable given runway?
  • What's the burn rate relative to revenue? (Burn multiple)

Runway

Runway (months) = Cash Balance / Monthly Net Burn

Example:

  • Cash Balance: $6,000,000
  • Net Burn: $400,000/month
  • Runway = $6M / $400K = 15 months

Quality checks:

  • Do you have >12 months runway? (Healthy)
  • Do you have <6 months runway? (Crisis—raise now or cut burn)
  • Can you reach next milestone before runway ends?

Rule: Start fundraising at 6-9 months runway, not 3 months.


Operating Expenses (OpEx)

OpEx = Sales & Marketing + R&D + General & Administrative

Track as % of Revenue:
S&M as % of Revenue
R&D as % of Revenue
G&A as % of Revenue

Example:

  • Revenue: $10M/year
  • S&M: $5M (50% of revenue)
  • R&D: $3M (30% of revenue)
  • G&A: $1M (10% of revenue)
  • Total OpEx: $9M (90% of revenue)

Quality checks:

  • Are OpEx categories growing slower than revenue? (Operating leverage)
  • Is S&M spend efficient? (Check magic number)
  • Is G&A <15% of revenue? (Should stay low)

Net Income (Profit Margin)

Net Income = Revenue - COGS - OpEx
Profit Margin % = Net Income / Revenue × 100

Example:

  • Revenue: $10M
  • COGS: $2M
  • OpEx: $9M
  • Net Income = $10M - $2M - $9M = -$1M (loss)
  • Profit Margin = -10%

Quality checks:

  • Is profit margin improving over time? (Path to profitability)
  • At current growth rate, when will you break even?
  • Are you investing losses in growth? (Acceptable if LTV:CAC is healthy)

Step 3: Calculate Efficiency Ratios

Rule of 40

Rule of 40 = Revenue Growth Rate % + Profit Margin %

Example 1 (Growth Mode):

  • Revenue Growth: 80% YoY
  • Profit Margin: -30%
  • Rule of 40 = 80% + (-30%) = 50 ✅ Healthy

Example 2 (Mature):

  • Revenue Growth: 25% YoY
  • Profit Margin: 20%
  • Rule of 40 = 25% + 20% = 45 ✅ Healthy

Example 3 (Problem):

  • Revenue Growth: 30% YoY
  • Profit Margin: -35%
  • Rule of 40 = 30% + (-35%) = -5 🚨 Unhealthy

Quality checks:

  • Is Rule of 40 >40? (Healthy balance)
  • Is Rule of 40 >25? (Acceptable)
  • Is Rule of 40 <25? (Burning cash without sufficient growth)

Trade-offs:

  • Early stage: Maximize growth, accept losses (60% growth, -20% margin = 40)
  • Growth stage: Balance (40% growth, 5% margin = 45)
  • Mature: Prioritize profitability (20% growth, 25% margin = 45)

Magic Number

Magic Number = (Current Quarter Revenue - Previous Quarter Revenue) × 4 / Previous Quarter S&M Spend

Example:

  • Q2 Revenue: $2.5M
  • Q1 Revenue: $2.0M
  • Q1 S&M Spend: $800K
  • Magic Number = ($2.5M - $2.0M) × 4 / $800K = $2M / $800K = 2.5

Quality checks:

  • Is magic number >0.75? (Efficient—scale S&M spend)
  • Is magic number 0.5-0.75? (Acceptable—optimize before scaling)
  • Is magic number <0.5? (Inefficient—fix GTM before spending more)

Interpretation:

  • >1.0 = For every $1 in S&M, you get $1+ in new ARR (excellent)
  • 0.75-1.0 = Efficient, scale confidently
  • 0.5-0.75 = Marginal, optimize before scaling
  • <0.5 = Inefficient, fix before investing more

Operating Leverage

Track over time to see if you're scaling efficiently.

Example:

Quarter Revenue YoY Growth OpEx YoY Growth Leverage
Q1 2024 $8M - $6M - -
Q2 2024 $10M 25% $7M 17% Positive ✅
Q3 2024 $12M 20% $9M 29% Negative ⚠️

Quality checks:

  • Is revenue growing faster than OpEx? (Positive leverage)
  • Are you scaling OpEx too fast relative to revenue?
  • Which OpEx category is growing fastest? (R&D, S&M, G&A)

Step 4: Analyze by Segment and Channel

Unit economics vary dramatically by segment:

Segment CAC LTV LTV:CAC Payback Gross Margin
SMB $500 $2,000 4:1 8 months 75%
Mid-Market $5,000 $25,000 5:1 12 months 80%
Enterprise $50,000 $300,000 6:1 24 months 85%

Quality checks:

  • Which segment has best unit economics?
  • Which segment has fastest payback? (Prioritize when cash-constrained)
  • Which segment has highest LTV? (Invest in retention/expansion)

Examples

See examples/ folder for detailed scenarios. Mini examples below:

Example 1: Healthy Unit Economics

Company: CloudAnalytics (mid-market analytics SaaS)

Unit Economics:

  • CAC: $8,000
  • LTV: $40,000
  • LTV:CAC: 5:1 ✅
  • Payback Period: 10 months ✅
  • Gross Margin: 82% ✅

Capital Efficiency:

  • Monthly Net Burn: $300K
  • Runway: 18 months ✅
  • Rule of 40: 55 (40% growth + 15% margin) ✅
  • Magic Number: 0.9 ✅

Analysis:

  • Strong unit economics (5:1 LTV:CAC, 10-month payback)
  • Efficient GTM (0.9 magic number)
  • Healthy balance (Rule of 40 = 55)
  • Sufficient runway (18 months)

Action: Scale acquisition aggressively. Economics support growth.


Example 2: Good LTV:CAC, Bad Payback (Cash Trap)

Company: EnterpriseCRM (enterprise sales motion)

Unit Economics:

  • CAC: $80,000
  • LTV: $400,000
  • LTV:CAC: 5:1 ✅ (looks great!)
  • Payback Period: 36 months 🚨 (terrible!)
  • Gross Margin: 85%

Capital Efficiency:

  • Monthly Net Burn: $2M
  • Runway: 9 months 🚨
  • Average Customer Lifetime: 48 months
  • Average Contract: $100K/year

Analysis:

  • ⚠️ Great LTV:CAC ratio (5:1) masks cash problem
  • 🚨 36-month payback with 9-month runway = cash trap
  • 🚨 Takes 3 years to recover CAC, but only 9 months of cash
  • ⚠️ Customers stay 4 years, so economics work IF you have cash

Problem: You'll run out of cash before recovering acquisition costs.

Actions:

  1. Negotiate upfront annual payments (reduce payback to 12 months)
  2. Raise capital to extend runway (need 36+ months to sustain growth)
  3. Reduce CAC (shorten sales cycle, improve conversion)
  4. Target smaller deals with faster payback (mid-market vs. enterprise)

Example 3: Scaling Too Fast (Negative Operating Leverage)

Company: SocialScheduler (SMB social media tool)

Quarter-over-Quarter Trend:

Quarter Revenue OpEx Net Income Revenue Growth OpEx Growth
Q1 $1.0M $800K -$800K - -
Q2 $1.3M $1.2M -$1.2M 30% 50% 🚨
Q3 $1.6M $1.8M -$1.8M 23% 50% 🚨

Analysis:

  • 🚨 OpEx growing FASTER than revenue (50% vs. 23-30%)
  • 🚨 Losses accelerating ($800K → $1.8M in 2 quarters)
  • 🚨 Negative operating leverage (should be positive)
  • ⚠️ Scaling S&M and R&D without corresponding revenue growth

Problem: Burning cash faster while revenue growth is slowing.

Actions:

  1. Freeze headcount until revenue catches up
  2. Cut inefficient S&M spend (magic number likely <0.5)
  3. Focus on improving unit economics before scaling
  4. Aim for OpEx growth <revenue growth

Common Pitfalls

Pitfall 1: Celebrating High LTV Without Checking Payback

Symptom: "Our LTV:CAC is 6:1, amazing!"

Consequence: 6:1 ratio with 48-month payback is a cash trap. You'll run out of money before recovering CAC.

Fix: Always pair LTV:CAC with payback period. 3:1 with 10-month payback beats 6:1 with 36-month payback.


Pitfall 2: Ignoring Gross Margin When Calculating LTV

Symptom: "LTV = $100/month × 36 months = $3,600"

Consequence: You're using revenue, not profit. Actual LTV after 30% COGS = $2,520, not $3,600.

Fix: Always include gross margin in LTV calculations. LTV = ARPU × Margin % / Churn Rate.


Pitfall 3: Scaling S&M with Low Magic Number

Symptom: "We need to grow faster—let's double S&M spend!" (Magic Number = 0.3)

Consequence: You're pouring gas on a broken engine. Doubling spend will just accelerate cash burn without proportional revenue growth.

Fix: Only scale S&M when magic number >0.75. If <0.5, fix GTM efficiency first.


Pitfall 4: Using Simplistic LTV Formulas

Symptom: "LTV = ARPU × Lifetime" (ignoring expansion, discount rates, cohort variance)

Consequence: Overstating LTV for decision-making. Reality: expansion boosts LTV; discounting reduces it; cohorts vary.

Fix: Use sophisticated LTV models for big decisions. Simple LTV ok for directional guidance only.


Pitfall 5: Forgetting Time Value of Money

Symptom: "$10K revenue today = $10K revenue in 5 years"

Consequence: Overstating LTV for long-payback businesses. $10K in 5 years is worth ~$7.8K today (at 5% discount rate).

Fix: Discount future cash flows for LTV periods >24 months. Use NPV (net present value).


Pitfall 6: Comparing CAC Across Different Payback Periods

Symptom: "Channel A has $5K CAC, Channel B has $8K CAC—Channel A is better!"

Consequence: If Channel A has 24-month payback and Channel B has 8-month payback, Channel B is actually better (faster cash recovery).

Fix: Compare CAC + payback together, not CAC in isolation.


Pitfall 7: Celebrating Rule of 40 >40 with Negative Cash Flow

Symptom: "Rule of 40 = 50, we're crushing it!" (60% growth, -10% margin, burning $5M/month)

Consequence: Rule of 40 doesn't account for absolute burn. You might have great balance but only 3 months runway.

Fix: Pair Rule of 40 with burn rate and runway. Balance matters, but survival matters more.


Pitfall 8: Ignoring Segment-Specific Unit Economics

Symptom: "Blended CAC is $2K, blended LTV is $10K, we're good!"

Consequence: SMB segment might have $500 CAC / $2K LTV (great), while Enterprise has $20K CAC / $15K LTV (terrible). Blended metrics hide the problem.

Fix: Calculate unit economics by segment. Optimize each independently.


Pitfall 9: Confusing Gross Margin with Contribution Margin

Symptom: "Gross margin is 80%, our margins are great!"

Consequence: After variable support costs (10%) and payment processing (3%), contribution margin might be 67%—not 80%.

Fix: Track both gross margin (COGS only) AND contribution margin (all variable costs). Use contribution margin for unit economics.


Pitfall 10: Forgetting Working Capital Timing

Symptom: "We have 12 months runway based on burn rate" (but all contracts are paid monthly)

Consequence: Annual contracts paid upfront boost cash temporarily. Monthly contracts delay cash collection. Runway is longer/shorter than burn rate suggests.

Fix: Account for working capital when calculating runway. Cash-based runway ≠ revenue-based runway.


References

Related Skills

  • saas-revenue-growth-metrics — Revenue, retention, and growth metrics that feed into LTV
  • finance-metrics-quickref — Fast lookup for all metrics
  • feature-investment-advisor — Uses margin and contribution calculations for feature ROI
  • acquisition-channel-advisor — Uses CAC, LTV, payback for channel evaluation
  • business-health-diagnostic — Uses efficiency metrics for health checks

External Frameworks

  • David Skok (Matrix Partners): "SaaS Metrics" blog — Definitive guide to CAC, LTV, payback
  • Bessemer Venture Partners: "SaaS Metrics 2.0" — Rule of 40, magic number benchmarks
  • Ben Murray: The SaaS CFO — Advanced unit economics modeling
  • Jason Lemkin (SaaStr): SaaS benchmarking research
  • Brad Feld: Venture Deals — Understanding investor perspective on unit economics

Provenance

  • Adapted from research/finance/Finance for Product Managers.md
  • Consolidated from research/finance/Finance_QuickRef.md
  • Common mistakes from research/finance/Finance_Metrics_Additions_Reference.md
用于计算和解读SaaS收入、留存及增长指标,帮助产品经理诊断业务势头、流失风险及产品市场契合度。提供关键指标定义、公式及基准,辅助识别早期问题并指导增长投资决策。
诊断SaaS业务增长健康状况 分析客户流失或扩张信号 评估产品市场契合度 解读MRR/ARR等核心财务数据
skills/saas-revenue-growth-metrics/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill saas-revenue-growth-metrics -g -y
SKILL.md
Frontmatter
{
    "name": "saas-revenue-growth-metrics",
    "type": "component",
    "theme": "finance-metrics",
    "intent": "Master revenue and retention metrics to understand SaaS business momentum, evaluate product-market fit, and make data-driven decisions about growth investments. Use this to calculate key metrics, interpret trends, identify problems early, and communicate business health to stakeholders.",
    "best_for": [
        "Understanding your key revenue and retention metrics",
        "Calculating MRR, ARR, churn, and NRR correctly",
        "Building a metrics dashboard for your SaaS product"
    ],
    "scenarios": [
        "I need to calculate and interpret our MRR, churn rate, and NRR for a board deck",
        "Help me understand the difference between gross and net revenue retention and how to improve it"
    ],
    "description": "Calculate SaaS revenue, retention, and growth metrics. Use when diagnosing momentum, churn, expansion, or product-market-fit signals.",
    "argument-hint": "[metrics or question]",
    "estimated_time": "10-15 min"
}

Purpose

Master revenue and retention metrics to understand SaaS business momentum, evaluate product-market fit, and make data-driven decisions about growth investments. Use this to calculate key metrics, interpret trends, identify problems early, and communicate business health to stakeholders.

This is not a business intelligence tool—it's a framework for PMs to understand which metrics matter, how to calculate them correctly, and what actions to take based on the numbers.

Input

Works best with: The question you're answering (is growth healthy? is churn a fire?) or the metrics you want interpreted. Also useful: Your numbers — MRR/ARR, growth rate, GRR/NRR, expansion, cohort data — partial data is workable.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. Use it as a reference: read the metric sections relevant to your diagnosis.

Example invocation: Interpret these: $4M ARR, 8% MoM growth, GRR 88%, NRR 103% — is the growth masking a churn problem?

Key Concepts

Revenue Metrics Family

The "top-line" metrics that measure how much money the business generates.

Revenue — Total money earned from selling products/services before expenses. The "top line" of the income statement.

  • Why PMs care: Every feature should connect to revenue (direct or indirect). If you can't articulate revenue impact, prioritization becomes impossible.
  • Formula: Sum of all customer payments in a period
  • Benchmark: Growth rate matters more than absolute number (context-dependent by stage)

ARPU (Average Revenue Per User) — Average revenue generated per individual user.

  • Why PMs care: Measures per-seat monetization effectiveness. Critical for seat-based pricing models.
  • Formula: Total Revenue / Total Users
  • Benchmark: Varies by model; track trend more than absolute value
  • B2C SaaS: $5-50/month typical; B2B: $50-500+/month

ARPA (Average Revenue Per Account) — Average revenue generated per customer account.

  • Why PMs care: Measures account-level deal size. Critical for account-based pricing models.
  • Formula: MRR / Active Accounts
  • Benchmark: SMB SaaS: $100-$1K/month; Mid-market: $1K-$10K; Enterprise: $10K+

ARPA/ARPU Analysis — Using both metrics together to understand monetization.

  • Why PMs care: Prevents packaging mistakes. High ARPA + low ARPU = undermonetized per seat. Low ARPA + high ARPU = small deal sizes.
  • Example: $10K ARPA with 100 seats = $100 ARPU (reasonable). $10K ARPA with 1,000 seats = $10 ARPU (leaving money on table).

ACV (Annual Contract Value) — Annualized recurring revenue per contract (excludes one-time fees).

  • Why PMs care: Compares economics across different contract structures. Enables sales compensation design and segment analysis.
  • Formula: Annual Recurring Revenue per Contract (don't include setup fees, professional services)
  • Benchmark: SMB: $5K-$25K; Mid-market: $25K-$100K; Enterprise: $100K+

MRR/ARR (Monthly/Annual Recurring Revenue) — Predictable recurring revenue normalized to monthly or annual.

  • Why PMs care: The heartbeat of subscription businesses. Valued at 5-10x+ multiples. Track components (new, expansion, churn).
  • Formula: MRR = Sum of all recurring subscription revenue per month; ARR = MRR × 12
  • Benchmark: Growth rate and quality matter; track new MRR, expansion MRR, churned MRR, contracted MRR

Gross vs. Net Revenue — Gross revenue before vs. net revenue after discounts, refunds, credits.

  • Why PMs care: Discounts and refunds can hide bad acquisition quality or product problems.
  • Formula: Net Revenue = Gross Revenue - Discounts - Refunds - Credits
  • Benchmark: Refunds >10% is a red flag; track by acquisition channel

Retention & Expansion Metrics Family

Metrics that measure how well you keep and grow existing customers.

Churn Rate — Percentage of customers who cancel in a period.

  • Why PMs care: Silent killer of SaaS. Undermines all acquisition efforts. 5% monthly churn = 46% annual churn (compounding).
  • Formula: Customers Lost in Period / Starting Customers
  • Benchmark (Monthly): <2% great, 2-5% acceptable, >5% crisis
  • Benchmark (Annual): <10% great, 10-30% acceptable, >30% crisis
  • Note: Logo churn (customer count) differs from revenue churn (dollar amount)

NRR (Net Revenue Retention) — Revenue retention from existing customers including expansion and contraction.

  • Why PMs care: The holy grail metric. NRR >100% means you grow without new logos. Highly valued by investors.
  • Formula: (Starting ARR + Expansion - Churn - Contraction) / Starting ARR × 100
  • Benchmark: >120% excellent, 100-120% good, 90-100% acceptable, <90% problem
  • Example: Start with $1M ARR, add $300K expansion, lose $100K to churn = $1.2M / $1M = 120% NRR

Expansion Revenue — Additional revenue from existing customers (upsells, cross-sells, usage growth).

  • Why PMs care: Most capital-efficient revenue (no CAC). Should drive NRR >100%.
  • Formula: Sum of upsells + cross-sells + usage increases from existing customers
  • Benchmark: Should represent 20-30% of total revenue; drives NRR >100%

Quick Ratio (SaaS) — Revenue gains vs. revenue losses.

  • Why PMs care: Shows if you're building on solid ground or running on a treadmill.
  • Formula: (New MRR + Expansion MRR) / (Churned MRR + Contraction MRR)
  • Benchmark: >4 excellent, 2-4 healthy, <2 leaky bucket

Analysis Frameworks

Revenue Mix Analysis — Breakdown of revenue by product, segment, or channel.

  • Why PMs care: Identifies which products fund the business and where to invest. Reveals concentration risk.
  • Formula: Product/Segment Revenue / Total Revenue × 100
  • Benchmark: No single product >60% ideal; diversification reduces risk

Cohort Analysis — Group customers by join date and track behavior over time.

  • Why PMs care: Blended metrics hide critical trends. Shows whether business is improving or degrading.
  • Method: Track retention, expansion, and LTV by cohort (e.g., "Jan 2024 cohort")
  • Benchmark: Recent cohorts should perform same or better than old cohorts

Anti-Patterns (What This Is NOT)

  • Not profit metrics: Revenue is top-line, not bottom-line. High revenue with negative margins is a disaster.
  • Not vanity metrics: Total revenue growth means nothing if driven by unsustainable discounting or margin-destroying deals.
  • Not blended averages: ARPU that averages $10 SMB and $1,000 enterprise customers hides segment economics.
  • Not isolated numbers: Churn rate alone doesn't tell the story—need to see cohort trends and NRR.

When to Use These Metrics

Use these when:

  • Evaluating overall business health and product-market fit
  • Comparing performance across time periods or cohorts
  • Prioritizing features with direct monetization paths (ARPU impact, expansion enablers)
  • Communicating with leadership, board, or investors
  • Assessing retention problems (churn analysis, cohort degradation)
  • Measuring pricing or packaging changes (ARPU/ARPA shifts)

Don't use these when:

  • Evaluating profitability (use margin metrics instead)
  • Assessing capital efficiency (use LTV:CAC, payback period)
  • Making product investment decisions without cost context (revenue alone isn't ROI)
  • Comparing across wildly different business models without normalization

Application

Step 1: Calculate Revenue Metrics

Use the templates in template.md to calculate your core revenue metrics.

Revenue

Revenue = Sum of all customer payments in period

Example:

  • Month 1 payments: $100,000
  • Revenue = $100,000

Quality checks:

  • Is this gross or net revenue? (Clarify if discounts/refunds are included)
  • Is revenue growing cohort-over-cohort, or just from new customer adds?
  • What's the revenue growth rate vs. headcount/cost growth rate?

ARPU (Average Revenue Per User)

ARPU = Total Revenue / Total Users

Example:

  • Total Revenue: $100,000/month
  • Total Users: 2,000
  • ARPU = $100,000 / 2,000 = $50/user/month

Quality checks:

  • Is ARPU growing or shrinking over time?
  • Is ARPU growth from price increases or mix shift (losing small customers)?
  • How does ARPU vary by cohort? (Are new customers less valuable?)

ARPA (Average Revenue Per Account)

ARPA = MRR / Active Accounts

Example:

  • MRR: $100,000
  • Active Accounts: 200
  • ARPA = $100,000 / 200 = $500/account/month

Quality checks:

  • Is ARPA growing from expansion or just larger new deals?
  • How does ARPA compare across customer segments?
  • Is ARPA high but ARPU low? (Undermonetized per seat)

ARPA/ARPU Combined Analysis

ARPA = MRR / Active Accounts
ARPU = MRR / Total Users
Average Seats per Account = ARPA / ARPU

Example:

  • ARPA: $500/month
  • ARPU: $50/month
  • Average Seats: $500 / $50 = 10 seats/account

Quality checks:

  • Are you monetizing per seat effectively?
  • Could you charge more per seat (raise ARPU)?
  • Could you expand seat count per account (raise ARPA)?

ACV (Annual Contract Value)

ACV = Annual Recurring Revenue per Contract
(Exclude one-time fees like setup, professional services)

Example:

  • Customer signs 3-year contract for $300K total
  • ACV = $300K / 3 years = $100K/year

Quality checks:

  • How does ACV vary by segment (SMB vs. Enterprise)?
  • Is ACV growing over time (moving upmarket)?
  • Does ACV justify sales team cost structure?

MRR/ARR (Monthly/Annual Recurring Revenue)

MRR = Sum of all recurring monthly subscriptions
ARR = MRR × 12

Track components:
- New MRR (from new customers)
- Expansion MRR (from upsells/cross-sells)
- Churned MRR (from lost customers)
- Contraction MRR (from downgrades)

Example:

  • Starting MRR: $500K
  • New MRR: +$50K
  • Expansion MRR: +$20K
  • Churned MRR: -$15K
  • Contraction MRR: -$5K
  • Ending MRR: $550K
  • ARR = $550K × 12 = $6.6M

Quality checks:

  • Is MRR growth from new customers or expansion?
  • Is churn/contraction increasing as you grow?
  • What's the ratio of new:expansion:churn MRR? (Best: expansion > new)

Gross vs. Net Revenue

Net Revenue = Gross Revenue - Discounts - Refunds - Credits

Example:

  • Gross Revenue: $100K
  • Discounts: -$10K
  • Refunds: -$2K
  • Net Revenue: $88K

Quality checks:

  • Are discounts >20%? (Pricing power problem)
  • Are refunds >10%? (Product quality problem)
  • Do certain channels have higher discount/refund rates?

Step 2: Calculate Retention & Expansion Metrics

Churn Rate

Logo Churn Rate = Customers Lost / Starting Customers × 100
Revenue Churn Rate = MRR Lost / Starting MRR × 100

Example (Logo Churn):

  • Starting Customers: 1,000
  • Customers Lost: 30
  • Logo Churn = 30 / 1,000 = 3% monthly

Example (Revenue Churn):

  • Starting MRR: $500K
  • MRR Lost: $15K
  • Revenue Churn = $15K / $500K = 3% monthly

Quality checks:

  • Is churn rate accelerating or decelerating over time?
  • Are newer cohorts churning faster than older ones? (PMF degradation)
  • Is revenue churn higher than logo churn? (Losing big customers)

Convert monthly to annual:

  • Monthly churn compounds: 3% monthly ≠ 36% annual
  • Formula: Annual Churn = 1 - (1 - Monthly Churn)^12
  • 3% monthly = ~31% annual churn

NRR (Net Revenue Retention)

NRR = (Starting ARR + Expansion - Churn - Contraction) / Starting ARR × 100

Example:

  • Starting ARR: $5M
  • Expansion: +$800K
  • Churn: -$300K
  • Contraction: -$100K
  • Ending ARR from cohort: $5.4M
  • NRR = $5.4M / $5M = 108%

Quality checks:

  • Is NRR >100%? (You grow without new logos)
  • Is NRR improving or degrading cohort-over-cohort?
  • What's driving NRR? (Expansion or low churn?)

Expansion Revenue

Expansion Revenue = Upsells + Cross-sells + Usage Growth (from existing customers)

Example:

  • Upsells to higher tier: $50K/month
  • Cross-sells of add-ons: $20K/month
  • Usage growth: $10K/month
  • Total Expansion Revenue: $80K/month

Quality checks:

  • Is expansion revenue growing as % of total revenue?
  • What % of customers expand each year? (Expansion rate)
  • Are certain cohorts/segments more likely to expand?

Quick Ratio (SaaS)

Quick Ratio = (New MRR + Expansion MRR) / (Churned MRR + Contraction MRR)

Example:

  • New MRR: $50K
  • Expansion MRR: $20K
  • Churned MRR: $15K
  • Contraction MRR: $5K
  • Quick Ratio = ($50K + $20K) / ($15K + $5K) = $70K / $20K = 3.5

Quality checks:

  • Quick Ratio >4 = excellent (gains far exceed losses)
  • Quick Ratio 2-4 = healthy (sustainable growth)
  • Quick Ratio <2 = leaky bucket (fix retention before scaling)

Step 3: Analyze Trends with Frameworks

Revenue Mix Analysis

Product/Segment % = Product/Segment Revenue / Total Revenue × 100

Example:

  • Product A Revenue: $300K
  • Product B Revenue: $500K
  • Product C Revenue: $200K
  • Total Revenue: $1M
  • Product A: 30%, Product B: 50%, Product C: 20%

Quality checks:

  • Is revenue concentration increasing? (Risk: over-reliance on one product)
  • Which products are growing/shrinking?
  • Does revenue mix match your strategic priorities?

Cohort Analysis

Group customers by when they joined and track metrics over time.

Example:

Cohort Month 0 Month 1 Month 2 Month 3 Month 6
Jan 2024 100% 95% 92% 90% 85%
Feb 2024 100% 94% 90% 87% 80%
Mar 2024 100% 92% 86% 82% -

Quality checks:

  • Are recent cohorts retaining better or worse than older cohorts?
  • If worse: Product-market fit is degrading (fix before scaling)
  • If better: Improvements are working (safe to scale)
  • Track revenue retention by cohort, not just logo retention

Step 4: Quality Checks & Benchmarks

Before reporting metrics, validate:

Revenue metrics:

  • ✅ Gross vs. net revenue clearly labeled
  • ✅ Revenue growth rate > cost growth rate
  • ✅ ARPU/ARPA trends analyzed by cohort (not just blended)

Retention metrics:

  • ✅ Logo churn and revenue churn both tracked
  • ✅ Cohort-over-cohort trends analyzed (not just blended churn)
  • ✅ NRR tracked with components (expansion, churn, contraction)

Analysis:

  • ✅ Cohort analysis shows retention trends
  • ✅ Revenue mix shows concentration risk
  • ✅ Quick ratio shows growth sustainability

Examples

See examples/ folder for detailed scenarios. Mini examples below:

Example 1: Healthy SaaS Metrics

Company: Mid-market project management SaaS

Revenue Metrics:

  • MRR: $2M (growing 10% month-over-month)
  • ARR: $24M
  • ARPA: $1,200/month (200 accounts)
  • ARPU: $120/month (20,000 users)
  • Average seats: 100 per account

Retention Metrics:

  • Monthly logo churn: 2%
  • Revenue churn: 1.5% (losing smaller customers)
  • NRR: 115% (strong expansion)
  • Expansion revenue: $200K/month (10% of MRR)
  • Quick Ratio: 5.0

Analysis:

  • ✅ Strong growth (10% MoM MRR)
  • ✅ Excellent retention (2% logo churn, 115% NRR)
  • ✅ Healthy expansion (NRR >100%)
  • ✅ Sustainable (Quick Ratio 5.0)
  • ✅ Revenue churn < logo churn (losing smaller customers, good signal)

Action: Scale acquisition. Unit economics are strong.


Example 2: Warning Signs

Company: SMB marketing automation SaaS

Revenue Metrics:

  • MRR: $500K (growing 15% month-over-month)
  • ARR: $6M
  • ARPA: $250/month (2,000 accounts)
  • ARPU: $50/month (10,000 users)

Retention Metrics:

  • Monthly logo churn: 6% (increasing from 4% six months ago)
  • Revenue churn: 7% (losing larger customers)
  • NRR: 85% (contracting)
  • Expansion revenue: $5K/month (1% of MRR)
  • Quick Ratio: 1.2

Cohort Analysis:

Cohort Month 6 Retention
6 months ago 75%
3 months ago 65%
Current 58%

Analysis:

  • ⚠️ High churn (6% monthly = ~50% annual)
  • 🚨 Revenue churn > logo churn (losing bigger customers)
  • 🚨 NRR <100% (contracting, not expanding)
  • 🚨 Cohort degradation (newer customers churn faster)
  • 🚨 Quick Ratio 1.2 (leaky bucket)

Action: STOP scaling acquisition. Fix retention first. Investigate:

  • Why are newer cohorts churning faster?
  • Why is expansion revenue only 1% of MRR?
  • What's causing customer contraction?

Example 3: Blended Metrics Hiding Problems

Company: Multi-product SaaS platform

Blended Metrics Look Great:

  • MRR: $3M (growing 20% MoM)
  • Blended churn: 3%
  • Blended NRR: 110%

But Revenue Mix Analysis Shows:

Product Revenue % of Total Growth Churn NRR
Legacy Product $2M 67% -5% MoM 8% 75%
New Product $1M 33% +80% MoM 1% 150%

Analysis:

  • 🚨 Legacy product (67% of revenue) is dying: -5% growth, 8% churn, 75% NRR
  • ✅ New product is stellar: +80% growth, 1% churn, 150% NRR
  • ⚠️ Blended metrics hide the fact that 2/3 of revenue is contracting
  • ⚠️ High dependency on one product (67% concentration risk)

Action: Accelerate migration from legacy to new product. Plan for legacy product sunset.


Common Pitfalls

Pitfall 1: Confusing Revenue with Profit

Symptom: "We grew revenue 50% this year, we're crushing it!"

Consequence: Revenue is the top line, not bottom line. You might be growing at a loss, destroying margins, or scaling unprofitable products.

Fix: Always pair revenue metrics with margin metrics (see saas-economics-efficiency-metrics). $1M revenue at 80% margin >> $2M revenue at 20% margin.


Pitfall 2: Celebrating ARPU Growth from Mix Shift

Symptom: "ARPU increased 30%!" (but customer count dropped 40%)

Consequence: ARPU rose because you lost all your small customers, not because you improved monetization.

Fix: Analyze ARPU by cohort and segment. True ARPU improvement = same customers paying more, not losing cheap customers.


Pitfall 3: Ignoring Cohort Degradation

Symptom: "Blended churn is stable at 3%"

Consequence: Blended metrics can hide that new cohorts churn at 6% while old cohorts churn at 1%. Product-market fit is degrading.

Fix: Always analyze retention by cohort. If newer cohorts perform worse, stop scaling and fix the product.


Pitfall 4: Logo Churn vs. Revenue Churn Confusion

Symptom: "Logo churn is only 2%, we're great!"

Consequence: You might be losing 2% of customers but 10% of revenue if you're churning large customers.

Fix: Track both logo churn AND revenue churn. If revenue churn > logo churn, you're losing high-value customers.


Pitfall 5: Treating All Churn Equally

Symptom: "We lost 50 customers this month" (no context on who)

Consequence: Losing 50 small customers ($10/month) is different from losing 50 enterprise customers ($10K/month).

Fix: Segment churn analysis by customer size, cohort, and reason. Weight by revenue impact, not just logo count.


Pitfall 6: Forgetting Compounding Churn

Symptom: "3% monthly churn is fine, that's only 36% annually"

Consequence: Churn compounds. 3% monthly = 31% annual churn, not 36%. Math: 1 - (1 - 0.03)^12 = 31%.

Fix: Use the correct formula when converting monthly to annual churn. Don't just multiply by 12.


Pitfall 7: Celebrating Gross Revenue While Net Contracts

Symptom: "Gross revenue is up 20%!" (but discounts/refunds doubled)

Consequence: Net revenue might be flat or shrinking. Discounts hide pricing power problems; refunds hide product quality issues.

Fix: Always track gross AND net revenue. If discounts >20% or refunds >10%, investigate why.


Pitfall 8: NRR >100% from Low Churn, Not Expansion

Symptom: "NRR is 105%, we're expanding!"

Consequence: NRR can be >100% just from very low churn, without meaningful expansion. True expansion-driven NRR is >120%.

Fix: Break down NRR into components: expansion MRR vs. churned/contracted MRR. Aim for expansion-driven NRR, not just low churn.


Pitfall 9: Revenue Concentration Risk

Symptom: "We're at $10M ARR!" (but $5M is from one customer)

Consequence: Losing that one customer cuts revenue in half. Roadmap becomes hostage to one customer's requests.

Fix: Track revenue concentration. Ideal: Top customer <10% of revenue, Top 10 customers <40%. Diversify early.


Pitfall 10: Averaging ARPU/ARPA Across Segments

Symptom: "Our ARPU is $100" (average of $10 SMB and $1,000 enterprise)

Consequence: Blended ARPU hides segment economics. Can't make smart acquisition or product decisions.

Fix: Calculate ARPU/ARPA by segment (SMB, mid-market, enterprise). Optimize each segment independently.


References

Related Skills

  • saas-economics-efficiency-metrics — Unit economics (CAC, LTV, margins, burn rate)
  • finance-metrics-quickref — Fast lookup for all metrics
  • feature-investment-advisor — Uses revenue metrics to evaluate feature ROI
  • finance-based-pricing-advisor — Uses ARPU/ARPA to evaluate pricing changes
  • business-health-diagnostic — Uses revenue/retention metrics to diagnose business health

External Frameworks

  • Bessemer Venture Partners: "SaaS Metrics 2.0" — Definitive guide to SaaS metrics
  • David Skok (Matrix Partners): "SaaS Metrics" blog series — Deep dive on unit economics
  • Tomasz Tunguz (Redpoint): SaaS benchmarking research
  • Tien Tzuo: Subscribed — Subscription business model fundamentals
  • ChartMogul, Baremetrics, ProfitWell: SaaS analytics platforms with metric definitions

Provenance

  • Adapted from research/finance/Finance for Product Managers.md
  • Consolidated from research/finance/Finance_QuickRef.md
  • Common mistakes from research/finance/Finance_Metrics_Additions_Reference.md
将原始PM内容转化为符合标准的SKILL.md文件,确保通过验证并融入仓库。适用于创建或更新技能资产,利用脚本工具规范流程,严格检查元数据、章节顺序及引用完整性,实现从草稿到发布就绪的标准化转换。
需要创建新的技能资产 需要更新现有技能以符合标准 将会议记录或提示词转换为合规的SKILL.md
skills/skill-authoring-workflow/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill skill-authoring-workflow -g -y
SKILL.md
Frontmatter
{
    "name": "skill-authoring-workflow",
    "type": "workflow",
    "intent": "Create or update PM skills without chaos. This workflow turns rough notes, workshop content, or half-baked prompt dumps into compliant `skills\/<skill-name>\/SKILL.md` assets that actually pass validation and belong in this repo.",
    "best_for": [
        "Creating a new repo skill from notes or source material",
        "Updating an existing skill while keeping standards intact",
        "Running the full authoring and validation workflow before commit"
    ],
    "scenarios": [
        "Help me turn these workshop notes into a new PM skill",
        "I need to update an existing skill without breaking the repo standards",
        "What workflow should I use to author a new skill in this repo?"
    ],
    "description": "Turn raw PM content into a compliant, publish-ready skill. Use when creating or updating a repo skill without breaking standards.",
    "argument-hint": "[source content or skill to update]"
}

Purpose

Create or update PM skills without chaos. This workflow turns rough notes, workshop content, or half-baked prompt dumps into compliant skills/<skill-name>/SKILL.md assets that actually pass validation and belong in this repo.

Use it when you want to ship a new skill without "looks good to me" roulette.

Input

Bring the raw material and the intent — rough is fine; the workflow exists to get it the rest of the way:

  • Works best with: the source content (notes, transcript, framework, prompt sequence) or the existing skill you want to update
  • Also useful: the intended skill type (component/interactive/workflow), target audience, and any naming preference

If you supply this inline with your request (e.g., "turn research/pricing-workshop-notes.md into an interactive advisor"), the workflow starts at Phase 1 with that context — it won't re-ask for what you already gave. If you provide nothing, it opens by asking what content you want to turn into a skill and offers the entry modes from the facilitation protocol.

Example: Use skill-authoring-workflow: convert research/pricing-workshop-notes.md into an interactive pricing advisor.

Key Concepts

Dogfood First

Use repo-native tools and standards before inventing a custom process:

  • scripts/find-a-skill.sh
  • scripts/add-a-skill.sh
  • scripts/build-a-skill.sh
  • scripts/test-a-skill.sh
  • scripts/check-skill-metadata.py

Pick the Right Creation Path

  • Guided wizard (build-a-skill.sh): Best when you have an idea but not final prose.
  • Content-first generator (add-a-skill.sh): Best when you already have source content.
  • Manual edit + validate: Best for tightening an existing skill.

Definition of Done (No Exceptions)

A skill is done only when:

  1. Frontmatter is valid (name, description, intent, type)
  2. Section order is compliant (Purpose, Input, Key Concepts, Application, Examples, Common Pitfalls, References)
  3. Metadata limits are respected (name <= 64 chars, description <= 200 chars)
  4. Description says both what the skill does and when to use it
  5. The Input section says what the user can bring, shows an example invocation, tells the agent to use inline input instead of re-asking, and makes clear that arriving with partial or zero input is fine — in plain language, never runtime template syntax like $ARGUMENTS (rationale: CONTRIBUTING.md, "Why We Don't Use $ARGUMENTS")
  6. Intent carries the fuller repo-facing summary without replacing the trigger-oriented description
  7. Cross-references resolve
  8. README catalog counts and tables are updated (if adding/removing skills)

Facilitation Source of Truth

When running this workflow as a guided conversation, use workshop-facilitation as the interaction protocol.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.

Application

Phase 1: Preflight (Avoid Duplicate Work)

  1. Search for overlapping skills:
./scripts/find-a-skill.sh --keyword "<topic>"
  1. Decide type:
  • Component: one artifact/template
  • Interactive: 3-5 adaptive questions + numbered options
  • Workflow: multi-phase orchestration

Phase 2: Generate Draft

If you have source material:

./scripts/add-a-skill.sh research/your-framework.md

If you want guided prompts:

./scripts/build-a-skill.sh

Phase 3: Tighten the Skill

Manually review for:

  • Clear "when to use" guidance
  • One concrete example
  • One explicit anti-pattern
  • No filler or vague consultant-speak

Phase 4: Validate Hard

Run strict checks before thinking about commit:

./scripts/test-a-skill.sh --skill <skill-name> --smoke
python3 scripts/check-skill-metadata.py skills/<skill-name>/SKILL.md
python3 scripts/check-skill-triggers.py skills/<skill-name>/SKILL.md --show-cases

Phase 5: Integrate with Repo Docs

If this is a new skill:

  1. Add it to the correct README category table
  2. Update skill totals and category counts
  3. Verify link paths resolve

Phase 6: Optional Packaging

If targeting Claude custom skill upload:

./scripts/zip-a-skill.sh --skill <skill-name>
# or zip one category:
./scripts/zip-a-skill.sh --type component --output dist/skill-zips
# or use a curated starter preset:
./scripts/zip-a-skill.sh --preset core-pm --output dist/skill-zips

Examples

Example: Turn Workshop Notes into a Skill

Input: research/pricing-workshop-notes.md
Goal: new interactive advisor

./scripts/add-a-skill.sh research/pricing-workshop-notes.md
./scripts/test-a-skill.sh --skill <new-skill-name> --smoke
python3 scripts/check-skill-metadata.py skills/<new-skill-name>/SKILL.md

Expected result:

  • New skill folder exists
  • Skill passes structural and metadata checks
  • README catalog entry added/updated

Anti-Pattern Example

"We wrote a cool skill, skipped validation, forgot README counts, and shipped anyway."

Result:

  • Broken references
  • Inconsistent catalog numbers
  • Confusion for contributors and users

Common Pitfalls

  • Shipping vibes, not standards.
  • Choosing workflow when the task is really a component template.
  • Bloated descriptions that exceed upload limits.
  • Descriptions that say what the skill is but not when Claude should trigger it.
  • Descriptions that silently hit the 200-char limit and get cut off mid-thought.
  • Letting intent become a substitute for a weak trigger description.
  • Forgetting to update README counts after adding a skill.
  • Treating generated output as final without review.

References

  • README.md
  • AGENTS.md
  • CLAUDE.md
  • docs/Building PM Skills.md
  • docs/Add-a-Skill Utility Guide.md
  • Anthropic's Complete Guide to Building Skills for Claude
  • scripts/add-a-skill.sh
  • scripts/build-a-skill.sh
  • scripts/find-a-skill.sh
  • scripts/test-a-skill.sh
  • scripts/check-skill-metadata.py
  • scripts/check-skill-triggers.py
  • scripts/zip-a-skill.sh
为关键干系人制定定制化沟通策略。通过诊断双方动机、关系历史及潜在阻力,区分执行与规划阶段,避免通用化沟通失效。适用于准备重要对话、化解冲突或对齐关键关系前的专项规划。
准备与关键干系人的重要对话或会议 需要化解特定干系人的抵触情绪或阻力 在关键里程碑前需对齐重要干系人关系 针对高影响力或可能阻碍项目的干系人制定管理计划
skills/stakeholder-engagement-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill stakeholder-engagement-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "stakeholder-engagement-advisor",
    "type": "interactive",
    "intent": "Guide per-stakeholder engagement planning through the Adaptive Decision Ladder: three targeted questions diagnose the stakeholder's profile, power\/impact quadrant, and your engagement context, then deliver a tailored approach — key message framing, recommended medium and cadence, what you need from them versus what they need from you, and a named next action with owner and deadline. Treats both sides of the relationship, not just yours.",
    "sources": [
        "MITRE Innovation Toolkit — Quickstart Stakeholder Engagement Canvas: https:\/\/itk.mitre.org\/toolkit-tools\/quickstart-stakeholder-engagement-canvas\/"
    ],
    "best_for": [
        "Preparing to engage a powerful executive sponsor whose support is critical but whose motivations are unclear",
        "Planning outreach to a resistant or skeptical stakeholder who could block your roadmap",
        "Navigating first contact with a newly identified stakeholder mid-initiative",
        "Designing inclusive engagement for a Q1 (high-impact, low-power) user community that needs more voice",
        "Aligning cross-functional engagement strategy before a high-stakes roadmap review or launch"
    ],
    "scenarios": [
        "Help me plan how to engage [stakeholder] before my roadmap review",
        "I have a resistant stakeholder — how do I approach them?",
        "I need to bring a new executive sponsor up to speed quickly",
        "How do I engage frontline users who've been excluded from our feedback loops?",
        "Help me prepare a 1:1 with someone who could block this initiative"
    ],
    "description": "Plan engagement for a specific stakeholder. Use when preparing an outreach, navigating resistance, or aligning a critical relationship before a key milestone.",
    "argument-hint": "[stakeholder and situation]"
}

Stakeholder Engagement Advisor

Purpose

Plan how to engage a specific stakeholder — before a critical conversation, milestone, or relationship repair. Generic stakeholder engagement fails because it treats all stakeholders with the same message, medium, and cadence. An executive sponsor who privately disagrees with your direction needs different handling than an impacted frontline user who's never been consulted. This skill diagnoses the specific stakeholder relationship you're managing and delivers a tailored engagement approach that accounts for both sides of the conversation — their motivations and yours.

Run this skill once per priority stakeholder. Priority stakeholders are those in the "manage closely" quadrant from stakeholder-mapping, every Q1 (high-impact, low-power) stakeholder regardless of Power × Interest placement, and anyone who has the potential to block, delay, or fundamentally reshape your initiative.

Input

Works best with: The specific stakeholder and the situation — the conversation, milestone, or tension you're preparing for. Also useful: Their power/interest read, history with you or the initiative, and what a good outcome looks like.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking who the stakeholder is and what's coming up with them.

Example invocation: Plan engagement: our VP Sales publicly supports the replatform but keeps escalating exceptions — QBR in 2 weeks.

Key Concepts

Stakeholder Motivations vs. Your Motivations — The most common engagement failure is planning only your side of the conversation. Effective stakeholder engagement requires mapping what the stakeholder needs, wants, and fears — separately from what you need from them. Where these overlap, you have an alignment path. Where they diverge, you have a negotiation to prepare for.

Proxy — A credible representative who speaks for or stands in for a stakeholder who is hard to reach, part of a large group, or represents a community rather than an individual. A good proxy is validated: they understand and can speak for the people they represent. A convenient proxy — the person who shows up to meetings — often cannot. Name the proxy explicitly and verify their representativeness before relying on their input.

Analysis Before Action — The engagement plan has two phases: diagnosis (who is this person, what drives them, what is the relationship history?) and planning (what will you say, through which medium, with what desired outcome?). Teams that skip directly to planning produce tactics without foundation — a message crafted for the wrong motivation, a medium that signals the wrong level of importance, an ask that misreads what the stakeholder actually controls.

Equity Lens in Engagement — High-impact, low-power stakeholders (Q1 from stakeholder-mapping) require proactive engagement design, not an open-door policy. An open door serves the people who already know they have a seat at the table. Q1 stakeholders typically need you to go to them: structured research recruitment, named roles in review processes, and deliberate inclusion in decisions that affect them.

Next Action Commitment — Every engagement plan must end with a named next action: who does what, by when, through which medium, with what key message and desired outcome. Engagement plans without this commitment are intentions, not plans. The next action is the only part that actually moves the relationship forward.

Engagement Context — The situational frame around the engagement matters as much as the stakeholder profile. Preparing for a first contact requires different framing than recovering from a conflict, securing buy-in before a launch, or maintaining an already-aligned relationship. The context shapes the message, the medium, and the desired outcome.

Application

This skill runs as a guided conversation. Answer each question; the advisor synthesizes your inputs and delivers a tailored engagement plan structured around three decision points:

  1. Stakeholder profile — who they are and what role they play
  2. Power and impact — how much authority they hold vs. how much they're affected
  3. Engagement context — the situation you're preparing for

After all three, you receive a set of numbered engagement approaches to choose from, then a specific action plan.


Opening

"We're going to plan your engagement with a specific stakeholder. I'll ask three questions about them and the situation, then deliver a tailored approach — message framing, medium, cadence, and your next action.

Who is this stakeholder? Give me their name, role, and one sentence on the history of your relationship with them so far."


Question 1 of 3 — Stakeholder profile

"Which of the following best describes this stakeholder?

  1. Executive sponsor or senior decision-maker — holds formal authority over scope, budget, or go/no-go; your initiative needs their active support or at minimum their absence of resistance
  2. Cross-functional peer or partner — adjacent team lead whose capacity, systems, or process your initiative touches; peer relationship, not a reporting one
  3. End user or community representative — the person or group who will live with the product's outcomes daily; may have limited org power but high stakes in the result
  4. Skeptic or potential blocker — has publicly or privately expressed resistance, doubt, or competing priorities; could slow or derail the initiative if not addressed
  5. Newly identified stakeholder — discovered mid-initiative; relationship history is thin or nonexistent"

Based on the answer, tailor the next question and the eventual recommendation.


Question 2 of 3 — Power and impact profile

"Looking at this stakeholder's position from your stakeholder mapping — or your best read if you haven't mapped formally yet:

  1. High power, high impact — they can shape the initiative AND they're significantly affected by its outcome (e.g., the VP whose team's workflow changes and who controls the budget)
  2. High power, low impact — they control resources or approval but aren't significantly affected day-to-day (e.g., a CFO approving budget for a product they'll never use)
  3. Low power, high impact — they're directly affected by the product's outcome but have limited org authority to shape it (e.g., frontline users, support agents, end communities)
  4. Low power, low impact — limited stakes and limited authority; still worth mapping but engagement investment should be proportionate"

Question 3 of 3 — Engagement context

"What's the situation you're preparing for?

  1. First contact — establishing a relationship and earning credibility before the work gets political
  2. Pre-milestone alignment — roadmap review, launch gate, OKR commitment, or exec briefing coming up; you need this stakeholder in a good place beforehand
  3. Resistance or conflict — the stakeholder has expressed disagreement, is blocking progress, or has competing priorities that put them at cross-purposes
  4. Elevating an underrepresented voice — this is a Q1 stakeholder who has been excluded from or underrepresented in decision-making; you're designing proactive inclusion
  5. Ongoing maintenance — an existing, aligned relationship that needs sustained investment to stay that way"

Synthesis and recommendations

After all three answers, deliver a tailored engagement plan:

"Based on [stakeholder type], [power/impact profile], and [engagement context], here are your recommended approaches:

1. [Approach name] — [When this fits and what it accomplishes] 2. [Approach name] — [Alternative for different risk tolerance or timeline] 3. [Approach name] — [Option for higher or lower relationship investment]

Choose a number, combine approaches (e.g., '1 then 3'), or describe your situation in more detail."

After selection, deliver the specific plan:

  • Key message: What is the single most important thing you want them to understand or believe after this interaction?
  • Framing: How does this initiative connect to what they care about? Lead with their goals, not yours.
  • Medium and format: Email, 1:1, group briefing, written pre-read, working session, or research participation? Why this medium for this stakeholder?
  • Cadence: One-time touchpoint or recurring? At what frequency?
  • What you need from them: Be specific — a decision, an approval, information, validation, or simply awareness.
  • What they likely need from you: Based on their profile — transparency, influence over design, credit for contribution, assurance about risk, or proof of impact.
  • Next action: [Owner] will [action] via [medium] by [date/milestone], with the message "[key message]" and the desired outcome "[what success looks like for this interaction]."

Handling edge cases

  • If the stakeholder is a large group (e.g., a user community): shift to proxy identification — name the most credible representative, validate their alignment to the group, design engagement through them while building broader touchpoints over time.
  • If the relationship has history of conflict: lead with listening before proposing; the goal of the first engagement is to understand their concerns, not to persuade.
  • If the engagement plan feels implausible given timeline or access constraints: scope down to what's achievable and name the residual risk explicitly.

Examples

Sample conversation flow — Executive sponsor, pre-milestone

Advisor: "Who is this stakeholder?" User: "SVP of Product — she's the exec sponsor. We've had two brief introductions at all-hands. She's publicly supportive but we've never had a real conversation about what she actually thinks about the approach."

Advisor: "Which profile fits best: 1-5?" [see Question 1] User: "1 — Executive sponsor."

Advisor: "Power and impact?" [see Question 2] User: "1 — High power, high impact. Her org uses the product and she controls the Q3 budget commitment."

Advisor: "Engagement context?" [see Question 3] User: "2 — Pre-milestone. Roadmap review in three weeks."

Advisor: "Recommended approaches:

  1. Pre-read + 1:1 alignment — Send a two-page executive brief 5 days before the review, then request a 30-minute 1:1 to walk through it. Goal: surface her unstated concerns before the room hears them first.
  2. Working session — Invite her into a 60-minute pre-review working session to shape the framing. Higher investment, but earns genuine co-ownership.
  3. Informal check-in — A brief hallway or coffee conversation, no slides. Lower risk if her support is likely solid; insufficient if there's a 30% chance of a surprise objection.

Key message: 'Here's where we are, why we made these calls, and the three decisions we need your guidance on.' What she likely needs from you: Evidence that you've managed the political risks she'd have to defend upward. Next action: [You] send executive brief to [her EA] by [date minus 5 days], request 30-minute slot before the review, with the message: 'I want to walk you through the direction and make sure you have what you need for the room.'"


Sample flow — Frontline users, elevating underrepresented voice

Advisor: "Who is this stakeholder?" User: "Customer support agents — about 40 people. We've never talked to them during this initiative even though their tooling changes completely."

Profile: 3 (End user / community representative) Power/Impact: 3 (Low power, high impact — Q1) Context: 4 (Elevating underrepresented voice)

Advisor: "Recommended approach:

  1. Structured research recruitment — Recruit 5-8 agents for a 30-minute discovery interview using the discovery-interview-prep skill. This gives you validated insight before requirements are locked and signals that their perspective shapes the product.
  2. UAT role with feedback loop — Include agents in user acceptance testing with a clear feedback mechanism. Commit publicly to reporting back what changed because of their input.
  3. Proxy identification — If direct access is limited, identify the team lead or most experienced agent who can credibly represent the group. Validate their representativeness with the team before relying on their input.

Key message: 'We want to understand how this changes your day-to-day work before we finalize the design.' Next action: [You] coordinate with support manager by [date] to schedule 5 discovery interviews, with the message: 'We're redesigning intake and need the team's perspective to get it right.'"

Common Pitfalls

Planning only your side of the conversation. An engagement plan that focuses entirely on your message and your ask treats the stakeholder as an audience to persuade rather than a person with their own goals, fears, and constraints. Map their motivations first. The message that lands is the one that connects to what they care about.

Running it on every stakeholder regardless of priority. Per-stakeholder engagement planning takes time. Reserve it for high-stakes relationships: "manage closely" stakeholders, Q1 stakeholders, and anyone who can block or derail. Monitor-tier stakeholders don't need a tailored plan.

Treating the engagement plan as permanent. Stakeholder relationships evolve. A successfully pre-aligned sponsor can become skeptical after a bad sprint review. An initially resistant peer can become an ally once they see their concern addressed. Revisit the plan after major milestones.

Substituting a convenient proxy for a credible one. The person who shows up to meetings and is easy to reach is often not the person who can accurately represent the group they nominally speak for. A credible proxy is validated — they've confirmed their own alignment with the group they represent.

Ending without a named next action. An engagement plan without owner, action, medium, and deadline is an intention. Intentions don't move relationships forward. The next action is the only output that matters.

Using the same medium for all stakeholders. An executive who's already in back-to-back meetings doesn't need another meeting — they need a well-written pre-read. A frontline user who's never been consulted doesn't need an email — they need a face-to-face research session that signals their perspective actually matters. Match the medium to the relationship and context.

References

用于在启动项目或制定计划前,全面识别利益相关者。通过盟友/受众/影响者分类、RPD标记及公平视角,确保纳入边缘群体,避免遗漏关键决策者与受影响方,为后续优先级排序和沟通策略奠定基础。
启动新项目或倡议 进行需求调研范围界定 从零构建参与计划 需要全面梳理利益相关者名单
skills/stakeholder-identification/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill stakeholder-identification -g -y
SKILL.md
Frontmatter
{
    "name": "stakeholder-identification",
    "type": "component",
    "intent": "Produce a comprehensive, equity-aware stakeholder set before any engagement begins. Combines broad brainstorm with structured categorization (Allies \/ Audiences \/ Influencers, R\/P\/D marking), an explicit equity and bias check, and a disciplined narrowing to the 2-3 stakeholders to understand deeply first. Designed to run as a solo exercise or a kickoff workshop. Feed outputs directly into stakeholder-mapping for prioritization.",
    "sources": [
        "MITRE Innovation Toolkit — Stakeholder Identification Canvas: https:\/\/itk.mitre.org\/toolkit-tools\/stakeholder-identification-canvas\/",
        "MITRE Innovation Toolkit — Community Map: https:\/\/itk.mitre.org\/toolkit-tools\/community-map\/"
    ],
    "best_for": [
        "Launching a new initiative where the stakeholder landscape is unmapped and influence networks are unknown",
        "Scoping a discovery sprint to define who to research, interview, and recruit",
        "Preparing a PRD stakeholder section with a validated, comprehensive list before writing requirements",
        "Onboarding to a new product domain and needing to map allies, gatekeepers, and decision-makers quickly",
        "Pressure-testing an existing stakeholder list for blind spots, bias, and missing edge-case populations"
    ],
    "scenarios": [
        "Who are all the stakeholders for this initiative?",
        "Are we missing anyone important in our stakeholder map?",
        "Help me prepare the stakeholder section of my PRD",
        "Who should we recruit for discovery research?"
    ],
    "description": "Map every stakeholder before engaging anyone. Use when launching an initiative, scoping discovery, or building an engagement plan from scratch.",
    "argument-hint": "[initiative]"
}

Stakeholder Identification

Purpose

Map every stakeholder before engaging anyone. This skill produces a comprehensive, equity-aware stakeholder set — not just the obvious sponsors and users, but the gatekeepers, the impacted communities, and the voices your team defaults to overlooking.

Most PM stakeholder lists are written from memory in five minutes. They reliably capture executives, product peers, and the most vocal users. They reliably miss the marginalized user groups who bear the product's consequences without having the organizational power to shape its decisions. This skill forces a slower, more structured brainstorm that builds the foundation for every engagement decision that follows.

Use this before stakeholder-mapping (which prioritizes) and before stakeholder-engagement-advisor (which plans per-stakeholder outreach). Identification comes first — you cannot prioritize people you haven't named.

Input

Works best with: The initiative, product, or decision you're mapping stakeholders for. Also useful: Stakeholders already on your list (the skill's job is to find who's missing), org context, and affected communities.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks what the initiative is and who it touches, then runs the equity-aware sweep.

Example invocation: Identify stakeholders for migrating all customers to the new billing system by Q4.

Key Concepts

Allies, Audiences, Influencers — The three categories that clarify stakeholder relationship to your work. Allies actively support the initiative; audiences are impacted by it; influencers shape opinion or decisions without being directly affected. Sorting stakeholders this way reveals who to recruit, who to inform, and who to persuade — three different engagement jobs.

R/P/D Marking — Tagging each stakeholder as a provider of Resources (budget, headcount, access), Permission (approval to proceed, regulatory clearance), or Decision-making authority (final say). This quickly surfaces who can fund, block, or green-light your initiative versus who is merely interested. One stakeholder can hold multiple tags.

Equity Lens — Deliberately stretching the list to include stakeholders who are often excluded: marginalized user populations, frontline employees, downstream communities, people who bear the product's consequences but lack organizational power to influence its design. Without this step, teams optimize for loud, well-resourced voices and build products that fail the quieter majority.

Primary, Secondary, Tertiary Effects — Tracing ripple effects of your product outward from direct users to indirectly affected groups. A feature that changes how support agents work (primary) affects how customers experience service (secondary), which affects the company's reputation and churn (tertiary). Following the chain surfaces stakeholders that single-level thinking misses.

Notice Bias & Assumptions — An explicit team check: who did we default to naming? Who is absent from the list? Whose perspective are we treating as universal? This step names the blind spots before they become requirements gaps.

Identification vs. Prioritization — The discipline of separating who exists from who matters most. The goal of this skill is a complete list, not a prioritized one. Collapsing these two steps causes teams to prematurely cut stakeholders they haven't yet understood. Prioritization happens in stakeholder-mapping.

Application

Step 1 — Brainstorm without filtering

Generate a fast, unconstrained list of potential stakeholders: individuals, teams, organizations, and communities connected to this initiative. Do not self-edit. Write down anyone who could plausibly have a stake — even if their involvement seems unlikely.

If working in a group, run this silently for 4-6 minutes before sharing.

Step 2 — Categorize

Sort each stakeholder into one or more of these categories:

  • Allies — who actively supports this work or would benefit from its success?
  • Audiences — who is impacted by the outcome, directly or indirectly?
  • Influencers — who shapes decisions, opinion, or adoption without being a direct participant?

Note: a stakeholder can appear in more than one category. Those overlaps — an ally who is also a key influencer — often mark your highest-leverage relationships.

Step 3 — Apply R/P/D marking

For each stakeholder, mark whether they provide:

  • R — Resources (budget, people, data, access)
  • P — Permission (approval, legal clearance, sign-off)
  • D — Decision authority (final say on scope, prioritization, or launch)

Any stakeholder holding P or D who is missing from your list is a gap that will surface later as a blocker.

Step 4 — Apply the equity lens

Ask the following questions about your list:

  • Who experiences a significant difference or consequence from this product — financially, professionally, or in their daily experience?
  • Who bears the product's costs or risks without having the power to shape its design?
  • Whose perspective is missing because we assumed someone else represents them?
  • Who are the primary users? Who are the secondary users? Who is affected in the third degree?

Add anyone the equity lens surfaces. These stakeholders are likely to end up in Q1 of your stakeholder-mapping (high impact, low power) — the voices most important to elevate.

Step 5 — Notice bias and assumptions

As a group, answer explicitly:

  • Who did we default to naming in Step 1?
  • Who is absent? Why?
  • What assumptions did we make about who counts as a stakeholder?

Record the answers. These shape your research plan and recruitment strategy.

Step 6 — Narrow to priority targets

With the full list visible, identify the 2-3 stakeholders you need to understand most deeply before proceeding. These are typically:

  • The highest-power decision-makers whose buy-in is required
  • The highest-impact users whose needs are least understood
  • The most likely blockers or skeptics

For each priority stakeholder, capture: name, category, R/P/D tag, and a one-line "what we need to learn from them." These outputs feed directly into stakeholder-mapping and stakeholder-engagement-advisor.

Examples

Situation: A product team is scoping a new intake workflow that replaces manual email-based requests with a self-service portal. Initial stakeholder list: VP of Operations, Engineering Lead, PMO Director, enterprise customers.

Underdeveloped (common default): The list captures obvious sponsors and the customer segment that asked loudest for the feature. Missing: the customer support agents who currently process every manual request (primary daily users of the current workflow), IT security team (P — must approve data handling), compliance officer (P — regulatory implications), small business customers who lack technical staff to use a self-service portal (high-impact, low-power audience).

Stronger list after applying equity lens and R/P/D marking:

  • VP of Operations (D, Ally) — final scope authority
  • Engineering Lead (R, Ally) — capacity and technical feasibility
  • PMO Director (P, Influencer) — must approve process change
  • Enterprise customers (Audience) — primary users of new portal
  • Customer support agents (Audience, R) — process every intake today; adoption risk if not consulted
  • IT Security (P) — data handling approval required
  • Compliance Officer (P) — regulatory review
  • Small business customers (Audience) — impacted differently; may need a non-self-service path

The second list produces a PRD with different requirements, a different rollout plan, and a different definition of success.

Common Pitfalls

Treating the first brainstorm as the final list. The initial pass reliably captures 60% of stakeholders and systematically misses the 40% who are less visible. The categorization and equity steps exist to close that gap — skipping them defeats the exercise.

Listing roles or org units instead of people. "Engineering" is not a stakeholder. The engineering lead who controls sprint capacity is. Vague category names prevent you from booking the conversation you actually need.

Conflating identification with prioritization. Cutting stakeholders during the brainstorm phase, before you've understood their actual influence or impact, is how high-impact, low-power voices get silently dropped. Complete the list first. Prioritize in stakeholder-mapping.

Skipping the bias and assumptions check. Teams that skip this step feel confident in their completeness. Teams that run it discover they've assumed a well-resourced user proxy speaks for everyone. Name the blind spot explicitly.

Running it solo without external validation. A single person's stakeholder map reflects a single person's network and assumptions. If working solo, use the bias check to identify who is absent from your mental model, then validate with a cross-functional colleague before proceeding.

Generating a complete list but capturing no next steps. The canvas ends with priority targets and actions for a reason. A comprehensive stakeholder list with no "who talks to whom, by when" attached is a document, not a plan.

References

通过运行权力-兴趣和影响-权力两个互补网格,优先排序干系人并制定参与策略。对比两者以识别被低估的高影响力低权力群体,揭示产品风险,适用于干系人识别后、沟通计划前。
需要为已识别的干系人制定参与策略 发现某些高影响但低权力的干系人被忽视或代表性不足 在干系人识别完成后进行优先级排序
skills/stakeholder-mapping/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill stakeholder-mapping -g -y
SKILL.md
Frontmatter
{
    "name": "stakeholder-mapping",
    "type": "component",
    "intent": "Run two complementary 2x2 grids — Power × Interest (sets engagement strategy per stakeholder) and Impact × Power (surfaces who bears consequences but lacks voice) — then compare outputs to reveal blind spots and plan quadrant migration. The grids answer different questions and neither one alone is sufficient: Power × Interest tells you how to engage; Impact × Power tells you whose voice to elevate. Feed outputs into stakeholder-engagement-advisor for per-stakeholder action planning.",
    "sources": [
        "MITRE Innovation Toolkit — Stakeholder Map & Matrix: https:\/\/itk.mitre.org\/toolkit-tools\/stakeholder-map-and-matrix\/",
        "MITRE Innovation Toolkit — Stakeholder Power Categories: https:\/\/itk.mitre.org\/toolkit-tools\/stakeholder-power-categories\/"
    ],
    "best_for": [
        "After stakeholder identification, when you need to decide who gets which level of engagement",
        "Preparing an engagement plan before a roadmap review where executives and impacted user groups have conflicting authority",
        "Surfacing high-impact, low-power user segments who deserve more voice in product decisions but lack org pull",
        "Re-baselining stakeholder strategy after a reorg has shifted who holds decision authority",
        "Planning a compliance or regulatory initiative where power to block sits separately from who bears the consequences"
    ],
    "scenarios": [
        "Who should I prioritize engaging on this initiative?",
        "How do I handle stakeholders with conflicting priorities?",
        "Help me figure out whose voice is missing from our roadmap decisions",
        "I need a stakeholder engagement strategy before our quarterly review"
    ],
    "description": "Prioritize stakeholders using two complementary grids. Use when setting engagement strategy and surfacing whose voice needs elevating after stakeholder identification.",
    "argument-hint": "[stakeholder list or initiative]"
}

Stakeholder Mapping

Purpose

Prioritize stakeholders and set engagement strategy. This skill runs two complementary grids on your identified stakeholder set and deliberately compares what they reveal, because each grid shows you something the other cannot.

Power × Interest answers: how much does each stakeholder care about this initiative, and how much can they influence it? It produces engagement strategies — who to involve deeply, who to keep informed, who to monitor. This is the grid most PMs know.

Impact × Power answers: who bears the consequences of this product's outcomes, and how much organizational power do they actually hold? It surfaces the stakeholders who matter most to get right but are most likely to be underrepresented — high impact, low power.

Running only the first grid optimizes for managing relationships with the powerful. Running only the second produces an equity analysis without an engagement plan. The insight lives in comparing them: a stakeholder who appears in "keep informed" on the first grid and "high impact, low power" on the second is someone you've been under-engaging with consequences that fall entirely on them. That's a product risk.

Use this after stakeholder-identification (which builds the full list) and before stakeholder-engagement-advisor (which plans per-stakeholder outreach).

Input

Works best with: Your identified stakeholder list (ideally from stakeholder-identification). Also useful: What you know about each person's power, interest, and current stance, plus the engagement decisions the map must drive.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the stakeholder set first — mapping unidentified stakeholders just formalizes your blind spots.

Example invocation: Map these 14 stakeholders for the billing migration on both grids — list attached with role notes.

Key Concepts

Power × Interest Grid — A 2×2 that plots stakeholders by their power to affect the initiative (vertical axis) and their interest in its outcome (horizontal axis). Produces four quadrants with prescribed engagement strategies:

  • High power, high interest → Manage closely (co-design, frequent touchpoints)
  • High power, low interest → Keep satisfied (executive briefings, strategic framing)
  • Low power, high interest → Keep informed (newsletters, demos, transparency)
  • Low power, low interest → Monitor (light touch, check-ins only)

Impact × Power Grid — A 2×2 that plots stakeholders by whether they are significantly affected by the initiative (vertical axis) and the power they hold to shape it (horizontal axis). Produces four quadrants:

  • High impact, high power → Q2 — impacted and empowered; manage closely
  • High impact, low power → Q1 — impacted but marginalized; elevate their voice deliberately
  • Low impact, high power → Q4 — gatekeepers; manage relationship, lower engagement depth
  • Low impact, low power → Q3 — monitor, minimal investment

Elevating Q1 Voices — High-impact, low-power stakeholders (Q1) are the people most likely to experience your product's failure modes and least likely to appear in your normal feedback loops. Deliberately increasing their role in roadmap decisions — through research recruitment, usability testing, and requirements review — is not just equitable; it reduces the product risk of building for the wrong problems.

Quadrant Migration — The deliberate strategy of moving a stakeholder from their current quadrant to a desired one through targeted actions. A skeptical executive currently in "monitor" who needs to become a sponsor requires a different set of actions than one already in "manage closely." Making migration explicit turns the map from a snapshot into a plan.

Impact vs. Power — These are not the same dimension. A frontline support agent has high impact (their daily workflow changes completely) but low power (no seat at the roadmap table). A VP of Finance has high power (budget approval) but low impact (the product doesn't change how they work). Conflating the two is the most common mapping error.

Paired Variables — The reason to run both grids rather than one. Different paired axes reveal different relationships. A single grid produces a single, incomplete picture. Running multiple analyses and comparing outputs is where the real insight lives.

Engagement Strategy — The differentiated communication and involvement approach assigned per quadrant. It allocates limited PM bandwidth where it yields the most leverage — and protects against the trap of treating all stakeholders equally, which means investing in low-stakes relationships while neglecting critical ones.

Application

Step 1 — Run the Power × Interest grid

For each stakeholder from your identification exercise, assess:

  • Power: Can this person or group significantly shape, regulate, approve, or block this initiative? (Consider formal authority, budget, veto power, and informal influence.)
  • Interest: Is this person or group actively engaged in or affected by the outcome? Do they have stated or likely opinions about the direction?

Place each stakeholder in the appropriate quadrant. Don't rank or quantify within quadrants at this step — the placement itself is the output.

Assign engagement strategy per quadrant:

  • Manage closely → deep involvement, co-design sessions, weekly or bi-weekly touchpoints
  • Keep satisfied → executive briefings, high-level framing, milestone updates
  • Keep informed → structured communications, demos, read-only access to artifacts
  • Monitor → light check-ins, available but not pursued

Step 2 — Run the Impact × Power grid

For each stakeholder, assess separately:

  • Impact: Will this initiative significantly affect this person or group — financially, professionally, in their daily work, or in their access to services? If yes, they're high impact.
  • Power: Can they significantly shape the initiative, regardless of whether they want to? (Same definition as Step 1, but assessed independently of interest.)

Place each stakeholder in the Q1–Q4 quadrants. Do this without referencing your Power × Interest placements — the independence of the two assessments is what makes the comparison valuable.

Step 3 — Compare and find the gaps

Place both grids side by side and ask:

  • Who appears in "keep informed" on Grid 1 and Q1 (high impact, low power) on Grid 2? These are stakeholders you're under-engaging relative to how much the product affects them.
  • Who appears in "manage closely" on Grid 1 and Q3/Q4 on Grid 2? These are powerful stakeholders with little stake in the outcome — watch for over-investment.
  • Who moved dramatically between grids? Those shifts reveal where power and consequences are misaligned.

Step 4 — Plan quadrant migration

For stakeholders you want to move:

  • Q1 → Q2: Actively recruit them into advisory processes, discovery research, and requirements review. Give them a named role, not just passive access.
  • Monitor → Keep informed: Increase transparency to build awareness and early alignment before the initiative becomes relevant to them.
  • Skeptic in any quadrant → Ally: Identify what they need to believe to become supportive, then design 1:1 engagement to address those concerns directly.

Document: who is moving, what action triggers the move, and who owns it.

Step 5 — Feed into engagement planning

For each stakeholder in "manage closely" and each Q1 stakeholder, create an engagement plan using stakeholder-engagement-advisor. These are the relationships where tactical planning — specific messages, mediums, cadences, and success criteria — yields the most return.

Examples

Situation: A platform team is migrating internal API infrastructure. Stakeholder list: VP of Engineering (sponsor), three engineering leads (direct users), Legal (compliance review), the customer support team (their tooling depends on the APIs), and enterprise customers who won't see the change directly but whose uptime depends on it.

Power × Interest grid placements:

  • VP of Engineering → Manage closely (high power, high interest)
  • Engineering Leads → Manage closely (high power, high interest — direct builders)
  • Legal → Keep satisfied (high power, low day-to-day interest)
  • Customer Support → Keep informed (low power, high interest — their tools change)
  • Enterprise Customers → Monitor (low power, low stated interest)

Impact × Power grid placements:

  • VP of Engineering → Q2 (high impact, high power)
  • Engineering Leads → Q2 (high impact, high power)
  • Legal → Q4 (low impact, high power)
  • Customer Support → Q1 (high impact, low power — their tooling breaks if migration fails)
  • Enterprise Customers → Q1 (high impact, low power — uptime dependency)

The gap the comparison reveals: Customer Support and Enterprise Customers are "monitor" or "keep informed" on Grid 1, but Q1 on Grid 2. The migration team has been treating them as passive observers when they're actually the highest-risk stakeholders. Resolution: recruit support agents into UAT, create an enterprise customer communication plan with rollback triggers, and add both groups to the launch readiness criteria.

Common Pitfalls

Running only one grid. Power × Interest without Impact × Power optimizes for managing relationships with the powerful while systematically under-serving high-impact, low-power groups. Impact × Power without Power × Interest produces an equity analysis with no engagement strategy attached. Both grids earn their place.

Conflating organizational seniority with power. A mid-level program manager who controls the approval queue for your initiative holds more practical power than a VP who's uninvolved. Informal influence — process knowledge, gatekeeping, coalition-building — is real power. Assess it, don't assume the org chart reflects it.

Treating placement as permanent. Org changes, budget cycles, and stakeholder rotations shift people between quadrants. Build in a re-run cadence at quarterly review cycles or after significant org events.

Stopping at placement without engagement actions. Two grids with dots on them and no "who does what next" is a pretty slide, not a plan. The map is a means to the migration strategy and the per-stakeholder engagement plan.

Quantifying or ranking within quadrants at placement time. The method explicitly discourages this. False precision at the categorization step derails the discussion into arguing about relative rankings instead of identifying who's missing from the right quadrants.

Letting Q1 stakeholders remain decorative. Naming high-impact, low-power stakeholders on the canvas and then continuing to engage them the same way is the most common failure. Elevation requires a concrete action: a named research slot, a co-design session, a role in requirements review, a presence at the launch readiness gate.

References

生成六格故事板,通过经典叙事弧展示用户从问题到解决的旅程。用于利益相关者对齐、概念评审或演示,以情感化方式具象化产品价值,而非UI原型。
需要快速叙事以对齐利益相关者 进行概念评审或演示 测试产品创意的情感共鸣 向高管或投资者传达愿景
skills/storyboard/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill storyboard -g -y
SKILL.md
Frontmatter
{
    "name": "storyboard",
    "type": "component",
    "intent": "Create a 6-frame visual narrative that tells the story of a user's journey from problem to solution, using the classic storytelling arc to build empathy, illustrate value, and make abstract product concepts concrete. Use this to align stakeholders, pitch features, communicate vision, or test if your solution resonates emotionally before building it.",
    "description": "Create a six-frame storyboard that shows a user's journey from problem to solution. Use when you need a fast narrative for alignment, concept reviews, or demos.",
    "argument-hint": "[user and problem]"
}

Purpose

Create a 6-frame visual narrative that tells the story of a user's journey from problem to solution, using the classic storytelling arc to build empathy, illustrate value, and make abstract product concepts concrete. Use this to align stakeholders, pitch features, communicate vision, or test if your solution resonates emotionally before building it.

This is not a UI mockup—it's a storytelling tool that brings the human side of your product to life.

Input

Works best with: The user and the problem-to-solution story you want told. Also useful: The emotional arc, key moments you know must appear, and the audience for the storyboard (execs, design review, sales).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks who the user is and what changes for them, then builds the six frames.

Example invocation: Storyboard: overwhelmed pharmacy tech discovers our auto-refill queue and ends the day on time — for next week's concept review.

Key Concepts

The 6-Frame Storyboard Structure

Based on classic narrative arcs, the 6-frame format follows this pattern:

  1. Frame 1: Main Character — Introduce the persona and their context
  2. Frame 2: The Problem Emerges — Show the challenge or obstacle they face
  3. Frame 3: The "Oh Crap" Moment — Escalate the problem to create urgency
  4. Frame 4: The Solution Appears — Introduce your product/feature
  5. Frame 5: The "Aha" Moment — Show the user experiencing the breakthrough
  6. Frame 6: Life After the Solution — Illustrate the improved state

Why This Works

  • Emotional engagement: Stories create empathy in ways specs can't
  • Concrete over abstract: Visual narrative makes vague concepts tangible
  • Memorable: People remember stories better than feature lists
  • Alignment tool: Stakeholders can react to a story and give feedback
  • Low-fidelity: Doesn't require polished design—sketches work great

Anti-Patterns (What This Is NOT)

  • Not a user flow diagram: This is emotional storytelling, not process documentation
  • Not a feature demo: Focus on user outcomes, not product capabilities
  • Not marketing copy: Authentic narrative, not hype

When to Use This

  • Pitching a new product or feature to stakeholders
  • Aligning teams on user value (product, design, engineering, execs)
  • Testing if a product idea resonates emotionally
  • Communicating vision at all-hands or investor meetings
  • Validating problem/solution fit before building

When NOT to Use This

  • For technical implementation details (use architecture diagrams instead)
  • When the user problem is trivial or well-understood
  • As a replacement for user research (storyboards illustrate insights, don't create them)

Application

Use template.md for the full fill-in structure.

Step 1: Gather Context

Before creating the storyboard, ensure you have:

  • Persona clarity: Who is the main character? (reference skills/proto-persona/SKILL.md)
  • Problem understanding: What challenge do they face? (reference skills/problem-statement/SKILL.md)
  • Solution definition: What product/feature will help? (reference skills/positioning-statement/SKILL.md)
  • Desired outcome: What does success look like for the user?

If missing context: Run discovery work first. Don't fabricate personas or problems.


Step 2: Answer the 7 Storyboard Questions

Ask these questions one at a time to develop the narrative:

  1. Who is the main character experiencing this problem? (Name, age, role, context)
  2. Describe the problem or challenge the main character is facing.
  3. Describe the "Oh Crap" moment where the problem creates a major issue.
  4. How is the solution introduced to the main character?
  5. Describe the main character using the solution and experiencing an "Aha" moment.
  6. What is life like for the main character after using the solution?
  7. Do you have any specific visual style or rendering instructions? (Default: fat-marker sharpie sketches, minimal and monochrome)

Step 3: Write the 6-Frame Narrative

Based on the answers above, draft the narrative:

## Generated 6-Frame Storyline

**Frame 1: Introducing the Main Character**
- [Insert description of the main character, their setting, and context]
- [Example: "Sarah, 35, is a freelance graphic designer juggling 10 client projects from her home office"]

**Frame 2: The Problem Emerges**
- [Describe the main character's challenge and how it affects their life]
- [Example: "She's drowning in invoice tracking—8 hours per month chasing late payments via spreadsheets and email"]

**Frame 3: The 'Oh Crap' Moment**
- [Highlight the escalation of the problem into a major issue]
- [Example: "A major client's payment is 2 weeks overdue. Sarah realizes she forgot to follow up because she was focused on design work. The client has now gone silent, and she's anxious about cash flow."]

**Frame 4: The Solution Appears**
- [Explain how the solution is introduced and the main character's initial reaction]
- [Example: "Sarah discovers SmartInvoice, a tool that automatically sends payment reminders at optimal times. She's skeptical—will it sound too pushy?—but decides to try it."]

**Frame 5: The 'Aha' Moment**
- [Show the main character using the solution and experiencing a breakthrough]
- [Example: "Two days later, Sarah receives a notification: 'Client XYZ just paid!' The AI-timed reminder worked—no awkward follow-up call needed. She feels relieved and in control."]

**Frame 6: Life After the Solution**
- [Describe the resolution and how life improves after overcoming the problem]
- [Example: "Sarah now spends 30 minutes per month on invoicing instead of 8 hours. She's reclaimed her evenings, spending time with family instead of chasing payments. Her cash flow is predictable, and her anxiety is gone."]

**Optional Visual Elements**
- [If no visual style specified: "Use fat-marker, sharpie-style sketches—minimal, monochrome, hand-drawn feel"]
- [If visual elements provided: "Include user-provided images, GIFs, or icons"]

Step 4: Visualize Each Frame

For each frame, create or describe the visual:

Frame 1: Main Character

  • Visual: Sarah at her desk, surrounded by sticky notes, laptop open, coffee cup
  • Mood: Busy, slightly stressed
  • Tools: DALL·E, MidJourney, hand-drawn sketches

Frame 2: The Problem Emerges

  • Visual: Sarah staring at a spreadsheet labeled "Overdue Invoices," multiple browser tabs open
  • Mood: Overwhelmed
  • Details: Clock showing 10pm, to-do list getting longer

Frame 3: The 'Oh Crap' Moment

  • Visual: Sarah's phone showing "Day 14: Payment Overdue from Client XYZ" notification. Her face shows worry.
  • Mood: Anxious, urgent
  • Details: Calendar showing upcoming rent due date

Frame 4: The Solution Appears

  • Visual: Sarah's laptop showing the SmartInvoice landing page with headline "Stop Chasing Payments"
  • Mood: Curious, hopeful
  • Details: Testimonial quote: "Saved me 5 hours/month"

Frame 5: The 'Aha' Moment

  • Visual: Sarah's phone showing notification "Client XYZ just paid! $5,000 received." She's smiling, relieved.
  • Mood: Joy, relief, empowerment
  • Details: Background shows sunset—she's done with work early

Frame 6: Life After the Solution

  • Visual: Sarah playing with her kids in the backyard, laptop closed on the patio table
  • Mood: Peaceful, balanced
  • Details: Clock showing 6pm (not 10pm anymore)

Step 5: Test the Storyboard

Ask these questions:

  1. Is the main character relatable? Would your target persona recognize themselves?
  2. Is the problem visceral? Do people feel the frustration in Frame 2-3?
  3. Is the "Oh Crap" moment real? Does it escalate the problem authentically?
  4. Is the solution introduction natural? Or does it feel forced/contrived?
  5. Is the "Aha" moment believable? Can users imagine experiencing this?
  6. Is the "after" state aspirational? Would users want this outcome?

If any answer is "no," revise.


Examples

See examples/sample.md for full storyboard examples.

Mini example excerpt:

**Frame 1:** Sarah, 35, freelance designer juggling 10 clients\n**Frame 2:** Spends 8 hours/month chasing overdue invoices\n**Frame 3:** $5,000 payment is 2 weeks overdue\n```

---

## Common Pitfalls

### Pitfall 1: Generic Persona
**Symptom:** "Meet User, a busy professional"

**Consequence:** No one identifies with this character.

**Fix:** Get specific: "Meet Sarah, 35, freelance designer, juggling 10 clients, home office, loves design but hates admin."

---

### Pitfall 2: Weak Problem
**Symptom:** "User has a problem with efficiency"

**Consequence:** Problem doesn't resonate emotionally.

**Fix:** Make it visceral: "Sarah spends 8 hours/month chasing overdue invoices, missing family dinners, feeling anxious about cash flow."

---

### Pitfall 3: Forced Solution Introduction
**Symptom:** "User magically discovers our product"

**Consequence:** Feels contrived, not authentic.

**Fix:** Show realistic discovery: "Sarah sees a recommendation in a designer forum" or "Sarah's colleague mentions it."

---

### Pitfall 4: Feature-Centric "Aha" Moment
**Symptom:** "User sees the dashboard and loves the features"

**Consequence:** No emotional payoff.

**Fix:** Focus on outcome: "Sarah gets notification: '$5,000 received!' She's relieved—no awkward call needed."

---

### Pitfall 5: Vague "After" State
**Symptom:** "Life is better now"

**Consequence:** Not aspirational or concrete.

**Fix:** Be specific: "Sarah leaves work at 6pm now, spending evenings with her kids instead of chasing clients. On-time payments jumped from 50% to 80%."

---

## References

### Related Skills
- `skills/proto-persona/SKILL.md` — Defines the main character
- `skills/problem-statement/SKILL.md` — Frames the problem for Frame 2-3
- `skills/positioning-statement/SKILL.md` — Informs the solution introduction in Frame 4
- `skills/jobs-to-be-done/SKILL.md` — Informs the desired outcome in Frame 6

### External Frameworks
- Joseph Campbell, *The Hero's Journey* (1949) — Classic narrative structure
- Pixar's story rules — "Once upon a time... Every day... Until one day..."
- Donald Miller, *Building a StoryBrand* (2017) — Story-driven marketing frameworks

### Dean's Work
- Storyboard Storytelling Prompt (6-Frame Storyline Generator)

### Provenance
- Adapted from `prompts/storyboard-storytelling-prompt.md` in the `https://github.com/deanpeters/product-manager-prompts` repo.

---

**Skill type:** Component
**Suggested filename:** `storyboard.md`
**Suggested placement:** `/skills/components/`
**Dependencies:** References `skills/proto-persona/SKILL.md`, `skills/problem-statement/SKILL.md`, `skills/positioning-statement/SKILL.md`, `skills/jobs-to-be-done/SKILL.md`
用于计算TAM、SAM和SOM的结构化市场估算工具。通过自适应提问,结合真实数据引用与明确假设,为产品创意或商业计划提供经得起推敲的市场规模分析,适用于融资路演或内部验证。
需要计算市场规模 准备投资人演示文稿 验证产品市场契合度 设定增长目标
skills/tam-sam-som-calculator/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill tam-sam-som-calculator -g -y
SKILL.md
Frontmatter
{
    "name": "tam-sam-som-calculator",
    "type": "interactive",
    "intent": "Guide product managers through calculating Total Addressable Market (TAM), Serviceable Available Market (SAM), and Serviceable Obtainable Market (SOM) for a product idea by asking adaptive, contextually relevant questions. Use this to build defensible market size estimates backed by real-world citations, economic projections, and population data—essential for pitching to investors, securing budget, or validating product-market fit.",
    "description": "Calculate TAM, SAM, and SOM with explicit assumptions, methods, and caveats. Use when sizing a market for a product idea, business case, or executive review.",
    "argument-hint": "[product idea] [market constraints]"
}

Purpose

Guide product managers through calculating Total Addressable Market (TAM), Serviceable Available Market (SAM), and Serviceable Obtainable Market (SOM) for a product idea by asking adaptive, contextually relevant questions. Use this to build defensible market size estimates backed by real-world citations, economic projections, and population data—essential for pitching to investors, securing budget, or validating product-market fit.

This is not a back-of-napkin guess—it's a structured, citation-backed analysis that withstands scrutiny.

Input

Works best with: The product or idea being sized, and any market constraints you already know (geography, vertical, customer type). Also useful: Pricing assumptions, comparable companies, and the audience for the numbers (investors, execs, business case).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The calculator opens by asking what you're sizing and for whom, then works through method and assumptions.

Example invocation: Size the market: AI scheduling assistant for independent dental practices, US only, $99/mo price point.

Key Concepts

TAM/SAM/SOM Framework

The three-tier market sizing model:

Total Addressable Market (TAM):

  • The total market demand for a product or service
  • "If we captured 100% of the market, what's the revenue?"
  • Broadest possible market (no constraints)

Serviceable Available Market (SAM):

  • The segment of TAM your company can realistically target
  • Narrowed by geography, firmographics, demographics, or product constraints
  • "Who can we actually reach with our product?"

Serviceable Obtainable Market (SOM):

  • The portion of SAM you can realistically capture
  • Accounts for competition, market constraints, go-to-market capacity
  • "What can we capture in the next 1-3 years?"

Why This Works

  • Top-down validation: TAM → SAM → SOM ensures estimates are grounded in reality
  • Investor-friendly: Standard framework VCs and execs understand
  • Citation-backed: Real data sources (Census, Statista, World Bank) add credibility
  • Adaptive: Questions adjust based on context (B2B vs. B2C, US vs. global, etc.)

Anti-Patterns (What This Is NOT)

  • Not a single-number guess: "The market is $10B" without supporting data
  • Not static: Markets evolve—reassess annually
  • Not a substitute for customer validation: Market size ≠ product-market fit

When to Use This

  • Pitching to investors or execs (need market size in deck)
  • Validating product ideas (is the market big enough?)
  • Prioritizing product lines (which has bigger opportunity?)
  • Setting growth targets (what's realistic to capture?)

When NOT to Use This

  • For internal tools with captive users (no external market)
  • Before defining the problem (market sizing requires clear problem space)
  • As the only validation (pair with customer research)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

Use template.md for the full fill-in structure.

This interactive skill asks up to 4 adaptive questions, offering enumerated context-aware options at each step. The agent adapts questions based on previous responses.


Step 0: Gather Context (Before Questions)

Agent suggests:

Before we begin, it's helpful to have product context. If available, please share:

For Your Own Product:

  • Website copy (homepage, product pages, value prop statements)
  • Marketing emails or landing pages
  • Product descriptions or positioning statements
  • Case studies or customer testimonials
  • Sales deck or pitch materials

If You Don't Have a Product Yet:

  • Find a similar or adjacent product (competitor or analog)
  • Copy their website homepage, product description, or landing page
  • We'll use this as a reference point for market sizing

You can paste this content directly, or we can proceed with a brief description.

Why this helps:

  • Marketing materials already contain target audience, pain points, and value props
  • Analyzing real content (yours or competitors') grounds the analysis in reality
  • You can benchmark against similar products' market positioning

Optional Helper Script (Deterministic Math)

If you already have population and ARPU numbers (or a TAM estimate), you can run a deterministic helper to compute TAM/SAM/SOM and generate a Markdown table. This script does not fetch data or write files.

python3 scripts/market-sizing.py --population 5400000 --arpu 1000 --sam-share 30% --som-share 10%

Question 1: Problem Space

Agent asks: "Based on the context you've provided (or will describe), what problem space are you exploring for market sizing?"

Offer 4 enumerated examples (user can select by number or write custom):

  1. B2B SaaS productivity — E.g., "Workflow automation for small business operations" (like Zapier, Integromat)
  2. Consumer fintech — E.g., "Personal budgeting app for Gen Z users" (like Mint, YNAB)
  3. Healthcare/telehealth — E.g., "Mental health support for remote workers" (like BetterHelp, Talkspace)
  4. E-commerce enablement — E.g., "Payment processing for online sellers" (like Stripe, Square)

Or write your own problem space description based on the marketing materials you shared.

Tip: If you provided website copy or marketing materials, the agent can extract the problem space from phrases like:

  • "We help [target] solve [problem]"
  • "The #1 solution for [use case]"
  • Customer pain points in testimonials or case studies

User response: [Selection or custom description]


Question 2: Geographic Region

Agent asks: "What geographic region are you targeting?"

Offer 4 enumerated options (adapted based on problem space):

  1. United States — Best for detailed Census Bureau data, BLS stats, robust industry reports
  2. European Union — Use Eurostat, local statistical agencies; note GDPR/compliance considerations
  3. Global — World Bank, IMF data; broader but less granular
  4. Specific country/region — E.g., "Canada," "Southeast Asia," "Latin America"

Or specify your own region.

User response: [Selection or custom]

Adaptation logic:

  • If user selected B2B SaaS (Question 1, Option 1) → Emphasize US/EU markets (mature SaaS adoption)
  • If user selected Consumer fintech (Question 1, Option 2) → Mention emerging markets (higher mobile adoption)

Question 3: Industry/Market Segments

Agent asks: "What specific industry or market segments does this problem space relate to?"

Offer 4 enumerated options (adapted based on problem space + geography):

Example (if Question 1 = B2B SaaS, Question 2 = US):

  1. SMB services sector — 5.4M businesses, $1.2T revenue (US Census, 2023)
  2. Professional services (legal, accounting) — 1.1M firms, $850B revenue (IBISWorld, 2023)
  3. Healthcare providers — 900K practices, $4T industry (BLS, 2023)
  4. Tech/software companies — 500K firms, $1.8T revenue (Statista, 2023)

Or describe your own industry segment.

User response: [Selection or custom]

Adaptation logic:

  • If Question 1 = Consumer fintech, offer consumer segments (e.g., "Gen Z 18-25," "Millennials 25-40")
  • If Question 1 = Healthcare, offer segments (e.g., "Primary care physicians," "Therapists/counselors")

Question 4: Potential Customers (Demographics/Firmographics)

Agent asks: "Who are the potential customers affected by this problem?"

Offer 4 enumerated options (adapted based on previous answers):

Example (if Question 1 = B2B SaaS, Question 3 = SMB services sector):

  1. SMBs with 10-50 employees — 1.2M businesses, $400B revenue (Census Bureau, 2023)
  2. SMBs with 50-250 employees — 600K businesses, $800B revenue (Census Bureau, 2023)
  3. Solo entrepreneurs/freelancers — 3.5M self-employed, $200B revenue (BLS, 2023)
  4. Service businesses with online presence — 2M businesses, $600B e-commerce (Statista, 2023)

Or describe your own customer segment (firmographics, demographics, income, etc.).

User response: [Selection or custom]


Output: Generate TAM/SAM/SOM Analysis

After collecting responses, the agent generates a structured analysis:

# TAM/SAM/SOM Analysis

**Problem Space:** [User's input from Question 1]
**Geographic Region:** [User's input from Question 2]
**Industry/Market Segments:** [User's input from Question 3]
**Potential Customers:** [User's input from Question 4]

---

## Total Addressable Market (TAM)

**Definition:** The total market demand if you captured 100% of potential customers in the problem space.

**Population Estimate:** [Calculated from data sources]
- **Source:** [Citation, e.g., "US Census Bureau, 2023"]
- **Calculation:** [Show math, e.g., "5.4M SMBs × $1.2T revenue = $1.2T TAM"]

**Market Size Estimate:** $[X] billion/million
- **Source:** [Industry report citation]
- **URL:** [Clickable link to source]

---

## Serviceable Available Market (SAM)

**Definition:** The segment of TAM you can realistically target with your product (narrowed by geography, firmographics, product fit).

**Segment of TAM:** [User's narrowed segment from Question 4]

**Population Estimate:** [Calculated]
- **Source:** [Citation]
- **Calculation:** [Show math, e.g., "1.2M SMBs with 10-50 employees"]

**Market Size Estimate:** $[X] billion/million
- **Source:** [Citation]
- **URL:** [Link]

**Assumptions:**
- [List key assumptions, e.g., "Assumes 50% of SMBs have budget for automation tools"]

---

## Serviceable Obtainable Market (SOM)

**Definition:** The portion of SAM you can realistically capture in the next 1-3 years, accounting for competition and market constraints.

**Realistically Capturable Market:** [Agent's estimation based on market maturity, competition]

**Population Estimate:** [Calculated]
- **Source:** [Citation]
- **Calculation:** [Show math, e.g., "1.2M SMBs × 5% market share (Year 1) = 60K customers"]

**Market Size Estimate:** $[X] million
- **Assumptions:**
  - [Competition assumption, e.g., "5 major competitors, market leader has 15% share"]
  - [GTM assumption, e.g., "Sales capacity: 50 customers/month in Year 1"]
  - [Conversion assumption, e.g., "10% trial-to-paid conversion"]

**Year 1-3 Projections:**
- **Year 1:** [X]K customers, $[X]M revenue (5% of SAM)
- **Year 2:** [X]K customers, $[X]M revenue (10% of SAM)
- **Year 3:** [X]K customers, $[X]M revenue (15% of SAM)

---

## Data Sources & Citations

- [Source 1: e.g., "US Census Bureau (2023). County Business Patterns. URL: census.gov"]
- [Source 2: e.g., "IBISWorld (2023). Professional Services Industry Report. URL: ibisworld.com"]
- [Source 3: e.g., "Statista (2023). SMB Software Market Size. URL: statista.com"]
- [Add all sources used]

---

## Validation Questions

1. **Does TAM align with industry reports?** [Compare to 3rd-party market research]
2. **Is SAM realistically serviceable?** [Can your GTM motion reach this segment?]
3. **Is SOM achievable given competition?** [Is 5-15% market share realistic in 3 years?]

---

## Next Steps

1. **Validate with customer interviews:** Does the problem resonate with target segment?
2. **Benchmark against competitors:** What market share do incumbents have?
3. **Refine SOM based on GTM capacity:** Can sales/marketing support this growth?
4. **Update annually:** Markets shift—reassess TAM/SAM/SOM yearly

---

**Would you like to refine any assumptions or explore a different segment?**

Examples

See examples/sample.md for a full TAM/SAM/SOM analysis example.

Mini example excerpt:

**TAM:** 5.4M SMBs × $2,000 ARPA = $10.8B
**SAM:** 1.2M SMBs × $2,000 ARPA = $2.4B
**SOM:** 5% of SAM = $120M

Common Pitfalls

Pitfall 1: TAM Without Citations

Symptom: "The market is $50B" (no source)

Consequence: Can't defend the number to investors or execs.

Fix: Cite industry reports (Gartner, IBISWorld, Statista) with URLs.


Pitfall 2: SOM Equals SAM

Symptom: "SAM is $5B, SOM is $5B" (assuming 100% capture)

Consequence: Unrealistic projection—no market has zero competition.

Fix: SOM should be 1-20% of SAM in Year 1-3, accounting for competition.


Pitfall 3: No Population Estimates

Symptom: Only dollar amounts, no customer counts

Consequence: Can't build sales/marketing plans without knowing customer volume.

Fix: Always include population (e.g., "1.2M businesses" or "60K customers in Year 1").


Pitfall 4: Static Assumptions

Symptom: TAM/SAM/SOM calculated once, never updated

Consequence: Stale data as markets shift.

Fix: Reassess annually. Markets grow/shrink, competition changes, new data emerges.


Pitfall 5: Ignoring GTM Constraints

Symptom: "SOM is 50% of SAM in Year 1" (but no sales team)

Consequence: SOM isn't realistic given GTM capacity.

Fix: Ground SOM in GTM constraints (sales capacity, marketing budget, conversion rates).


References

Related Skills

  • skills/positioning-statement/SKILL.md — TAM/SAM/SOM informs "For [target]" segment size
  • skills/problem-statement/SKILL.md — Problem space defines the market
  • skills/recommendation-canvas/SKILL.md — Market sizing informs business outcome projections

Optional Helpers

  • skills/tam-sam-som-calculator/scripts/market-sizing.py — Deterministic TAM/SAM/SOM calculator (no network access)

External Frameworks

  • Steve Blank, The Four Steps to the Epiphany (2005) — Market sizing for startups
  • Lean Startup methodology — Validate market size with experiments, not just desk research

Data Sources (For Citations)

  • US: US Census Bureau, Bureau of Labor Statistics, IBISWorld, Statista
  • Europe: Eurostat, local statistical agencies
  • Global: World Bank, IMF, Gartner, Forrester

Dean's Work

  • TAM/SAM/SOM Prompt Generator (multi-turn adaptive market sizing)

Skill type: Interactive Suggested filename: tam-sam-som-calculator.md Suggested placement: /skills/interactive/ Dependencies: None (standalone interactive skill)

引导产品经理通过自适应问答构建用户故事地图,输出包含主干活动、用户任务和发布切片的二维结构。旨在将扁平待办事项转化为可视化的工作流框架,明确MVP范围并优化发布计划,避免上下文缺失。
需要创建用户故事地图 进行产品发布规划 梳理工作流与优先级 从扁平待办事项转为可视化视图
skills/user-story-mapping-workshop/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill user-story-mapping-workshop -g -y
SKILL.md
Frontmatter
{
    "name": "user-story-mapping-workshop",
    "type": "interactive",
    "intent": "Guide product managers through creating a user story map by asking adaptive questions about the system, users, workflow, and priorities—then generating a two-dimensional map with backbone (activities), user tasks, and release slices. Use this to move from flat backlogs to visual story maps that communicate the big picture, identify missing functionality, and enable meaningful release planning—avoiding \"context-free mulch\" where stories lose connection to the overall system narrative.",
    "description": "Run a user story mapping workshop with adaptive questions and a structured map output. Use when you need backbone activities, tasks, and release slices for a workflow.",
    "argument-hint": "[system or workflow]"
}

Purpose

Guide product managers through creating a user story map by asking adaptive questions about the system, users, workflow, and priorities—then generating a two-dimensional map with backbone (activities), user tasks, and release slices. Use this to move from flat backlogs to visual story maps that communicate the big picture, identify missing functionality, and enable meaningful release planning—avoiding "context-free mulch" where stories lose connection to the overall system narrative.

This is not a backlog generator—it's a visual communication framework that organizes work by user workflow (horizontal) and priority (vertical).

Input

Works best with: The system or workflow to map. Also useful: The primary users, workflow steps you already know, and what the map must decide (MVP scope, release plan).

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The workshop opens by asking about the system and its users (Q1), then proceeds per the facilitation protocol.

Example invocation: Run a story mapping workshop for our vendor onboarding portal — output should give us a first release slice.

Key Concepts

What is a User Story Map?

A story map (Jeff Patton) organizes user stories in two dimensions:

Horizontal axis (left to right): Activities arranged in narrative/workflow order—the sequence you'd use explaining the system to someone

Vertical axis (top to bottom): Priority within each activity, with the most essential tasks at the top

Structure:

Backbone (Activities across top)
↓
User Tasks (descending vertically by priority)
↓
Details/Acceptance Criteria (at the bottom)

Key Principles

The Backbone: Essential activities form the system's structural core—these aren't prioritized against each other; they're the narrative flow.

Walking Skeleton: The highest-priority tasks across all activities form the minimal viable product—the smallest end-to-end functionality.

Ribs: Supporting tasks descend vertically under each activity, indicating priority through placement.

Left-to-Right, Top-to-Bottom Build Strategy: Build incrementally across all major features rather than completing one feature fully before starting another.

Why This Works

  • Visual communication: Story maps remain displayed as information radiators, maintaining focus on the big picture
  • Narrative structure: Organizes by user workflow, not technical architecture
  • Release planning: Horizontal slices reveal MVPs and incremental releases
  • Gap identification: Reveals missing functionality that flat backlogs obscure

Anti-Patterns (What This Is NOT)

  • Not a Gantt chart: Story maps show priority, not time estimates
  • Not technical architecture: Maps follow user workflow, not system layers (UI → API → DB)
  • Not a project plan: It's a discovery and communication tool, not a schedule

When to Use This

  • Starting a new product or major feature
  • Reframing an existing backlog (moving from flat list to visual map)
  • Aligning stakeholders on scope and priorities
  • Planning MVP or incremental releases

When NOT to Use This

  • Single-feature projects (story map overkill)
  • When backlog is already well-understood and prioritized
  • For technical refactoring work (no user workflow to map)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill asks up to 5 adaptive questions, offering 3-4 enumerated options at each step.

Use template.md for the facilitation agenda and outputs checklist.

Interaction pattern: Pair with skills/workshop-facilitation/SKILL.md when you want a one-step-at-a-time flow with numbered recommendations at decision points and quick-select options for regular questions. If the user asks for a single-shot output, skip the multi-turn facilitation.


Step 0: Gather Context (Before Questions)

Agent suggests:

Before we create your story map, let's gather context:

Product/Feature Context:

  • What system or feature are you mapping?
  • Product concept, PRD draft, or existing backlog
  • Website copy, positioning materials, or user flows
  • Existing user stories (if transitioning from flat backlog)

User Context:

  • Target personas or user segments
  • User research, interviews, or journey maps
  • Jobs-to-be-done or problem statements

You can paste this content directly, or describe the system briefly.


Question 1: Define Scope

Agent asks: "What are you mapping? (What's the scope?)"

Offer 4 enumerated options:

  1. Entire product — "Full end-to-end system from discovery to completion" (Common for new products or full rewrites)
  2. Major feature area — "Specific workflow within a larger product (e.g., 'onboarding,' 'checkout,' 'reporting')" (Common for feature launches)
  3. User journey — "Specific user goal or job-to-be-done (e.g., 'hire a contractor,' 'file taxes')" (Common for JTBD-driven mapping)
  4. Redesign/refactor — "Existing product/feature being rebuilt or simplified" (Common for legacy system modernization)

Or describe your specific scope.

User response: [Selection or custom]


Question 2: Identify Users/Personas

Agent asks: "Who are the primary users for this map? (List personas or user segments.)"

Offer 4 enumerated options:

  1. Single persona — "One primary user type (e.g., 'small business owner')" (Simplifies mapping, good for MVP)
  2. Multiple personas, shared workflow — "Different user types, same core activities (e.g., 'buyer' and 'seller' both browse listings)" (Common for marketplaces)
  3. Multiple personas, different workflows — "Different user types with distinct workflows (e.g., 'admin' vs. 'end user')" (Requires separate maps or swim lanes)
  4. Roles within organization — "Different job functions (e.g., 'PM,' 'designer,' 'engineer')" (Common for internal tools)

Or describe your users.

Adaptation: Use personas from context provided in Step 0 (proto-personas, JTBD, etc.)

User response: [Selection or custom]


Question 3: Generate Backbone (Activities)

Agent says: "Let's build the backbone—the narrative flow of activities users perform to accomplish their goal."

Agent generates 5-8 activities based on scope (Q1) and users (Q2), arranged left-to-right in workflow order.

Example (if Scope = "E-commerce checkout"):

Backbone Activities (left to right):

1. Browse Products
2. Add to Cart
3. Review Cart
4. Enter Shipping Info
5. Enter Payment Info
6. Confirm Order
7. Receive Confirmation

Agent asks: "Does this backbone capture the full workflow? Should we add, remove, or reorder activities?"

User response: [Approve, modify, or add custom activities]


Question 4: Generate User Tasks (Under Each Activity)

Agent says: "Now let's add user tasks under each activity, organized by priority (top = must-have, bottom = nice-to-have)."

Agent generates 3-5 user tasks per activity, arranged vertically by priority.

Example (for Activity 2: "Add to Cart"):

Add to Cart (Activity)
├─ Add single item to cart (must-have, walking skeleton)
├─ Adjust quantity (must-have)
├─ Add multiple items at once (should-have)
├─ Save item for later (nice-to-have)
└─ Add gift wrapping (nice-to-have)

Agent repeats for all backbone activities, showing the full map.

Agent asks: "Does this capture the key tasks? Are priorities correct (top = MVP, bottom = later releases)?"

User response: [Approve, modify, or add custom tasks]


Question 5: Identify Release Slices (Walking Skeleton + Increments)

Agent says: "Let's define release slices by drawing horizontal lines across the map."

Agent generates 3 release slices:

Release 1 (Walking Skeleton): Top-priority tasks across all activities—minimal end-to-end functionality

Release 2 (Next Increment): Second-priority tasks that enhance the core workflow

Release 3 (Polish/Expansion): Third-priority tasks (nice-to-haves, edge cases, optimizations)

Example:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 1 (Walking Skeleton):
- Browse products (basic list view)
- Add single item to cart
- Review cart (line items + total)
- Enter shipping info (name, address)
- Enter payment info (credit card only)
- Confirm order (basic confirmation)
- Receive email confirmation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 2 (Enhanced):
- Product filtering/search
- Adjust quantity in cart
- Save for later
- Multiple shipping options
- Multiple payment methods
- Order tracking link
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 3 (Polish):
- Product recommendations
- Guest checkout
- Gift wrapping
- Promo codes
- Advanced payment options
- Post-purchase surveys
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Agent asks: "Do these release slices make sense? Should we adjust scope or priorities?"

User response: [Approve or modify]


Output: User Story Map

After completing the flow, the agent outputs:

# User Story Map: [Scope from Q1]

**Users:** [From Q2]
**Date:** [Today's date]

---

## Backbone (Activities)

[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5] → [Activity 6]

---

## Full Story Map

### [Activity 1: Name]
- **[Task 1.1]** — Must-have (Release 1)
- **[Task 1.2]** — Should-have (Release 2)
- **[Task 1.3]** — Nice-to-have (Release 3)

### [Activity 2: Name]
- **[Task 2.1]** — Must-have (Release 1)
- **[Task 2.2]** — Should-have (Release 2)
- **[Task 2.3]** — Nice-to-have (Release 3)

[...repeat for all activities...]

---

## Release Slices

### Release 1: Walking Skeleton (MVP)
**Goal:** Minimal end-to-end functionality

**Stories:**
- [Task 1.1] — [Activity 1]
- [Task 2.1] — [Activity 2]
- [Task 3.1] — [Activity 3]
- [Task 4.1] — [Activity 4]
- [Task 5.1] — [Activity 5]
- [Task 6.1] — [Activity 6]

**Why this is the walking skeleton:** Delivers complete workflow with simplest version of each activity.

---

### Release 2: Enhanced Functionality
**Goal:** Improve core workflow with priority enhancements

**Stories:**
- [Task 1.2] — [Activity 1]
- [Task 2.2] — [Activity 2]
- [Task 3.2] — [Activity 3]
[...]

---

### Release 3: Polish & Expansion
**Goal:** Nice-to-haves, edge cases, optimizations

**Stories:**
- [Task 1.3] — [Activity 1]
- [Task 2.3] — [Activity 2]
[...]

---

## Next Steps

1. **Refine stories:** Use `skills/user-story/SKILL.md` to write detailed stories with acceptance criteria
2. **Estimate effort:** Score stories (story points, t-shirt sizes)
3. **Validate with stakeholders:** Walk through map left-to-right, confirm priorities
4. **Display map:** Print/post as information radiator for ongoing reference

---

**Ready to write user stories? Let me know if you'd like to refine the map or break down specific stories.**

Examples

Example 1: Good Story Map (E-commerce Checkout)

Q1 Response: "Major feature area — E-commerce checkout workflow"

Q2 Response: "Single persona — Online shopper"

Q3 - Backbone Generated:

Browse → Add to Cart → Review Cart → Enter Shipping → Enter Payment → Confirm → Receive Confirmation

Q4 - User Tasks Generated:

Browse Products
├─ View product list (R1)
├─ Search/filter (R2)
└─ Product recommendations (R3)

Add to Cart
├─ Add single item (R1)
├─ Adjust quantity (R2)
└─ Save for later (R3)

Review Cart
├─ View line items + total (R1)
├─ Apply promo code (R2)
└─ Estimate shipping cost (R3)

[...etc...]

Q5 - Release Slices:

  • Release 1: Walking skeleton—basic flow with no extras
  • Release 2: Search, quantity adjustment, promo codes
  • Release 3: Recommendations, guest checkout, gift options

Why this works:

  • Backbone follows user narrative (not technical layers)
  • Walking skeleton delivers end-to-end value
  • Incremental releases add sophistication without breaking core flow

Example 2: Bad Story Map (Technical Layers)

Backbone (WRONG):

UI Layer → API Layer → Database Layer → Deployment

Why this fails:

  • Not user-centric (users don't care about technical architecture)
  • Can't deliver end-to-end value incrementally
  • Waterfall thinking disguised as story mapping

Fix:

  • Map by user workflow: "Sign Up → Configure Settings → Invite Team → Start Project"
  • Each release delivers full workflow, not a single layer

Common Pitfalls

Pitfall 1: Flat Backlog in Disguise

Symptom: Story map is just a vertical list, no horizontal narrative

Consequence: Loses communication benefit; still "context-free mulch"

Fix: Force horizontal structure—activities across top, tasks descending vertically


Pitfall 2: Technical Architecture as Backbone

Symptom: Backbone = "Frontend → Backend → Database"

Consequence: Not user-centric, can't deliver value incrementally

Fix: Backbone should follow user workflow, not system layers


Pitfall 3: Feature-Complete Waterfall

Symptom: Release 1 = "Build Activity 1 fully," Release 2 = "Build Activity 2 fully"

Consequence: No end-to-end value until all activities complete

Fix: Walking skeleton = thin slice across ALL activities, incrementally enhanced


Pitfall 4: Too Much Detail Too Soon

Symptom: Trying to map every edge case and acceptance criterion upfront

Consequence: Analysis paralysis, lost big picture

Fix: Start with backbone + high-level tasks, refine later


Pitfall 5: Map Hidden in a Tool

Symptom: Story map lives in Jira/Miro, never displayed

Consequence: Loses value as information radiator

Fix: Print/post map physically; make it visible to team daily


References

Related Skills

  • skills/user-story-mapping/SKILL.md — Component skill with story mapping template
  • skills/user-story/SKILL.md — Converts map tasks into detailed user stories
  • skills/proto-persona/SKILL.md — Defines users for mapping
  • skills/jobs-to-be-done/SKILL.md — Informs backbone activities

External Frameworks

  • Jeff Patton, User Story Mapping (2014) — Origin of story mapping framework
  • Jeff Patton, "The New User Story Backlog is a Map" (blog) — Explains backbone concept

Dean's Work

  • [If Dean has story mapping resources, link here]

Provenance

  • Derived from skills/user-story/SKILL.md, skills/user-story-splitting/SKILL.md, and skills/user-story-mapping/SKILL.md.

Skill type: Interactive Suggested filename: user-story-mapping-workshop.md Suggested placement: /skills/interactive/ Dependencies: Uses skills/user-story-mapping/SKILL.md, skills/user-story/SKILL.md, skills/proto-persona/SKILL.md

基于Jeff Patton框架创建用户故事地图,将用户旅程分解为活动、步骤和任务。用于构建产品、设计与工程团队的共识,按用户工作流优先排序功能,识别体验缺口,并规划MVP及后续发布版本。
需要规划工作流或MVP时 围绕用户旅程梳理产品待办事项时 希望建立跨团队对用户体验的共同理解时
skills/user-story-mapping/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill user-story-mapping -g -y
SKILL.md
Frontmatter
{
    "name": "user-story-mapping",
    "type": "component",
    "intent": "Visualize the user journey by creating a hierarchical map that breaks down high-level activities into steps and tasks, organized left-to-right as a narrative flow. Use this to build shared understanding across product, design, and engineering, prioritize features based on user workflows, and identify gaps or opportunities in the user experience.",
    "description": "Create a user story map that lays out activities, steps, tasks, and release slices. Use when planning a workflow, backlog, or MVP around the user journey.",
    "argument-hint": "[product or workflow]"
}

Purpose

Visualize the user journey by creating a hierarchical map that breaks down high-level activities into steps and tasks, organized left-to-right as a narrative flow. Use this to build shared understanding across product, design, and engineering, prioritize features based on user workflows, and identify gaps or opportunities in the user experience.

This is not a backlog—it's a strategic artifact that shows how users accomplish their goals, which then informs what to build.

Input

Works best with: The product or user workflow being mapped. Also useful: The primary user, the end-to-end narrative as you understand it, existing backlog items to place, and release goals.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks whose journey you're mapping and what they're trying to get done, then builds backbone → tasks → slices.

Example invocation: Story map for our expense-reporting flow, from receipt capture to reimbursement, with an MVP slice for the pilot.

Key Concepts

The Jeff Patton Story Mapping Framework

Invented by Jeff Patton, story mapping organizes work into a 2D structure:

Horizontal axis (left-to-right): User journey over time

  • Backbone: High-level activities the user performs
  • Steps: Specific actions within each activity
  • Tasks: Detailed work required to complete each step

Vertical axis (top-to-bottom): Priority and releases

  • Top rows: Essential tasks (MVP / Release 1)
  • Lower rows: Nice-to-have tasks (Future releases)

Story Map Structure

Segment → Persona → Narrative (User's goal)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5]
     ↓              ↓              ↓              ↓              ↓
  [Step 1.1]     [Step 2.1]     [Step 3.1]     [Step 4.1]     [Step 5.1]
  [Step 1.2]     [Step 2.2]     [Step 3.2]     [Step 4.2]     [Step 5.2]
  [Step 1.3]     [Step 2.3]     [Step 3.3]     [Step 4.3]     [Step 5.3]
     ↓              ↓              ↓              ↓              ↓
  [Task 1.1.1]   [Task 2.1.1]   [Task 3.1.1]   [Task 4.1.1]   [Task 5.1.1]
  [Task 1.1.2]   [Task 2.1.2]   [Task 3.1.2]   [Task 4.1.2]   [Task 5.1.2]
  [Task 1.1.3]   [Task 2.1.3]   [Task 3.1.3]   [Task 4.1.3]   [Task 5.1.3]
  ...            ...            ...            ...            ...

Why This Works

  • User-centric: Organizes work around user goals, not engineering modules
  • Shared understanding: Product, design, engineering all see the same journey
  • Prioritization clarity: Top tasks = MVP, lower tasks = future iterations
  • Gap identification: Missing steps or tasks become obvious
  • Release planning: Draw horizontal "release lines" to define scope

Anti-Patterns (What This Is NOT)

  • Not a Gantt chart: This isn't project management—it's user journey visualization
  • Not a feature list: Activities aren't features—they're user behaviors
  • Not static: Story maps evolve as you learn more about users

When to Use This

  • Kicking off a new product or major feature
  • Aligning stakeholders on user workflow
  • Prioritizing backlog based on user needs
  • Identifying MVP vs. future releases
  • Onboarding new team members to the product vision

When NOT to Use This

  • For trivial features (don't map what you already understand)
  • When user workflows are constantly changing (map stabilizes workflows)
  • As a replacement for user stories (the map informs stories, doesn't replace them)

Application

Step 1: Define the Context

Use template.md for the full fill-in structure.

Segment

Who are you building for?

### Segment:
- [Specify the target segment, e.g., "Small business owners using DIY accounting software"]

Quality checks:

  • Specific: Not "users" but "enterprise IT admins" or "freelance designers"

Persona

Provide details about the persona within this segment (reference skills/proto-persona/SKILL.md).

### Persona:
- [Describe the persona: demographics, behaviors, pains, goals]

Example:

  • "Sarah, 35-year-old freelance graphic designer, manages 5-10 client projects at once, struggles with invoicing and payment tracking, wants to spend less time on admin and more time designing"

Step 2: Define the Narrative

What is the user trying to accomplish? Frame this as a Jobs-to-be-Done statement (reference skills/jobs-to-be-done/SKILL.md).

### Narrative:
- [Concise narrative of the persona's objective, e.g., "Complete a client project from kickoff to final payment"]

Quality checks:

  • Outcome-focused: Not "use the product" but "deliver a client project on time and get paid"
  • One sentence: If it takes more than one sentence, the scope may be too broad

Step 3: Identify Activities (Backbone)

List 3-5 high-level activities the persona engages in to fulfill the narrative. These form the backbone of your map.

### Activities:
1. [Activity 1, e.g., "Negotiate project scope and pricing"]
2. [Activity 2, e.g., "Execute design work"]
3. [Activity 3, e.g., "Deliver final assets to client"]
4. [Activity 4, e.g., "Send invoice and receive payment"]
5. [Activity 5, optional]

Quality checks:

  • Sequential: Activities happen in order (left-to-right)
  • User actions: Describe what the user does, not what the product provides
  • 3-5 activities: Too few = oversimplified, too many = overwhelming

Step 4: Break Activities into Steps

For each activity, list 3-5 steps that detail how the activity is carried out.

### Steps:

**For Activity 1: [Activity Name]**
- Step 1: [Detail step 1, e.g., "Review client brief"]
- Step 2: [Detail step 2, e.g., "Draft project proposal"]
- Step 3: [Detail step 3, e.g., "Negotiate timeline and budget"]
- Step 4: [Optional step 4]
- Step 5: [Optional step 5]

**For Activity 2: [Activity Name]**
- Step 1: [Detail step 1]
- Step 2: [Detail step 2]
...

Quality checks:

  • Actionable: Each step is something the user does
  • Observable: You could watch someone perform this step
  • Logical sequence: Steps follow a natural order

Step 5: Break Steps into Tasks

For each step, list 5-7 tasks that must be completed.

### Tasks:

**For Activity 1, Step 1: [Step Name]**
- Task 1: [Detail task 1, e.g., "Read client brief document"]
- Task 2: [Detail task 2, e.g., "Identify key deliverables"]
- Task 3: [Detail task 3, e.g., "Note budget constraints"]
- Task 4: [Detail task 4, e.g., "Clarify timeline expectations"]
- Task 5: [Detail task 5, e.g., "List open questions for client"]
- Task 6: [Optional task 6]
- Task 7: [Optional task 7]

**For Activity 1, Step 2: [Step Name]**
- Task 1: [Detail task 1]
...

Quality checks:

  • Granular: Tasks are small, specific actions
  • User-facing or behind-the-scenes: Include both (e.g., "Send email" and "Receive confirmation")
  • Prioritizable: You'll prioritize tasks vertically (top = essential, bottom = nice-to-have)

Step 6: Prioritize Vertically

Arrange tasks top-to-bottom by priority:

  • Top rows: MVP / Release 1 (must-have)
  • Middle rows: Release 2 (important but not critical)
  • Bottom rows: Future / Nice-to-have

Draw horizontal "release lines" to demarcate scope.


Step 7: Identify Gaps and Opportunities

Review the map and ask:

  • Are there missing steps or tasks?
  • Are there pain points we're not addressing?
  • Are there opportunities to delight users?
  • Do all activities flow logically?

Examples

See examples/sample.md for a full story map example.


Common Pitfalls

Pitfall 1: Activities Are Features, Not User Behaviors

Symptom: "Activity 1: Use the dashboard. Activity 2: Generate reports."

Consequence: You've mapped the product, not the user journey.

Fix: Reframe as user actions: "Activity 1: Monitor project progress. Activity 2: Summarize work for stakeholders."


Pitfall 2: Too Many Activities

Symptom: 10+ activities across the backbone

Consequence: Map becomes overwhelming and loses focus.

Fix: Consolidate. If you have 10 activities, you're likely mixing activities with steps. Aim for 3-5 high-level activities.


Pitfall 3: Tasks Are Too Vague

Symptom: "Task 1: Do the thing"

Consequence: Can't prioritize or estimate vague tasks.

Fix: Be specific: "Task 1: Enter client email address in the 'Bill To' field."


Pitfall 4: Ignoring Vertical Prioritization

Symptom: All tasks at the same level—no MVP vs. future releases defined

Consequence: No clarity on what to build first.

Fix: Explicitly prioritize. Draw release lines. Force hard choices about what's MVP.


Pitfall 5: Mapping in Isolation

Symptom: PM creates the map alone, then presents it to the team

Consequence: No shared ownership or understanding.

Fix: Map collaboratively. Run a story mapping workshop with product, design, and engineering.


References

Related Skills

  • skills/proto-persona/SKILL.md — Defines the persona for the story map
  • skills/jobs-to-be-done/SKILL.md — Informs the narrative and activities
  • skills/user-story/SKILL.md — Tasks from the map become user stories
  • skills/problem-statement/SKILL.md — Problem statement frames the narrative

External Frameworks

  • Jeff Patton, User Story Mapping (2014) — Origin of the story mapping technique
  • Teresa Torres, Continuous Discovery Habits (2021) — Opportunity solution trees (complementary to story maps)

Dean's Work

  • User Story Mapping Prompt (adapted from Jeff Patton's methodology)

Provenance

  • Adapted from prompts/user-story-mapping.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: user-story-mapping.md Suggested placement: /skills/components/ Dependencies: References skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md, skills/user-story/SKILL.md, skills/problem-statement/SKILL.md

将大型用户故事或史诗拆分为可独立交付的小故事。基于8种系统模式,确保保留用户价值并降低复杂度,适用于敏捷开发中估算困难、无法在单个冲刺内完成的工作。
用户故事或史诗过大,无法在单个冲刺内完成 需求难以准确估算规模 无法独立发布或测试 验收标准包含多个条件
skills/user-story-splitting/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill user-story-splitting -g -y
SKILL.md
Frontmatter
{
    "name": "user-story-splitting",
    "type": "component",
    "intent": "Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.",
    "description": "Break a large story or epic into smaller deliverable stories using proven split patterns. Use when backlog items are too big for estimation, sequencing, or independent release.",
    "argument-hint": "[story or epic to split]"
}

Purpose

Break down large user stories, epics, or features into smaller, independently deliverable stories using systematic splitting patterns. Use this to make work more manageable, reduce risk, enable faster feedback cycles, and maintain flow in agile development. This skill applies to user stories, epics, and any work that's too large to complete in a single sprint.

This is not arbitrary slicing—it's strategic decomposition that preserves user value while reducing complexity.

Input

Works best with: The story or epic that's too big — paste it as written. Also useful: Why it's too big (can't estimate, can't finish in a sprint, can't release independently) and your team's sizing ceiling.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks for the story text, then walks the split patterns against it.

Example invocation: Split this: 'As an admin, I can bulk-import users from CSV, Excel, or our HR system with field mapping and error handling.'

Key Concepts

The Story Splitting Framework

Based on Richard Lawrence and Peter Green's "Humanizing Work Guide to Splitting User Stories," the framework provides 8 systematic patterns for splitting work:

  1. Workflow steps: Split along sequential steps in a user's journey
  2. Business rule variations: Split by different rule scenarios (permissions, calculations, etc.)
  3. Data variations: Split by different data types or inputs
  4. Acceptance criteria complexity: Split when multiple "When" or "Then" statements exist
  5. Major effort: Split by technical milestones or implementation phases
  6. External dependencies: Split along dependency boundaries (APIs, third parties, etc.)
  7. DevOps steps: Split by deployment or infrastructure requirements
  8. Tiny Acts of Discovery (TADs): When none of the above apply, use small experiments to unpack unknowns

Why Split Stories?

  • Faster feedback: Smaller stories ship sooner, allowing earlier validation
  • Reduced risk: Less to build = less that can go wrong
  • Better estimation: Small stories are easier to estimate accurately
  • Maintain flow: Keeps work moving through the sprint without bottlenecks
  • Testability: Smaller scope = easier to write and run tests

Anti-Patterns (What This Is NOT)

  • Not horizontal slicing: Don't split into "front-end story" and "back-end story" (each story should deliver user value)
  • Not task decomposition: Stories aren't tasks ("Set up database," "Write API")
  • Not arbitrary chopping: Don't split "Add user management" into "Add user" and "Management" (meaningless)

When to Use This

  • Story is too large for a single sprint
  • Multiple "When" or "Then" statements in acceptance criteria
  • Epic needs to be broken down into deliverable increments
  • Team can't reach consensus on story size or scope
  • Story has multiple personas or workflows bundled together

When NOT to Use This

  • Story is already small and well-scoped (don't over-split)
  • Splitting would create dependencies that slow delivery
  • The story is a technical task (use engineering task breakdown instead)

Application

Step 1: Identify the Original Story

Start with the story/epic/feature that needs splitting. Ensure it's written using the user story format (reference skills/user-story/SKILL.md or skills/epic-hypothesis/SKILL.md).

### Original Story:
[Story formatted with use case and acceptance criteria]

Step 2: Apply the Splitting Logic

Use template.md for the full fill-in structure and output format.

Work through the 8 splitting patterns in order. Stop when you find one that applies.

Pattern 1: Workflow Steps

Ask: Does this story contain multiple sequential steps?

Example:

  • Original: "As a user, I want to sign up, verify my email, and complete onboarding"
  • Split:
    1. "As a user, I want to sign up with email/password"
    2. "As a user, I want to verify my email via a confirmation link"
    3. "As a user, I want to complete onboarding by answering 3 profile questions"

Pattern 2: Business Rule Variations

Ask: Does this story have different rules for different scenarios?

Example:

  • Original: "As a user, I want to apply discounts (10% for members, 20% for VIPs, 5% for first-time buyers)"
  • Split:
    1. "As a member, I want to apply a 10% discount at checkout"
    2. "As a VIP, I want to apply a 20% discount at checkout"
    3. "As a first-time buyer, I want to apply a 5% discount at checkout"

Pattern 3: Data Variations

Ask: Does this story handle different types of data or inputs?

Example:

  • Original: "As a user, I want to upload files (images, PDFs, videos)"
  • Split:
    1. "As a user, I want to upload image files (JPG, PNG)"
    2. "As a user, I want to upload PDF documents"
    3. "As a user, I want to upload video files (MP4, MOV)"

Pattern 4: Acceptance Criteria Complexity

Ask: Does this story have multiple "When" or "Then" statements?

Example:

  • Original: "As a user, I want to manage my cart"
    • When I add an item, Then it appears in my cart
    • When I remove an item, Then it disappears from my cart
    • When I update quantity, Then the cart total updates
  • Split:
    1. "As a user, I want to add items to my cart so I can purchase them later"
    2. "As a user, I want to remove items from my cart so I can change my mind"
    3. "As a user, I want to update item quantities so I can buy the right amount"

Note: This is the most common indicator that a story needs splitting. If you see multiple "When/Then" pairs, split along those boundaries.


Pattern 5: Major Effort

Ask: Does this story require significant technical work that can be delivered incrementally?

Example:

  • Original: "As a user, I want real-time collaboration on documents"
  • Split:
    1. "As a user, I want to see who else is viewing the document (read-only presence)"
    2. "As a user, I want to see live cursor positions of other editors"
    3. "As a user, I want to see live edits from other users in real-time"

Pattern 6: External Dependencies

Ask: Does this story depend on multiple external systems or APIs?

Example:

  • Original: "As a user, I want to log in with Google, Facebook, or Twitter"
  • Split:
    1. "As a user, I want to log in with Google OAuth"
    2. "As a user, I want to log in with Facebook OAuth"
    3. "As a user, I want to log in with Twitter OAuth"

Pattern 7: DevOps Steps

Ask: Does this story require complex deployment, infrastructure, or operational work?

Example:

  • Original: "As a user, I want to upload large files to cloud storage"
  • Split:
    1. "As a user, I want to upload small files (<10MB) to cloud storage"
    2. "As a user, I want to upload large files (10MB-1GB) with progress tracking"
    3. "As a user, I want to resume interrupted uploads"

Pattern 8: Tiny Acts of Discovery (TADs)

Ask: If none of the above apply, are there unknowns or assumptions that need unpacking?

Example:

  • Original: "As a user, I want AI-powered recommendations" (too vague, too many unknowns)
  • TADs:
    1. Prototype 3 recommendation algorithms and test with 10 users
    2. Define success criteria (click-through rate, user satisfaction)
    3. Build the simplest recommendation engine (collaborative filtering)
    4. Measure and iterate

Note: TADs aren't stories—they're experiments. Use them to de-risk and clarify before writing stories.


Step 3: Write the Split Stories

For each split, write a complete user story using the format from skills/user-story/SKILL.md:

### Split 1 using [Pattern Name]:

#### User Story [ID]:
- **Summary:** [Brief title]

**Use Case:**
- **As a** [persona]
- **I want to** [action]
- **so that** [outcome]

**Acceptance Criteria:**
- **Scenario:** [Description]
- **Given:** [Preconditions]
- **When:** [Action]
- **Then:** [Outcome]

Step 4: Validate the Splits

Ask these questions:

  1. Does each split deliver user value? (Not just "front-end done")
  2. Can each split be developed independently? (No hard dependencies)
  3. Can each split be tested independently? (Clear acceptance criteria)
  4. Is each split small enough for a sprint? (1-5 days of work)
  5. Do the splits, when combined, equal the original? (Nothing lost in translation)

If any answer is "no," revise.


Examples

See examples/sample.md for full splitting examples.

Mini example excerpt:

### Original Story:
As a team admin, I want to manage team members so that I can control access.

### Suggested Splits (Acceptance Criteria Complexity):
1. Invite new team members
2. Remove team members
3. Update team member roles

Common Pitfalls

Pitfall 1: Horizontal Slicing (Technical Layers)

Symptom: "Story 1: Build the API. Story 2: Build the UI."

Consequence: Neither story delivers user value independently.

Fix: Split vertically—each story should include front-end + back-end work to deliver a complete user-facing capability.


Pitfall 2: Over-Splitting

Symptom: "Story 1: Add button. Story 2: Wire button to API. Story 3: Display result."

Consequence: Creates unnecessary overhead and dependencies.

Fix: Only split when the story is too large. A 2-day story doesn't need splitting.


Pitfall 3: Meaningless Splits

Symptom: "Story 1: First half of feature. Story 2: Second half of feature."

Consequence: Arbitrary splits that don't map to user value or workflow.

Fix: Use one of the 8 splitting patterns—each split should have a clear rationale.


Pitfall 4: Creating Hard Dependencies

Symptom: "Story 2 can't start until Story 1 is 100% done, tested, and deployed."

Consequence: No parallelization, slows delivery.

Fix: Split in a way that allows independent development. If dependencies are unavoidable, prioritize Story 1.


Pitfall 5: Ignoring the "So That"

Symptom: Split stories have the same "so that" statement.

Consequence: You've split the action but not the outcome—likely a task decomposition, not a story split.

Fix: Ensure each split has a distinct user outcome. If not, reconsider the split pattern.


References

Related Skills

  • skills/user-story/SKILL.md — Format for writing the split stories
  • skills/epic-hypothesis/SKILL.md — Epics often need splitting before becoming stories
  • skills/jobs-to-be-done/SKILL.md — Helps identify meaningful splits along user jobs

External Frameworks

  • Richard Lawrence & Peter Green, The Humanizing Work Guide to Splitting User Stories — Origin of the 8 splitting patterns
  • Bill Wake, INVEST in Good Stories (2003) — Criteria for well-formed stories (Independent, Negotiable, Valuable, Estimable, Small, Testable)
  • Mike Cohn, User Stories Applied (2004) — Story decomposition techniques

Dean's Work

  • User Story Splitting Prompt Template (based on Humanizing Work framework)

Provenance

  • Adapted from prompts/user-story-splitting-prompt-template.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: user-story-splitting.md Suggested placement: /skills/components/ Dependencies: References skills/user-story/SKILL.md, skills/epic-hypothesis/SKILL.md Applies to: User stories, epics, and any work that's too large to complete in a single sprint

将用户需求转化为Mike Cohn格式的用户故事及Gherkin验收标准,聚焦用户价值与可测试性。适用于需求拆解、敏捷规划及产研沟通,确保开发工作具备明确目标和验证条件。
需要将模糊需求转化为开发任务 进行敏捷 backlog 梳理或 sprint 规划 为功能编写可测试的验收标准
skills/user-story/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill user-story -g -y
SKILL.md
Frontmatter
{
    "name": "user-story",
    "type": "component",
    "theme": "pm-artifacts",
    "intent": "Create clear, concise user stories that combine Mike Cohn's user story format with Gherkin-style acceptance criteria. Use this to translate user needs into actionable development work that focuses on outcomes, ensures shared understanding between product and engineering, and provides testable success criteria.",
    "best_for": [
        "Writing user stories with proper acceptance criteria",
        "Converting requirements into development-ready stories",
        "Establishing story quality standards across your team"
    ],
    "scenarios": [
        "I need to write a user story for a new notification system in our B2B SaaS app",
        "Convert this PRD requirement into a properly formatted user story with Gherkin acceptance criteria"
    ],
    "description": "Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions.",
    "argument-hint": "[feature or user need]",
    "estimated_time": "5-10 min"
}

Purpose

Create clear, concise user stories that combine Mike Cohn's user story format with Gherkin-style acceptance criteria. Use this to translate user needs into actionable development work that focuses on outcomes, ensures shared understanding between product and engineering, and provides testable success criteria.

This is not a feature spec—it's a conversation starter that captures who benefits, what they're trying to do, why it matters, and how you'll know it works.

Input

Works best with: The feature or user need the story captures. Also useful: The user role, the outcome they want, and edge cases the acceptance criteria must cover.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks who the user is and what they're trying to accomplish before drafting story and Gherkin criteria.

Example invocation: Write user stories for password reset via SMS for our banking app — include the lockout edge case.

Key Concepts

The Mike Cohn + Gherkin Format

A user story combines:

Use Case (Mike Cohn format):

  • As a [user persona/role]
  • I want to [action to achieve outcome]
  • so that [desired outcome]

Acceptance Criteria (Gherkin format):

  • Scenario: [Brief description of the scenario]
  • Given: [Initial context or preconditions]
  • and Given: [Additional preconditions]
  • When: [Event that triggers the action]
  • Then: [Expected outcome]

Why This Structure Works

  • User-centric: Forces focus on who benefits and why
  • Outcome-focused: "So that" emphasizes the value delivered, not just the action
  • Testable: Gherkin acceptance criteria are concrete and verifiable
  • Conversational: Story is the opening for discussion, not the final spec
  • Shared language: Product, engineering, and QA all understand the format

Anti-Patterns (What This Is NOT)

  • Not a task: "As a developer, I want to refactor the database" (this is a tech task, not user value)
  • Not a feature list: "I want dashboards, reports, and analytics" (this is too big—needs splitting)
  • Not vague: "I want a better experience" (unmeasurable, no clear outcome)
  • Not a contract: Stories are placeholders for conversation, not locked-in specs

When to Use This

  • Translating user needs into development work
  • Backlog grooming and sprint planning
  • Communicating value to engineering and design
  • Ensuring testable acceptance criteria exist before development

When NOT to Use This

  • For pure technical debt or refactoring (use engineering tasks instead)
  • When stories are too large (split first—see skills/user-story-splitting/SKILL.md)
  • Before understanding the user problem (write a problem statement first)

Application

Step 1: Gather Context

Before writing a story, ensure you have:

  • User persona: Who is this for? (reference skills/proto-persona/SKILL.md)
  • Problem understanding: What need does this address? (reference skills/problem-statement/SKILL.md)
  • Desired outcome: What does success look like?
  • Constraints: Technical, time, or scope limitations

If missing context: Run discovery interviews or problem validation work first.


Optional Helper Script (Template Generator)

If you want a consistent Markdown stub, you can generate one from CLI inputs. This script is deterministic and does not fetch data or write files.

python3 scripts/user-story-template.py --persona \"trial user\" --action \"log in with Google\" --outcome \"access the app without creating a new password\"

Step 2: Write the Use Case

Use template.md for the full fill-in structure.

Fill in the template:

### User Story [ID]:

- **Summary:** [Brief, memorable title focused on value to the user]

#### Use Case:
- **As a** [user name if available, otherwise persona, otherwise role]
- **I want to** [action user takes to get to outcome]
- **so that** [desired outcome]

Quality checks:

  • "As a" specificity: Is this a specific persona (e.g., "trial user") or generic ("user")?
  • "I want to" clarity: Is this an action the user takes, or a feature you're building?
  • "So that" outcome: Does this explain the user's motivation? Or is it just restating the action?

Common mistakes:

  • ❌ "As a user, I want a login button, so that I can log in" (restating the action)
  • ✅ "As a trial user, I want to log in with Google, so that I can access the app without creating a new password"

Step 3: Write the Acceptance Criteria

Fill in the template:

#### Acceptance Criteria:

- **Scenario:** [Brief, human-readable scenario describing value]
- **Given:** [Initial context or precondition]
- **and Given:** [Additional context or preconditions]
- **and Given:** [Additional context as needed]
- **and Given:** [UI-focused context ensuring 'When' can happen]
- **and Given:** [Outcomes-focused context ensuring 'Then' is delivered]
- **When:** [Event that triggers the action—aligns with 'I want to']
- **Then:** [Expected outcome—aligns with 'so that']

Quality checks:

  • Multiple Givens are okay: Preconditions stack up (e.g., "Given I'm logged in" + "Given I have items in my cart")
  • Only one When: If you need multiple "When" statements, you likely have multiple stories—split them
  • Only one Then: If you need multiple "Then" statements, you likely have multiple stories—split them
  • Alignment: Does "When" match "I want to"? Does "Then" match "so that"?

Red flags:

  • Multiple Whens/Thens: Sign of scope creep—split the story (reference skills/user-story-splitting/SKILL.md)
  • Vague Thens: "Then I see improved performance" (unmeasurable—make it specific)

Step 4: Add a Summary

Write a short, memorable summary that captures the story's value:

- **Summary:** [Brief, human-readable title]

Examples:

  • ✅ "Enable Google login for trial users to reduce signup friction"
  • ✅ "Bulk delete items to save time for power users"
  • ❌ "Add delete button" (feature-centric, not value-centric)

Step 5: Validate and Refine

  • Read aloud to the team: Does everyone understand who, what, why?
  • Test acceptance criteria: Can QA write test cases from this?
  • Check for splitting: If the story feels too big, use skills/user-story-splitting/SKILL.md
  • Ensure testability: Can you prove "Then" happened?

Examples

See examples/sample.md for full examples (good, bad, and split-needed stories).

Mini example excerpt:

### User Story 042:

- **Summary:** Enable Google login for trial users to reduce signup friction

#### Use Case:
- **As a** trial user visiting the app for the first time
- **I want to** log in using my Google account
- **so that** I can access the app without creating and remembering a new password

#### Acceptance Criteria:
- **Scenario:** First-time trial user logs in via Google OAuth
- **Given:** I am on the login page
- **and Given:** I have a login account
- **When:** I click the "Sign in with Google" button and authorize the app
- **Then:** I am logged into the app and redirected to the onboarding flow

Common Pitfalls

Pitfall 1: Technical Tasks Disguised as User Stories

Symptom: "As a developer, I want to refactor the API, so that the code is cleaner"

Consequence: This is an engineering task, not a user story. No user value is delivered.

Fix: If there's no user outcome, it's not a user story—use an engineering task or tech debt ticket instead.


Pitfall 2: "As a User" (Too Generic)

Symptom: Every story starts with "As a user"

Consequence: No persona clarity. Different users have different needs.

Fix: Use specific personas: "As a trial user," "As a paid subscriber," "As an admin," etc. (reference skills/proto-persona/SKILL.md)


Pitfall 3: "So That" Restates "I Want To"

Symptom: "I want to click the save button, so that I can save my work"

Consequence: No insight into why the user cares. Just restating the action.

Fix: Dig into the motivation: "so that I don't lose my progress if the page crashes" (real outcome).


Pitfall 4: Multiple When/Then Statements

Symptom: Acceptance criteria with 5 "When" statements and 5 "Then" statements

Consequence: Story is too big. Likely multiple features bundled together.

Fix: Split the story using skills/user-story-splitting/SKILL.md. Each When/Then pair should be its own story (or at least evaluated for splitting).


Pitfall 5: Untestable Acceptance Criteria

Symptom: "Then the user has a better experience" or "Then it's faster"

Consequence: QA can't verify success. Ambiguous definition of "done."

Fix: Make it measurable: "Then the page loads in under 2 seconds" or "Then the user sees a success confirmation message."


References

Related Skills

  • skills/user-story-splitting/SKILL.md — How to break large stories into smaller ones
  • skills/proto-persona/SKILL.md — Defines the "As a [persona]" section
  • skills/problem-statement/SKILL.md — Stories should address validated problems
  • skills/epic-hypothesis/SKILL.md — Epics decompose into user stories

Optional Helpers

  • skills/user-story/scripts/user-story-template.py — Deterministic Markdown stub generator (no network access)

External Frameworks

  • Mike Cohn, User Stories Applied (2004) — Origin of the "As a / I want / so that" format
  • Gherkin (Cucumber) — "Given/When/Then" acceptance criteria format
  • INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable)

Dean's Work

  • [Link to relevant Dean Peters' Substack articles if applicable]

Provenance

  • Adapted from prompts/user-story-prompt-template.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: user-story.md Suggested placement: /skills/components/ Dependencies: References skills/proto-persona/SKILL.md, skills/problem-statement/SKILL.md Used by: skills/user-story-splitting/SKILL.md, skills/epic-hypothesis/SKILL.md

专为总监级及以上产品领导者设计,指导向VP或CPO转型。通过诊断当前阶段(准备、面试、入职、调整)并提供针对性教练,帮助应对战略模糊、职责扩展及组织管理等核心挑战。
寻求从总监晋升至VP或CPO的职业发展建议 准备高管级别的产品领导岗位面试 新任VP/CPO面临组织管理或战略转型难题 需要针对高阶产品领导力的实战辅导
skills/vp-cpo-readiness-advisor/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill vp-cpo-readiness-advisor -g -y
SKILL.md
Frontmatter
{
    "name": "vp-cpo-readiness-advisor",
    "type": "interactive",
    "theme": "career-leadership",
    "intent": "Guide Directors and senior product leaders through the specific challenges of the transition to VP or CPO using adaptive questions and targeted coaching. Diagnoses where you are in the journey and delivers practical, lived-experience coaching calibrated to your situation — not generic executive advice.",
    "best_for": [
        "Preparing for the Director-to-VP or VP-to-CPO transition",
        "Evaluating a VP or CPO role before you accept it",
        "Recalibrating when something isn't working in an executive product role"
    ],
    "scenarios": [
        "I'm a Director preparing for VP roles and want to understand what actually changes",
        "I have a CPO offer I'm evaluating — what are the right questions to ask the CEO?",
        "I've been a VP for 18 months and my executive peer relationships aren't working"
    ],
    "description": "Guide the transition to VP or CPO across preparing, interviewing, landing, and recalibrating. Use when executive product scope is changing fast.",
    "argument-hint": "[where you are in the transition]",
    "estimated_time": "15-20 min"
}

Purpose

Guide Directors and senior product leaders through the specific challenges of the transition to VP or CPO using adaptive questions and targeted coaching. Diagnoses where you are in the journey and delivers practical, lived-experience coaching calibrated to your situation — not generic executive advice.

The VP/CPO transition is not a continuation of the Director transition. The landscape changes. Strategy becomes largely unwritten. Your primary customer may shift. You stop using product language with executives. Constraints don't disappear — the Rubik's Cube just goes from 3×3 to 9×9. This advisor names what's actually hard at this level and what to do about it.

Input

Works best with: Where you are in the Director-to-VP/CPO journey: preparing, interviewing, newly landed, or recalibrating. Also useful: Company stage, whether you'd be (or are) the first product executive, and your relationship with the CEO.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The advisor opens by asking which of the four situations describes you, then branches.

Example invocation: I have a CPO final-round interview with a founder-CEO who has strong product opinions — help me prepare.

Key Concepts

The Three Ps Framework

At VP and CPO level, your accountability expands across three dimensions simultaneously:

  • Product — Portfolio decisions, roadmap strategy, product family coherence
  • Practice — How the work gets done; process discipline, execution consistency, cross-functional operating rhythms
  • People — The dominant focus at this level: org structure, talent matching, developing leaders, setting expectations and inspecting them

Most Directors are strong in Product and adequate in Practice. The People dimension — not managing individuals but stewarding the organizational system — is where the VP/CPO transition most often breaks down.


The Empowerment Myth

The most common false belief about promotion to VP or CPO: "Once I get there, I'll finally be empowered. I'll have the authority to do what I always knew needed to be done."

The reality: constraints don't disappear. They change shape. A PM's Rubik's Cube is 3×3. A Director's is 5×5. A VP's is 7×7. A CPO's is 9×9. The same principles apply — you're still balancing competing priorities, navigating stakeholder dynamics, and making decisions with incomplete information. The blast radius of each decision just gets exponentially larger.

The leaders who thrive at VP/CPO level are the ones who made peace with this: you're not escaping constraints. You're developing the capacity to navigate larger ones.


The VP → CPO Paradigm Shift

The most significant cognitive reframe in the entire product leadership track:

VP mindset: "What are we releasing? How does our product portfolio perform? What's the roadmap?" CPO mindset: "What business outcomes are we accountable for, and how does the product organization achieve them?"

Practical consequences of this shift:

  • Language changes deliberately. Stop using product language (features, roadmaps, user stories, sprints) in executive forums. Switch to business language (ROI, revenue, retention, margin, EBITDA). Reserve product vocabulary for conversations with your product team.
  • Your primary "customer" may shift. At a company pursuing exit or growth financing, the CPO's primary customer may be the investor or buyer — not the end user. The persona you optimize for depends on the business context.
  • Your team shifts. As CPO, your most important team is not the product organization. It's the executive staff — CEO, CFO, CRO, CMO. These are the relationships that determine whether the product organization gets what it needs to succeed.

Time Horizon Expansion

Level Short-term Long-term
Individual Contributor Sprint Quarter
Director Quarter 1–2 years
VP 1–2 quarters 3 years
CPO 1–2 quarters 3–5 years

One thing doesn't change: you still have to deliver every quarter. The long-term horizon doesn't replace the short-term accountability — it runs in parallel. "Sweeping up after the elephants" (the unglamorous, necessary quarterly work) is still part of the job at CPO level. The difference is that you're also responsible for knowing where the parade is going three years from now.


Alliance Building at Executive Level

At Director level, you manage down and influence laterally. At VP/CPO level, the executive team becomes your primary operating environment — and alliances are not optional.

Without them, you're a "dead man walking." Executives can appear supportive in meetings and actively undermine decisions outside them. Alliance building at this level means:

  • Weekly engagement with peer executives (CRO, CFO, CMO) — not annual roadmap reviews
  • Proactive communication about trade-offs: "You're not getting X this quarter because of Y, and here's why that's best for the business"
  • Bringing people along before decisions are announced, not after
  • Understanding each peer's real priorities, not just their stated ones

The Four Transition Situations

  1. Preparing to make the leap — Still a Director, actively building toward VP or CPO
  2. Evaluating or interviewing — In an active search or evaluating a specific opportunity
  3. Newly landed — Recently stepped into VP or CPO (first 6 months)
  4. Recalibrating — Been in the role for a while; something isn't working

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

  • Session heads-up + entry mode (Guided, Context dump, Best guess)
  • One-question turns with plain-language prompts
  • Progress labels (e.g., Context Q1/3)
  • Interruption handling and pause/resume behavior
  • Numbered recommendations at decision points
  • Quick-select numbered response options (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.


Application

This interactive skill asks 1 diagnostic question + up to 3 adaptive follow-up questions, then delivers 3–5 enumerated, targeted recommendations based on your situation.


Step 0: Session Start

Agent says:

Before we start, choose how to run this session:

  1. Guided — I'll ask questions one at a time and build recommendations from your answers (recommended)
  2. Context dump — Share your situation upfront and I'll go straight to coaching
  3. Best guess — Tell me nothing; I'll give you the highest-value advice for the most common situation (newly landed VP, 0–3 months in)

Question 1: Where Are You?

Agent asks (Q1/3):

"Where are you in the Director-to-VP/CPO journey?"

  1. Preparing to make the leap — Still a Director, building toward VP or CPO
  2. Evaluating or interviewing — In an active search, evaluating an opportunity, or approaching an offer decision
  3. Newly landed — Recently stepped into a VP or CPO role (first 6 months)
  4. Recalibrating — Been in the role for a while; something isn't working the way it should

Or describe your situation directly.


Branch 1: Preparing to Make the Leap

Question 1B (Q2/3):

Agent asks:

"Which of the Three Ps is your biggest development area right now?"

  1. Product — I'm confident in strategy and portfolio thinking but want to sharpen executive-level framing
  2. Practice — I struggle to build consistent execution discipline and cross-functional operating rhythms at scale
  3. People — I haven't yet had to assess org structure, manage talent mismatches, or develop leaders at scale
  4. All three feel thin — I'm early in building director-level credibility; VP still feels like a stretch

Question 1C (Q3/3):

Agent asks:

"What's your current vantage point on executive dynamics?"

  1. Limited exposure — I'm mostly operating below executive staff; the VP/CPO layer feels opaque
  2. Occasional exposure — I present to executives, attend some leadership meetings, but don't operate as a peer yet
  3. Growing exposure — I'm actively navigating exec dynamics, participating in leadership conversations, and starting to understand the alliance layer
  4. Close proximity — I work alongside VP/CPO regularly and have a clear picture of what the role actually demands

Branch 1 Recommendations:

Agent delivers (based on 1B + 1C):

Example output for 1B = People + 1C = Limited exposure:

"At VP/CPO level, People is the dimension that most often determines success or failure — and limited exposure to executive dynamics means you're preparing for two transitions simultaneously. Here's where to focus:

  1. Study the Three Ps through your current VP/CPO's lens — Observe what they spend time on. When they're pulled into a meeting, what's it about? When they make a hard call, which of the Three Ps is driving it? Ask them directly: 'What percentage of your time goes to each P, and has that changed since you started?' The answer will be instructive.

  2. Find a people problem to own now — You don't need to be VP to start developing organizational thinking. Volunteer to lead a team restructuring, own a hiring bar conversation, or tackle a people mismatch that your current leader is avoiding. The skill is built through reps, not study.

  3. Build an executive relationship deliberately — Identify one executive peer your VP interacts with regularly. Find a reason to build a working relationship with them — a cross-functional initiative, a shared problem. Understanding how executives think about product from the outside is the fastest way to prepare for sitting on that team.

  4. Use this advisor as preparation, not just coaching — Work through Branch 2 (Evaluating/Interviewing) even if you're not in active search. The CEO interview questions surface what you'll need to navigate. The preparation for that conversation is the preparation for the role.

Choose a number to go deeper, or describe what you want to work on."


Branch 2: Evaluating or Interviewing

Question 2B (Q2/3):

Agent asks:

"Where are you in the process?"

  1. Early exploration — Considering whether to pursue VP/CPO roles; haven't entered an active process yet
  2. Active interviews — In process with one or more organizations; preparing for rounds or a presentation
  3. Near offer / offer decision — Evaluating a specific role and deciding whether to take it

Question 2C (Q3/3):

Agent asks:

"What do you most want to work on for this stage?"

  1. Demonstrating executive-level thinking — How to show VP/CPO-caliber thinking in interviews vs. talking about Director-level work
  2. Evaluating the role before accepting — How to probe the organization, the CEO, and the constraints before saying yes
  3. Preparing for a strategy presentation or case — Many VP/CPO interviews include a 30/60/90-day plan or portfolio strategy presentation
  4. Practicing with the frameworks — Using the Three Ps, Empowerment Myth, and paradigm shift concepts to sharpen my own thinking and interview responses

Branch 2 Recommendations:

Agent delivers (based on 2B + 2C):

Example output for 2B = Near offer + 2C = Evaluating the role before accepting:

"At VP/CPO level, you are interviewing the organization as much as it's interviewing you. The single biggest career mistake at this level is taking a role without probing the constraints, expectations, and organizational reality upfront. Here's the framework:

  1. Run the five CEO interview questions before accepting — These questions are in skills/executive-onboarding-playbook/SKILL.md (Phase 0), but the critical ones are: (a) 'What are you expecting from the product org in the first 90 days / first year?' — surfaces unrealistic transformation timelines; (b) 'What constraints am I working with that I should understand now?' — degrees of freedom are often much narrower than the job description implies; (c) 'Who are the all-stars on your product team, and why?' — reveals the CEO's talent lens and biases. They're often wrong, but it tells you what you're walking into.

  2. Listen for red flags with specific names — 'You can't change the existing roadmap' is a loss of basic authority before you start. 'We need you to transform the culture in two quarters' sets you up to fail. 'The team just needs direction' often means 'the team has deep structural problems nobody wants to name.' If you hear these, probe further or walk away.

  3. Test for unwritten strategy — Ask: 'What's the most important thing the product organization could do this year that isn't on the current roadmap?' The answer tells you what the CEO really wants. It may have nothing to do with the written strategy.

  4. Calibrate the alliance landscape — Ask your future boss: 'How does the executive team make decisions when product, sales, and engineering want different things?' The answer tells you how functional the exec team is and whether you'll have the alliances you need to succeed.

  5. Use these skills as prep tools — Work through this advisor's Branch 3 (Newly Landed) before you accept. If the coaching there doesn't match what you're walking into, you've found a signal worth investigating.

Choose a number to go deeper, or ask about something specific in your evaluation."


Branch 3: Newly Landed

Question 3B (Q2/3):

Agent asks:

"What's your most pressing challenge right now?"

  1. Getting oriented without acting prematurely — I want to build understanding before I make changes but I'm feeling pressure to show results
  2. Executive team dynamics — I'm navigating alliances, competing priorities from peers, and organizational politics I wasn't fully prepared for
  3. People and org assessment — I've inherited a team and I'm not sure yet who's strong, who's in the wrong role, and what needs to change
  4. Surfacing unwritten strategy — I'm getting mixed signals about what leadership actually wants, and the written strategy doesn't match what I'm hearing

Question 3C (Q3/3):

Agent asks:

"Where are you in the first 90 days?"

  1. Month 1 — Still in full diagnostic mode
  2. Month 2 — Validating what I've learned, reality-checking with my boss
  3. Month 3 — Starting to act; feeling the pressure to make moves

Branch 3 Recommendations:

Agent delivers (based on 3B + 3C):

Example output for 3B = Executive team dynamics + 3C = Month 2:

"Month 2 is when executive dynamics become real — you have enough context to see the alliances and tensions, but not yet the standing to navigate them directly. Here's how to approach this phase:

  1. Map the alliances before you need them — Who has been in this organization the longest? Who is the CEO's trusted inner circle? Who came in around the same time you did? Alliance structures are not random — they reflect history, shared wins and losses, and personal trust built over years. Understanding the map is more important than judging it.

  2. Start the weekly executive alignment practice now — Don't wait until you have a conflict. Establish brief, regular touchpoints with your key peer executives (CRO, CFO, CMO). The agenda: 'Here's what product is focused on this month. Here's the trade-off I'm navigating. Here's what I need from you.' Weekly builds understanding; quarterly leads to surprises.

  3. Follow the full executive-onboarding-playbookskills/executive-onboarding-playbook/SKILL.md has the complete diagnostic process for Months 1–3. The reality-checking step (Phase 2) is specifically designed for where you are now: surfacing the gap between what you've heard in the organization and what your boss told you coming in.

  4. Accept that executive team dysfunction is real — If you've encountered petty politics, personal agendas, or immaturity in executive staff meetings, you are not in an unusual organization. This is how almost every executive team operates. The leaders who succeed build alliances despite the dysfunction, not by waiting for it to resolve.

Choose a number to go deeper, or describe what's most blocking you."


Branch 4: Recalibrating

Question 4B (Q2/3):

Agent asks:

"What's the core friction? Where does the role feel most broken right now?"

  1. Still operating at Director level — I'm in the product details too much; I haven't fully made the altitude and language shifts
  2. Executive relationships aren't working — I'm not getting the trust, visibility, or influence I need with the executive team
  3. My organization isn't performing — The people and practice dimensions are struggling; team capability and execution consistency are inconsistent
  4. I'm not sure what success looks like — I don't have a clear enough picture of what the business actually needs from the product org

Question 4C (Q3/3):

Agent asks:

"How long have you been in this VP or CPO role?"

  1. Under 1 year — Still in the transition period; may need to accelerate the diagnostic work
  2. 1–2 years — Past the transition window; these feel like persistent patterns
  3. 2+ years — Established in the role; this has become a structural issue

Branch 4 Recommendations:

Agent delivers (based on 4B + 4C):

Example output for 4B = Executive relationships + 4C = 1-2 years:

"Executive relationship dysfunction after 12+ months is a structural problem, not a situational one. It doesn't resolve on its own. Here's the diagnosis and the path forward:

  1. Name which alliance is broken — 'The executive team' is too broad. Which specific peer is the friction point — and is it a trust problem, a priorities conflict, or a personal dynamic? The corrective action is different for each. A trust problem requires transparency and consistency over time. A priorities conflict requires a structured trade-off conversation. A personal dynamic may require your boss's involvement.

  2. Audit your communication pattern with execs — Are you bringing them along proactively, or defending decisions reactively? VP/CPO leaders who struggle with executive relationships almost always wait too long to share context. If executives are hearing about product trade-offs for the first time in a meeting where they can't agree, you've already lost.

  3. Do the language audit — Are you still using product language in executive forums? Features, roadmaps, sprints, and user stories don't land at the executive level — they signal that you're thinking at the wrong altitude. Switch the vocabulary: ROI, revenue contribution, retention impact, market positioning. Same decisions, different language. This shift alone changes how peers perceive product leadership.

  4. Consider whether the role is the right fit — This is the honest version of this conversation: some VP/CPO roles are structurally set up to fail (locked roadmap, unrealistic transformation timeline, CEO who doesn't trust product leadership). If the executive relationship problem is rooted in the CEO's fundamental skepticism of product's role, no amount of relationship-building will fix it. Diagnose whether the issue is yours to solve or the organization's.

  5. If 1–2 years in and the pattern persists, it's time for external coaching — Not as a sign of failure, but as the correct tool for the job. The VP/CPO transition is one of the hardest in the profession. Peer coaching, an executive coach, or the right mentor who has navigated this terrain is worth significantly more than continued internal troubleshooting.

Choose a number to go deeper, or tell me what you want to work on next."


Examples

See examples/conversation-flow.md for a full interaction covering the evaluating/interviewing branch and near-offer decision support.

Example: Director Preparing, Thin on People Dimension

Q1: "1 — Preparing to make the leap" Q2: "3 — People" Q3: "1 — Limited executive exposure"

Agent output: How to study the Three Ps through observation, where to find people problems to own now, how to build one executive relationship deliberately, and how to use this advisor's interviewing branch as preparation.


Example: Newly Landed VP, Unwritten Strategy Gap

Q1: "3 — Newly landed" Q2: "4 — Surfacing unwritten strategy" Q3: "2 — Month 2"

Agent output: Pointer to the executive-onboarding-playbook Phase 2 reality-check technique, specific indirect questions for surfacing tribal knowledge, and the weekly executive alignment practice to start now.


Example: Near-Offer CPO, Evaluating Whether to Accept

Q1: "2 — Evaluating or interviewing" Q2: "3 — Near offer / offer decision" Q3: "2 — Evaluating the role before accepting"

Agent output: Five CEO interview questions, named red flags, how to test for unwritten strategy, how to calibrate the alliance landscape before day one.


Common Pitfalls

Pitfall 1: Conflating VP and CPO Transitions

Symptom: Treating the Director → VP and VP → CPO transitions as the same move at different scales

Consequence: The VP → CPO shift is a qualitative change (product-first to business-first), not just a scope expansion. Applying VP thinking to CPO problems produces the wrong answers.

Fix: Explicitly identify which transition you're navigating. The language shift alone is a signal: if you're still leading with product language in executive forums as CPO, you haven't made the transition.


Pitfall 2: Waiting for Empowerment

Symptom: Taking the VP/CPO role expecting to finally have the authority to do what you've always known was right

Consequence: The Empowerment Myth sets you up for disillusionment. Constraints persist; they just get bigger.

Fix: Reframe before you arrive: "My job is not to be empowered. My job is to develop the capacity to navigate larger constraints than I've ever faced."


Pitfall 3: Neglecting the Alliance Layer

Symptom: Focusing primarily on managing your direct reports and product organization; treating exec team relationships as secondary

Consequence: Without executive alliances, every significant product decision can be undermined by a peer who wasn't brought along.

Fix: Your most important team at VP/CPO level is the executive staff, not the product org. Invest in those relationships at least as deliberately as you invest in developing your team.


Pitfall 4: Misidentifying Your Situation

Symptom: Selecting "preparing" when you're actually recalibrating a role that isn't working

Consequence: You get coaching for a transition you've already made, not for the problem you're actually in.

Fix: Be honest about the gap between where you aspire to be and where you actually are. The recalibrating branch will be more useful if the role has already landed badly.


References

Related Skills

  • skills/executive-onboarding-playbook/SKILL.md — The 30-60-90 diagnostic playbook; essential reading for Branch 3 (Newly Landed) and Branch 2 (Evaluating)
  • skills/altitude-horizon-framework/SKILL.md — The Director-level mental model; foundational context for understanding where the VP/CPO transition begins
  • skills/director-readiness-advisor/SKILL.md — The Director-level transition equivalent; useful if you're coaching a Director report through their own transition
  • skills/workshop-facilitation/SKILL.md — Facilitation protocol for this interactive skill

Source Material

External Frameworks

  • Marty Cagan, Empowered — Organizational dynamics and product leadership at scale
  • Patrick Lencioni, Five Dysfunctions of a Team — Diagnostic for executive team dysfunction
  • Michael Watkins, The First 90 Days — Structured approach to senior leadership transitions
提供交互式技能的标准引导协议,支持单步多轮对话、进度追踪及自适应推荐。适用于需要一致节奏和选项管理的场景,如工作坊或回顾会议,支持多种输入模式并处理中断。
需要引导式交互的工作坊或回顾会议 要求分步提问、进度可见且具备自适应推荐能力的多轮对话任务
skills/workshop-facilitation/SKILL.md
npx skills add deanpeters/Product-Manager-Skills --skill workshop-facilitation -g -y
SKILL.md
Frontmatter
{
    "name": "workshop-facilitation",
    "type": "interactive",
    "theme": "workshops-facilitation",
    "intent": "Provide the canonical facilitation pattern for interactive skills: one step at a time, with clear progress, adaptive recommendations at decision points, and predictable interruption handling.",
    "best_for": [
        "Adding structured facilitation to any PM workshop or guided session",
        "Running interactive sessions with numbered recommendations and progress tracking",
        "Ensuring your workshops stay on track and end with actionable choices"
    ],
    "scenarios": [
        "I want to run a structured positioning workshop with my product team — set up the facilitation protocol",
        "Help me facilitate a discovery sprint kickoff with clear questions, options, and progress labels"
    ],
    "description": "Facilitate workshop sessions in a one-step, multi-turn flow. Use when an interactive skill needs consistent pacing, options, and progress tracking.",
    "estimated_time": "varies by workshop"
}

Purpose

Provide the canonical facilitation pattern for interactive skills: one step at a time, with clear progress, adaptive recommendations at decision points, and predictable interruption handling.

Input

Nothing required — this skill defines the facilitation protocol other interactive skills follow. Also useful: If invoked standalone, name the session you want facilitated and any context for it; that context carries into the session as answers already given.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. When another skill references this protocol, that skill's Input section governs what to provide.

Example invocation: Facilitate a 45-minute retro on our failed beta launch using this protocol.

Key Concepts

  • One-step-at-a-time: Ask a single targeted question per turn.
  • Session heads-up + entry mode: Start by setting expectations and offering Guided, Context dump, or Best guess mode.
  • Progress visibility: Show user-facing progress labels like Context Qx/8 and Scoring Qx/5.
  • Decision-point recommendations: Use enumerated options only when a choice is needed, not after every answer.
  • Quick-select response options: For regular context/scoring questions, provide concise numbered answer options plus Other (specify) when useful.
  • Flexible selection parsing: Accept #1, 1, 1 and 3, 1,3, or custom text, then synthesize multi-select choices.
  • Context-aware progression: Build on previous answers and avoid re-asking resolved questions.
  • Interruption-safe flow: Answer meta questions directly (for example, "how many left?"), restate status, then resume.
  • Fast path: If the user requests a single-shot output, skip multi-turn facilitation and deliver a condensed result.

Application

  1. Start with a brief heads-up on estimated time and number of questions.
  2. Ask the user to choose an entry mode:
    • 1 Guided mode (one question at a time)
    • 2 Context dump (paste known context; skip redundancies)
    • 3 Best guess mode (infer missing details and label assumptions)
  3. Run one question per turn and wait for an answer before continuing.
  4. Keep questions plain-language; include a short example response format when helpful.
  5. Show progress each turn:
    • Context Qx/8 during context collection
    • Scoring Qx/5 during assessment/scoring
  6. Ask follow-up clarifications only when they materially improve recommendation quality.
  7. For regular context/scoring questions, offer quick-select numbered response options when practical:
    • Keep options concise and mutually exclusive when possible.
    • Include Other (specify) if likely answers are open-ended.
    • Accept multi-select responses like 1,3 or 1 and 3.
  8. Provide numbered recommendations only at decision points:
    • after context synthesis,
    • after maturity/profile synthesis,
    • during priority/action-plan selection.
  9. Accept numeric or custom choices, synthesize multi-select choices, and continue.
  10. If interrupted by a meta question, answer directly, then restate progress and pending question.
  11. If the user says stop/pause, halt immediately and wait for explicit resume.
  12. End with a clear summary, decisions made, and (if best guess mode was used) an Assumptions to Validate list.

Examples

Opening: "Quick heads-up: this should take about 7-10 minutes and around 10 questions. How do you want to start?

  1. Guided mode
  2. Context dump
  3. Best guess mode"

User: "2"

Facilitator: "Paste what you already know. I’ll skip answered areas and ask only what’s missing."

Decision point after synthesis:

  1. Prioritize Context Design (Recommended)
  2. Prioritize Agent Orchestration
  3. Prioritize Team-AI Facilitation

User: "1 and 3"

Facilitator: "Great. We’ll run Context Design first, with Team-AI Facilitation in parallel."

Inline input at invocation: when the user supplies context with the invocation itself, credit it as answers, open at the first unanswered question, and keep progress labels honest (start at Context Q2/6 if Q1 was covered). Full transcript, including the re-asking anti-pattern: examples/inline-input-flow.md.

Common Pitfalls

  • Asking multiple questions in the same turn.
  • Offering recommendations after every answer (creates interaction drag).
  • Using shorthand labels without plain-language questions.
  • Hiding progress, so users don't know how much remains.
  • Ignoring the user's chosen option or custom direction.
  • Failing to label assumptions when running in best-guess mode.

References

  • Use as the source of truth for interactive facilitation behavior.
  • Apply alongside workshop skills in skills/*-workshop/SKILL.md and advisor-style interactive skills.

首页 - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-07-14 11:19
浙ICP备14020137号-1 $访客地图$