Back to Details

opportunity-solution-tree

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
引导产品经理创建机会解决方案树（OST），具体步骤包括从利益相关方需求中提取目标成果、生成机会选项（待解决的问题）、梳理潜在解决方案，并基于可行性、影响力和市场适配性选择最优概念验证（POC）。通过此流程将模糊的产品需求转化为结构化的发现过程，确保团队在投入解决方案前先解决正确的问题——避免“功能工厂”综合征和过早锁定想法。
这不是路线图生成工具，而是一个结构化的发现流程，输出经过验证的机会和可测试的解决方案假设。

Key Concepts

核心概念

What is an Opportunity Solution Tree (OST)?

什么是机会解决方案树（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)
OST是一个可视化框架（源自Teresa Torres的《持续发现习惯》），连接以下要素：
  1. 期望成果（业务目标或产品指标）
  2. 机会（能够推动成果的客户问题、需求、痛点或诉求）
  3. 解决方案（解决每个机会的方式）
  4. 实验（验证解决方案的测试）
结构：
         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
  • 成果驱动： 从业务目标出发，而非功能需求
  • 先发散后收敛： 在选定解决方案前探索多个机会
  • 聚焦问题： 机会是真实的问题，而非伪装成问题的解决方案
  • 可测试： 每个解决方案都对应实验，而非直接“开发并上线”
  • POC选择： 在投入资源前评估可行性、影响力和市场适配性

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
  • 不是功能列表： 机会是客户端面临的问题，而非“我们需要深色模式”这类需求
  • 不是解决方案优先： 不要从“我们应该开发X”开始，而要从“客户在Y方面遇到困难”入手
  • 不是瀑布式规划： OST是发现工具，而非项目计划
  • 不是一次性练习： OST会随着你从实验中学习而不断演进

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
  • 利益相关方提出功能或产品倡议需求
  • 启动新产品领域的发现工作
  • 模糊的OKR或战略目标需要明确
  • 优先确定首先解决哪些问题
  • 团队对齐要达成的成果目标

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)
  • 问题已被验证（直接进入解决方案测试阶段）
  • 战术性bug修复或技术债务处理（无需发现过程）
  • 利益相关方强制要求特定解决方案（先解决对齐问题）

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.
默认使用
workshop-facilitation
作为此技能的交互协议。
它定义了：
  • 会议提前通知+进入模式（引导式、上下文输出、最佳猜测）
  • 单轮提问模式，使用通俗易懂的提示语
  • 进度标签（例如：Context Qx/8 和 Scoring Qx/5）
  • 中断处理和暂停/恢复机制
  • 决策点的编号建议
  • 常规问题的快速选择编号响应选项（必要时包含"其他（请说明）"）
本文件定义了特定领域的评估内容。若存在冲突，以本文件的领域逻辑为准。

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)
使用
template.md
获取完整的填写模板。
此交互式技能遵循两阶段流程：
阶段1：生成OST（提取成果、识别机会、梳理解决方案） 阶段2：选择POC（评估解决方案、推荐最佳起点）

Step 0: Gather Context (Before Questions)

步骤0：收集上下文（提问前）

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.
Agent建议：
在创建机会解决方案树之前，我们先收集以下上下文信息：
利益相关方需求或产品倡议：
  • 利益相关方提出了什么需求？（功能请求、产品想法、战略目标）
  • 现有相关材料：PRD草稿、OKR文档、战略备忘录、会议记录
  • 问题陈述、客户投诉或研究发现
产品上下文（如有）：
  • 网站文案、定位声明、产品描述
  • 竞品材料、客户评价（G2、Capterra）、社区讨论
  • 使用数据、支持工单、流失原因
你可以直接粘贴内容，或简要描述需求。

Phase 1: Generate Opportunity Solution Tree

阶段1：生成机会解决方案树

Question 1: Extract Desired Outcome

问题1：提取期望成果

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]
Agent提问： "此倡议的期望成果是什么？（你希望推动哪些业务或产品指标？）"
提供4个枚举选项：
  1. 收入增长 —— "增加ARR、拓展现有客户收入、开发新收入来源"（适用于成长期产品）
  2. 客户留存 —— "降低流失率、提高激活率、提升参与度/粘性"（适用于存在留存问题的成熟产品）
  3. 客户获取 —— "增加注册量、试用转化率、新用户增长"（适用于早期或增长期产品）
  4. 产品效率 —— "降低支持成本、缩短价值实现时间、优化运营指标"（适用于优化运营的成熟产品）
或描述你特定的期望成果（需可衡量：例如“将试用转付费转化率从15%提升至25%”）。
用户回复： [选择或自定义内容]
Agent提取并确认：
  • 期望成果： [具体、可衡量的成果]
  • 重要性： [来自利益相关方需求或上下文的理由]

Question 2: Identify Opportunities (Problems to Solve)

