mcpField
O
opportunity-solution-tree

opportunity-solution-tree

github.com/deanpeters设计与 UI7.7k2.8k 次安装2 周前更新
代码仓库

关于 opportunity-solution-tree

面向产品经理的 Opportunity Solution Tree（OST）构建技能，将利益相关者请求转化为目标结果、客户问题、解决方案和实验。它还按可行性、影响和市场契合度评估方案，帮助选择概念验证（POC）。

主要功能

  1. 01从请求中提取目标结果
  2. 02生成并筛选客户机会
  3. 03为选定机会提出解决方案
  4. 04将方案关联到验证实验
  5. 05按可行性、影响与市场契合度评估

适用场景

  1. 01将模糊的功能请求转为探索框架
  2. 02围绕业务目标识别客户问题
  3. 03比较解决方案并选择 POC
  4. 04为解决方案设计可验证的实验

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/deanpeters/product-manager-skills --skill opportunity-solution-tree

安装后在 Claude Code 中输入/opportunity-solution-tree确认已加载。

附带文件examples/sample.mdtemplate.md

详细介绍

目的

引导产品经理创建机会解决方案树（OST）：从利益相关方的请求中提取目标结果，生成机会选项（待解决的问题），梳理潜在解决方案，并根据可行性、影响和市场契合度选出最佳概念验证（POC）。利用此流程，将模糊的产品请求转化为结构化的探索，确保团队在着手解决方案之前先解决正确的问题，避免陷入“功能工厂”综合征或过早地对想法收敛。

这不是路线图生成器，而是一个结构化的探索流程，旨在产出经过验证的机会和可测试的解决方案假设。

输入

最适合的输入： 利益相关方的请求，或你要从其出发的目标结果。 也很有用： 你已有的客户证据、约束条件，以及已经有人在推动的解决方案。

调用时一并提供的任何内容——技能名称之后的文本、粘贴的上下文，或追加的 ARGUMENTS: 行——都视为已提供的答案。使用这些内容，并跳过其中已涵盖的问题；不要重复询问。

没有准备任何内容？也没关系。 此技能会先询问请求或期望结果，然后从中提取可衡量的目标结果。

调用示例： Build an OST from this request: 'Sales says we need a mobile app because competitors have one.'

核心概念

什么是机会解决方案树（OST）？

OST 是一个可视化框架（Teresa Torres，《Continuous Discovery Habits》），用于连接：

  1. 期望结果（业务目标或产品指标）
  2. 机会（可能推动目标实现的客户问题、需求、痛点或愿望）
  3. 解决方案（解决各项机会的方式）
  4. 实验（用于验证解决方案的测试）

结构：

         Desired Outcome (1)
                |
    +-----------+-----------+
    |           |           |
Opportunity  Opportunity  Opportunity (3)
    |           |           |
  +-+-+       +-+-+       +-+-+
  | | |       | | |       | | |
 S1 S2 S3    S1 S2 S3    S1 S2 S3 (9 total solutions)
为什么有效
  • 以结果为导向： 从业务目标开始，而不是从功能请求开始
  • 先发散，再收敛： 先探索多个机会，再选择解决方案
  • 聚焦问题： 机会是问题，而不是伪装成问题的解决方案
  • 可测试： 每个解决方案都对应实验，而不是只说“构建并发布”
  • 选择 POC： 在投入资源前评估可行性、影响和市场契合度
反模式（这不是什么）
  • 不是功能列表： 机会是客户面临的问题，而不是“我们需要深色模式”
  • 不是从解决方案出发： 不要从“我们应该构建 X”开始，而要从“客户在 Y 方面遇到困难”开始
  • 不是瀑布式规划： OST 是探索工具，不是项目计划
  • 不是一次性练习： OST 会随着你从实验中获得新认知而不断演进
何时使用
  • 利益相关方提出功能或产品计划请求
  • 开始探索新的产品领域
  • 明确模糊的 OKR 或战略目标
  • 确定应优先解决哪些问题
  • 让团队就要推动的结果达成一致
何时不使用
  • 问题已经得到验证时（转入解决方案测试）
  • 用于战术性 bug 修复或技术债务（无需探索）
  • 利益相关方要求采用特定解决方案时（先解决共识问题）
