Opportunity Solution Tree - 结构化产品发现框架

技能概述

Opportunity Solution Tree (OST) 是一个可视化框架，帮助产品团队结构化持续产品发现，将期望的业务结果连接到客户机会、可能解决方案和验证实验，基于 Teresa Torres 的《Continuous Discovery Habits》方法论。

适用场景

1. 结构化产品发现工作

当产品团队需要系统化地进行发现工作，而不是零散的临时研究时，OST 提供清晰的四层结构：成果→机会→解决方案→实验。适用于团队不知道"该做什么"或"下一步做什么"的情况，防止直接跳到解决方案而忽略问题定义。

2. 映射机会到解决方案

当团队发现了很多用户痛点，但不确定如何优先处理和匹配解决方案时，OST 帮助将机会（客户需求、痛点、愿望）与多个可能的解决方案连接起来，确保每个解决方案都有明确的机会支撑，避免"先有解决方案再找问题"的反向流程。

3. 决定构建什么优先级

当产品团队面临多个功能需求，需要基于客户价值而非主观意见进行优先级排序时，OST 通过机会评分（重要性 ×（1-满意度））和实验验证，帮助团队做出数据驱动的决策，确保资源投入到真正重要的客户问题上。

核心功能

1. 四层发现结构映射

提供从顶到下的完整产品发现树状结构：

• 成果层：定义单一、可衡量的业务或产品指标（如"7天留存提升到40%"）
• 机会层：从客户研究中识别的需求、痛点和愿望，使用客户视角表达（如"我难以..."或"我希望能够..."）
• 解决方案层：针对每个机会生成至少3个可能的解决方案，由产品三重奏（PM+设计师+工程师）共同头脑风暴
• 实验层：设计快速、廉价的测试来验证解决方案是否真正解决问题，包括价值、可用性、可行性、可行性风险评估

2. 机会优先级评估

使用机会评分公式（Opportunity Score = Importance ×（1- Satisfaction））对客户机会进行优先级排序：

• 将重要性和满意度标准化到 0-1 范围
• 高重要性和低满意度的问题得分最高
• 帮助团队聚焦于真正影响客户体验的核心痛点
• 基于真实客户研究数据而非团队内部意见

3. 实验设计与验证

提供系统化的假设验证方法：

• 明确假设声明（假设解决方案X会帮助客户实现Y）
• 选择最适合的实验方法（原型测试、落地页、假门、 concierge MVP等）
• 定义成功指标和阈值
• 优先选择具有"skin-in-the-game"（真实用户投入）的实验，而非仅基于意见的验证

常见问题

什么是 Opportunity Solution Tree？

Opportunity Solution Tree（机会解决方案树）是由产品发现专家 Teresa Torres 提出的可视化框架，用于结构化产品发现流程。它通过四层树状结构——期望成果、客户机会、解决方案和验证实验——帮助产品团队系统化地从问题定义到解决方案验证。OST 的核心价值在于防止团队过早跳到解决方案，确保每个功能都基于真实的客户需求。

如何使用 OST 框架进行产品发现？

使用 OST 进行产品发现的步骤是：

1. 定义成果：确定一个单一、可衡量的业务指标作为树的顶部
2. 识别机会：通过客户访谈、调研、分析反馈，从客户视角表达3-7个需求或痛点
3. 优先排序：使用机会评分（重要性×（1-满意度））排序，聚焦前2-3个机会
4. 生成方案：对每个优先机会，由产品三重奏共同头脑风暴至少3个解决方案
5. 设计实验：为最有前景的解决方案设计1-2个快速验证实验
6. 可视化树：以树状图呈现完整结构，并随着学习每周更新

Opportunity Solution Tree 适合什么场景？

OST 最适合的场景包括：

• 产品发现初期：团队需要结构化地理解用户问题和需求
• 功能优先级决策：多个需求竞争有限开发资源时
• 避免功能工厂模式：团队只专注交付功能而忽略发现价值时
• 跨职能协作：PM、设计师、工程师需要共同参与产品决策时
• 持续发现流程：建立每周更新发现节奏，而非一次性大调研

OST 不适合紧急的工程修复、技术债务清理或纯基础设施项目。

如何确定产品机会的优先级？

使用机会评分（Opportunity Score）量化排序：

1. 从客户研究中收集每个机会的重要性（Importance）和满意度（Satisfaction）评分
2. 将评分标准化到 0-1 范围（0=最低，1=最高）
3. 计算机会得分 = 重要性 ×（1 - 满意度）
4. 按得分排序，高得分代表"高重要性且低满意度"的痛点，应优先处理
5. 优先聚焦前2-3个机会，避免贪多

定性评估也可以使用：紧急程度、影响范围、与产品战略的契合度等。

产品实验应该如何设计？

有效的产品实验应遵循以下原则：

• 假设清晰：明确声明"如果做X，客户会Y，因为Z"
• 选择合适方法：根据验证的风险类型选择（原型测试验证可用性、假门测试价值意愿、concierge MVP 验证需求频率）
• 快速廉价：优先选择几天内能完成、成本低的实验
• 真实投入：设计让用户付出时间、金钱或声誉的实验（skin-in-the-game），而非仅口头反馈
• 成功标准：预先定义指标和阈值，避免事后解释
• 可执行结果：实验后能明确继续、调整或停止解决方案

Teresa Torres 的 Continuous Discovery Habits 是什么？

Continuous Discovery Habits（《持续发现习惯》）是 Teresa Torres 的产品发现方法论，核心观点包括：

• 连续而非周期性：产品团队应每周进行客户访谈和小实验，而非季度性的大研究
• 产品三重奏：PM、设计师、工程师共同参与发现和决策
• OST 框架：使用机会解决方案树结构化发现工作
• 假设驱动：每个解决方案都基于明确的假设，并通过实验验证
• 避免功能工厂：平衡发现和交付，确保持续理解客户需求

这本书和方法论已成为现代产品管理的标准实践。

产品三重奏如何协作？

产品三重奏（Product Trio）指产品经理（PM）、设计师和工程师三个角色的紧密合作：

• 共同参与发现：三重奏一起参与客户访谈、数据分析和机会识别
• 共同头脑风暴：在生成解决方案时，三重奏共同贡献想法（Torres指出"最好的想法往往来自工程师"）
• 不同视角互补：PM 关注商业价值、设计师 关注用户体验、工程师关注可行性
• 共同决策：对优先级和实验方案达成共识，而非单一角色决定
• 持续沟通：建立每周节奏同步学习、更新 OST

这种协作打破传统的"PM 提需求、工程师实现"的线性流程。

如何避免过早跳到产品解决方案？

OST 框架通过以下机制防止"解决方案优先"的反向流程：

• 强制从问题开始：树的顶部是成果，第二层是机会，必须先定义问题才能讨论解决方案
• 机会非功能：机会必须从客户视角表达（"我难以..."），而非"需要一个按钮"
• 生成多个方案：要求每个机会至少3个解决方案，避免"第一个想法陷阱"
• 对比选择：在生成多个方案后再评估和选择，而非直接执行第一个想法
• 实验验证：选择的解决方案需通过假设测试，而非团队内部投票决定

记住 Torres 的原则："永远不要让客户设计解决方案，优先解决机会（问题）而非功能。"