问题2：识别机会（待解决的问题）

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]
Agent根据期望成果和提供的上下文生成3个机会。
Agent说明： "基于你的期望成果（[来自问题1]）和提供的上下文，以下是3个机会（客户问题或需求），它们可以推动该成果的达成："
示例（若成果=提升试用转付费转化率）：
  1. 机会1：用户在试用期间未体验到产品价值 —— "新用户注册后未完成入门流程，从未达到‘顿悟时刻’，在看到核心价值前就放弃"
    • 证据：[来自上下文：入门流程分析数据、支持工单、退出调研]
  2. 机会2：定价不清晰或错位 —— "用户不确定付费计划是否值得；不理解付费能获得什么；定价页面令人困惑"
    • 证据：[来自上下文：定价页面的转化漏斗流失数据、销售异议]
  3. 机会3：免费版“足够好用” —— "用户无限期停留在免费层级，因为免费版已满足其需求；没有足够的理由升级"
    • 证据：[来自上下文：免费增值用户留存数据、寻求变通方法的支持工单]
Agent提问： "你认为哪个机会最需要优先探索，或者你想要修改/添加机会？"
用户回复： [选择或自定义内容]

Question 3: Generate Solutions for Selected Opportunity

问题3：为选定的机会生成解决方案

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]
Agent为选定的机会生成3个解决方案思路。
Agent说明： "针对机会[X]：[名称]，以下是3个可测试的潜在解决方案："
示例（若选定机会1：用户在试用期间未体验到产品价值）：
  1. 解决方案1：引导式入门清单 —— "交互式清单，逐步引导用户完成核心工作流程（例如‘创建你的第一个项目’、‘邀请团队成员’、‘完成一项任务’）"
    • 假设：结构化指导能提高完成率
    • 实验：A/B测试有无清单的情况，衡量激活率
  2. 解决方案2：价值实现时间触发机制 —— "当用户遇到瓶颈时自动提示（例如‘你还未创建项目——这里有一个模板帮你快速开始’）"
    • 假设：主动提示能防止用户流失
    • 实验：跟踪用户与提示的互动情况，衡量试用转付费转化率提升效果
  3. 解决方案3：人工辅助入门 —— "为高价值试用用户（企业、团队计划）提供15分钟的入门指导电话（由客户成功经理负责）"
    • 假设：个性化服务能提高高意向用户的转化率
    • 实验：向50名试用用户提供该服务，衡量其与对照组的转化率差异
Agent提问： "你想要探索其他机会的解决方案，还是进入POC选择阶段？"
用户回复： [选择或自定义内容]

Phase 2: Select Proof-of-Concept (POC)

阶段2：选择概念验证（POC）

After generating solutions, the agent helps select which solution to test first.
生成解决方案后，Agent将帮助你选择首先测试的方案。

Question 4: Evaluate Solutions (Feasibility, Impact, Market Fit)

问题4：评估解决方案（可行性、影响力、市场适配性）

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:
SolutionFeasibility (1-5)Impact (1-5)Market Fit (1-5)Total ScoreRationale
Solution 1: Guided onboarding checklist44513High feasibility (UI pattern), proven impact (industry standard), strong market fit (users expect onboarding)
Solution 2: Time-to-value triggers33410Medium feasibility (requires analytics integration), moderate impact (depends on trigger quality), good market fit
Solution 3: Human-assisted onboarding55313High 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
Agent说明： "让我们评估你的解决方案，以选择最佳起点。我将从可行性（开发难度）、影响力（对成果的推动程度）和市场适配性（与客户需求的契合度）三个维度为每个方案打分。"
Agent生成评估表格：
解决方案可行性（1-5）影响力（1-5）市场适配性（1-5）总分理由
解决方案1：引导式入门清单44513可行性高（UI模式成熟）、影响力已被验证（行业标准）、市场适配性强（用户期望入门指导）
解决方案2：价值实现时间触发机制33410可行性中等（需要集成分析工具）、影响力适中（取决于触发质量）、市场适配性良好
解决方案3：人工辅助入门55313可行性高（无需开发工作）、影响力高（个性化服务）、市场适配性较低（无法规模化،仅适用于高触达场景）
评分标准：
  • 可行性： 1 = 需要数月开发，5 = 数天/数周即可完成
  • 影响力： 1 = 对成果影响极小，5 = 能显著推动成果
  • 市场适配性： 1 = 客户不关心，5 = 客户主动提出需求
Agent推荐：
推荐POC：解决方案1（引导式入门清单）
选择此POC的原因：
  • 平衡了可行性（可在2-4周内完成开发）和影响力（已被验证的模式）
  • 市场适配性强（用户期望入门指导）
  • 可测试假设：“如果我们引导用户完成核心工作流程，激活率将从X%提升至Y%”
备选POC：解决方案3（人工辅助入门）
  • 如果你想在无需开发的情况下快速学习，可从这里开始
  • 手动对20-50名试用用户进行测试，收集定性反馈
  • 将学习成果用于优化自动化解决方案（解决方案1）
不推荐作为POC的方案：解决方案2（价值实现时间触发机制）
  • 需要更多前期投入
  • 影响力取决于触发质量（需要反复实验优化）
  • 更适合在验证核心入门流程后作为后续方案

Question 5: Define Experiment