引导流程的权威依据

将 workshop-facilitation 作为此技能的默认交互协议。

其中定义了：

  • 开场说明和进入模式（引导式、上下文转储、最佳猜测）
  • 每轮一个问题，并使用通俗易懂的提示
  • 进度标签（例如 Context Qx/8 和 Scoring Qx/5）
  • 中断处理以及暂停／恢复行为
  • 决策节点处的编号建议
  • 常规问题的编号快速选择选项（适用时包含 Other (specify)）

本文件定义了特定领域的评估内容。如果存在冲突，请遵循本文件的领域逻辑。

应用

完整的填写结构请参阅 template.md。

这项交互式技能采用两阶段流程：

阶段 1： 生成 OST（提炼结果、识别机会、梳理解决方案） 阶段 2： 选择 POC（评估解决方案，推荐最佳起点）

步骤 0：收集背景信息（提问之前）

Agent 建议：

在创建机会解决方案树之前，我们先收集一些背景信息：

利益相关方的请求或产品计划：

  • 利益相关方提出了什么要求？（功能请求、产品构想、战略目标）
  • 是否有现有材料：PRD 草稿、OKR 文档、战略备忘录、会议记录
  • 问题陈述、客户投诉或研究结果

产品背景（如有）：

  • 网站文案、定位陈述、产品描述
  • 竞争对手的材料、客户评价（G2、Capterra）、社区讨论
  • 使用数据、支持工单、客户流失原因

你可以直接粘贴这些内容，也可以简要描述请求。

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

问题 1：提炼预期结果

Agent 提问： “这项计划的预期结果是什么？（你希望推动哪项业务或产品指标？）”

提供 4 个编号选项：

  1. 营收增长 — “提高 ARR、扩大现有客户带来的营收、开辟新的收入来源”（常见于处于规模化阶段的产品）
  2. 客户留存 — “减少客户流失、提高激活率、改善参与度／用户黏性”（常见于已成熟但存在留存问题的产品）
  3. 客户获取 — “增加注册人数、提高试用转化率、扩大新用户群体”（常见于早期或增长型产品）
  4. 产品效率 — “降低支持成本、缩短价值实现时间、改善运营指标”（常见于优化运营的成熟产品）

或者描述你的具体预期结果（请确保可衡量，例如：“将试用转付费转化率从 15% 提高到 25%”）。

用户回复：[选择或自定义]

Agent 提炼并确认：

  • 预期结果：[具体、可衡量的结果]
  • 为何重要：[利益相关方请求或背景信息中的依据]
问题 2：识别机会（待解决的问题）

Agent 根据预期结果和提供的背景信息，生成 3 个机会。

Agent 表示： “根据你的预期结果（[来自问题 1]）和你提供的背景信息，以下是可能推动这一结果的3 个机会（客户问题或需求）：”

示例（如果预期结果 = 提高试用转付费转化率）：

  1. 机会 1：用户在试用期间无法体验到价值 — “新用户注册后没有完成引导，始终未达到‘顿悟时刻’，在看到核心价值之前就放弃了”

    • 证据：[来自背景信息：引导流程分析数据、支持工单、退出调查]

  2. 机会 2：定价不清晰或不匹配 — “用户不确定付费方案是否物有所值；不了解所付费用对应的权益；定价页面令人困惑”

    • 证据：[来自背景信息：定价页面的转化漏斗流失情况、销售异议]

  3. 机会 3：免费方案“已经够用” — “用户长期停留在免费层级，因为它已满足需求；缺少促使他们升级的有力理由”

    • 证据：[来自背景信息：免费增值用户留存数据、询问替代方案的支持工单]

Agent 提问： “你觉得哪个机会最值得优先探索？或者你想修改／添加机会吗？”

用户回复：[选择或自定义]

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

Agent 为选定的机会生成 3 个解决方案创意。

Agent 说： “针对机会 [X]：[名称]，以下是可供测试的 3 个潜在解决方案：”