问题5：定义实验

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]
Agent提问： "你将如何测试这个解决方案？具体的实验方案是什么？"
提供3个枚举选项：
  1. A/B测试 —— "开发最小可行产品（MVP），展示给50%的试用用户，对比其与对照组的转化率"（最适合：量化验证，需要足够流量）
  2. 原型+可用性测试 —— "创建可点击原型，观察10名用户完成入门流程，收集定性反馈"（最适合：早期验证，流量较少）
  3. 人工礼宾式测试 —— "手动为20名用户执行解决方案（例如，亲自引导他们完成入门流程），衡量成果"（最适合：快速学习，无需开发）
或描述你自己的实验方法。
用户回复： [选择或自定义内容]

Output: Opportunity Solution Tree + POC Plan

输出：机会解决方案树 + POC计划

After completing the flow, the agent outputs:
markdown
undefined
完成流程后，Agent将输出：
markdown
undefined

Opportunity Solution Tree + POC Plan

Opportunity Solution Tree + POC Plan

Desired Outcome

Desired Outcome

Outcome: [From Q1] Target Metric: [Specific, measurable goal] Why it matters: [Rationale]
Outcome: [From Q1] Target Metric: [Specific, measurable goal] Why it matters: [Rationale]

Opportunity Map

Opportunity Map

Opportunity 1: [Name]

Opportunity 1: [Name]

Problem: [Description] Evidence: [From context]
Solutions:
  1. [Solution A]
  2. [Solution B]
  3. [Solution C]
Problem: [Description] Evidence: [From context]
Solutions:
  1. [Solution A]
  2. [Solution B]
  3. [Solution C]

Opportunity 2: [Name]

Opportunity 2: [Name]

Problem: [Description] Evidence: [From context]
Solutions:
  1. [Solution A]
  2. [Solution B]
  3. [Solution C]
Problem: [Description] Evidence: [From context]
Solutions:
  1. [Solution A]
  2. [Solution B]
  3. [Solution C]

Opportunity 3: [Name]

Opportunity 3: [Name]

Problem: [Description] Evidence: [From context]
Solutions:
  1. [Solution A]
  2. [Solution B]
  3. [Solution C]
Problem: [Description] Evidence: [From context]
Solutions:
  1. [Solution A]
  2. [Solution B]
  3. [Solution C]

Selected POC

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]
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

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.

---
  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:
markdown
**Desired Outcome:** Increase trial-to-paid conversion from 15% to 25%
**Opportunity:** Users don’t reach "aha" moment during trial
**Solution:** Guided onboarding checklist
查看
examples/sample.md
获取完整的OST示例。
迷你示例节选：
markdown
**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

误区1：机会伪装成解决方案

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)

误区2：跳过发散阶段（直接跳到单一解决方案）

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.
症状： "我们知道解决方案是[X]，只需开发即可"
后果： 错失更好的替代方案，无法学习到新信息。
解决方法： 为每个机会至少生成3个解决方案。强制自己先发散再收敛。

Pitfall 3: Outcome is Too Vague

误区3：成果过于模糊

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%."
症状： "期望成果：提升用户体验"
后果： 无法衡量成功，无法优先排序机会。
解决方法： 让成果可衡量：“将NPS从30提升至50”或“将入门流程流失率从60%降低至40%”。

Pitfall 4: No Experiments (Just Build It)

误区4：无实验（直接开发）

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.
症状： 选择解决方案后直接进入路线图
后果： 缺乏验证，开发错误产品的风险高。
解决方法： 每个解决方案都必须对应实验。没有实验就没有OST。

Pitfall 5: Analysis Paralysis (Exploring Forever)

误区5：分析瘫痪（无限探索）

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.
症状： 生成20个机会、50个解决方案，却始终不做选择
后果： 团队陷入发现阶段，无法推进。
解决方法： 限制为3个机会，每个机会对应3个解决方案（共9个）。选择POC，运行实验，学习，迭代。

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
  • skills/problem-statement/SKILL.md
    —— 将机会梳理为客户问题
  • skills/jobs-to-be-done/SKILL.md
    —— 从JTBD研究中识别机会
  • skills/epic-hypothesis/SKILL.md
    —— 将已验证的解决方案转化为可测试的史诗需求
  • skills/user-story/SKILL.md
    —— 将实验拆解为可交付的用户故事
  • skills/discovery-interview-prep/SKILL.md
    —— 通过客户访谈验证机会

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
  • Teresa Torres，《持续发现习惯》（2021）—— 机会解决方案树的起源
  • Jeff Patton，《用户故事地图》（2014）—— 成果驱动的产品规划
  • Ash Maurya，《精益创业实战》（2012）—— 假设驱动的实验

Dean's Work

Dean的相关工作

  • 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
  • Productside Blueprint —— 战略产品发现流程
  • [若Dean有OST相关资源，在此处链接]
技能类型： 交互式 建议文件名： 
opportunity-solution-tree.md
建议存放路径： 
/skills/interactive/
依赖项： 使用
skills/problem-statement/SKILL.md
、
skills/jobs-to-be-done/SKILL.md
、
skills/epic-hypothesis/SKILL.md
、
skills/user-story/SKILL.md