示例（若选择机会 1：用户在试用期间无法体验到价值）：

  1. 解决方案 1：引导式入门清单 — “通过交互式清单逐步引导用户完成核心工作流（例如‘创建你的第一个项目’、‘邀请一位队友’、‘完成一项任务’）”

    • 假设：结构化引导能提高完成率
    • 实验：对比测试使用清单与不使用清单的效果，衡量激活率

  2. 解决方案 2：价值实现时间触发提示 — “在用户遇到困难时自动向其发送提示（例如‘你还没有创建项目——这里有一个模板可帮助你开始’）”

    • 假设：主动提示能防止用户流失
    • 实验：跟踪提示的互动情况，衡量试用转付费的提升幅度

  3. 解决方案 3：人工协助入门 — “为高价值试用用户（企业版、团队版套餐）提供 15 分钟的 CSM 入门指导电话”

    • 假设：个性化服务能提高高意向用户的转化率
    • 实验：向 50 位试用用户提供此服务，衡量转化率与对照组的差异

Agent 提问： “你想继续探索另一个机会的解决方案，还是开始选择 POC？”

用户回复： [选择或自定义]

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

生成解决方案后，Agent 会协助选择要优先测试的解决方案。

问题 4：评估解决方案（可行性、影响、市场契合度）

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（价值实现时间触发提示）

  • 需要更多前期投入
  • 影响取决于触发条件的质量（需要通过实验找到合适方案）
  • 验证核心入门流程后，再将其作为后续方案更合适
问题 5：定义实验

Agent 询问： “你将如何测试这个解决方案？实验是什么？”

提供 3 个编号选项：

  1. A/B 测试 — “构建 MVP，向 50% 的试用用户展示，并将转化率与对照组进行比较”（最适合：定量验证，需要流量）
  2. 原型 + 可用性测试 — “创建可点击的原型，观察 10 位用户尝试完成入门流程，并收集定性反馈”（最适合：早期验证、流量较少）
  3. 人工礼宾测试 — “与 20 位用户一起手动运行解决方案（例如，亲自引导他们完成入门流程），并衡量结果”（最适合：快速学习、无需开发工作）

或者描述你的实验方案。

用户回复： [选择或自定义]

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

完成流程后，Agent 将输出：

# 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.**

示例

完整的 OST 示例请参阅 examples/sample.md。

迷你示例摘录：

**Desired Outcome:** Increase trial-to-paid conversion from 15% to 25%
**Opportunity:** Users don’t reach "aha" moment during trial
**Solution:** Guided onboarding checklist

常见陷阱

陷阱 1：伪装成解决方案的机会

症状：“机会：我们需要一个移动应用”

**后果：**你还没探索问题，就已经认定了某个解决方案。

**解决方法：**将机会重新表述为客户问题：“移动优先的用户无法随时随地访问产品。”

陷阱 2：跳过发散（直接跳到一个解决方案）

症状：“我们知道解决方案是 [X]，只需要把它构建出来”

**后果：**错过更好的替代方案，也无法获得新认知。

**解决方法：**每个机会至少生成 3 个解决方案。在收敛之前，先强制进行发散思考。

陷阱 3：预期成果过于模糊

症状：“预期成果：改善用户体验”

**后果：**无法衡量成功，也无法确定机会的优先级。

**解决方法：**让成果可衡量：“将 NPS 从 30 提高到 50”或“将入门流程流失率从 60% 降至 40%。”

陷阱 4：没有实验（直接构建）

**症状：**选定一个解决方案后，直接进入路线图规划

**后果：**没有验证，构建错误方案的风险很高。

**解决方法：**每个解决方案都必须对应一个实验。没有实验 = 没有 OST。

陷阱 5：分析瘫痪（一直探索）

**症状：**生成 20 个机会、50 个解决方案，却始终不选一个

**后果：**团队陷入探索阶段，毫无进展。

**解决方法：**将范围限制在 3 个机会，每个机会 3 个解决方案（总计 9 个）。选择 POC，开展实验，吸取经验并迭代。

参考资料

相关技能
  • 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 — 通过客户访谈验证机会
外部框架
  • Teresa Torres，《Continuous Discovery Habits》（2021）——机会解决方案树的起源
  • Jeff Patton，《User Story Mapping》（2014）——以成果为导向的产品规划
  • Ash Maurya，《Running Lean》（2012）——以假设为驱动的实验
Dean 的工作
  • 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

评论

支持 Markdown