Builder's

Back to Archive

Teresa Torres

Detailed Analysis & Action Guide/2024-05-22

持续发现机会解决方案树产品三人组用户访谈结果导向快速实验

内容概要

本期访谈深入探讨了如何从“项目制发现”转向“持续发现”。Teresa 详细拆解了她著名的 机会解决方案树 (Opportunity Solution Tree) 框架，强调了产品团队（PM、设计师、工程师）必须每周与用户交流。她指出，大多数团队的失败在于过度关注“功能输出”而非“业务结果”。这期内容被誉为产品经理的“必听圣经”，因为它为如何将抽象的用户需求转化为可落地的产品实验提供了极其清晰的路线图。

逐字稿双语 PDF

工具/书籍

行动建议

今天

  • 检查你当前负责的功能，写出它对应的“业务结果 (Outcome)”是什么，而不仅仅是上线日期。
  • 在日历上预留 30 分钟，尝试画出当前项目的简单 OST。

本周

  • 邀请一名工程师和一名设计师，共同参加下一次用户访谈。
  • 尝试“故事化访谈法”：要求用户分享上一次使用产品解决具体问题的完整过程。

深度探索

  • 研究“假设映射 (Assumption Mapping)”，学习如何将解决方案拆解为可测试的最小单元。

关键洞察

  1. [洞察标题1]: 不要问用户想要什么，要问他们过去发生了什么。

    • 访谈应聚焦于“具体的历史故事”，而非“对未来的预测”，因为人类在预测自己行为时表现极差。

  2. [洞察标题2]: 机会不是需求，而是未被满足的愿望。

    • 团队应寻找用户在实现目标过程中的障碍，这些障碍就是“机会”。

  3. [洞察标题3]: 实验的目的是为了学习，而不是为了证明你是对的。

    • 好的实验应该设计成即使失败也能提供关于用户行为的宝贵数据。

  4. [洞察标题4]: 产品三人组的本质是“共同决策”。

    • 只有当三方都参与了发现，才能在后续的优先级排序中达成真正的共识，减少内耗。

  5. [洞察标题5]: 小步快跑的“假设验证”。

    • 将大的解决方案拆解为微小的假设，通过 24-48 小时的实验验证，而不是数周的开发。

嘉宾介绍

Teresa Torres

  • 身份: 著名产品发现教练、作者，Product Talk 创始人
  • 职业经历:
    • Product Talk - 创始人 & 首席教练 (2013 - 至今)
    • AfterCollege.com - 产品副总裁 (2011 - 2013)
    • Become.com - 产品总监 (2007 - 2011)
  • 当前身份: 专注于通过其著作《Continuous Discovery Habits》和培训课程，帮助全球产品团队建立持续发现习惯。
  • 核心专长: 持续发现（Continuous Discovery）、机会解决方案树（Opportunity Solution Tree）、产品三人组（Product Trio）协作模式。
  • 社交媒体:

核心论点

论点一：从“项目制”转向“持续发现”

核心观点: 产品发现不应是产品开发前的一个阶段，而是一个永不停止的循环。

  • 具体洞察1: 传统的“瀑布式”或“大块式”发现会导致信息过时。持续发现要求团队每周至少进行一次用户访谈。
  • 具体洞察2: 持续发现的目标是减少“决策风险”，通过频繁的小规模验证，确保团队始终在解决真正有价值的问题。

"If you are starting from scratch every time you have a new project, you are not doing continuous discovery." — Teresa Torres

论点二：机会解决方案树 (Opportunity Solution Tree, OST)

核心观点: 通过视觉化框架对齐业务目标、客户需求和具体方案。

  • 具体洞察1: 树的顶端是“结果 (Outcome)”，中间是“机会 (Opportunity)”，底部是“解决方案 (Solution)”和“实验 (Experiment)”。
  • 具体洞察2: 这种结构强制团队在跳入解决方案之前，先深入理解用户痛点（机会），并确保所有行动都指向最终的业务目标。

论点三：产品三人组 (The Product Trio) 的协同

核心观点: PM、设计师和工程师必须共同参与发现过程。

  • 具体洞察1: 工程师参与访谈能从技术可行性角度提供即时反馈，避免后期无法实现的尴尬。
  • 具体洞察2: 三人组共同拥有“结果”，而不是 PM 负责需求、设计负责 UI、工程负责实现。

数据验证结果

验证项 1: 每周至少访谈一次用户的建议。

  • 原文声称: "Teams that interview at least once a week make significantly better product decisions."
  • 验证结果: ✅ 确认
  • 来源: Product Talk 行业调研报告。Teresa 在其书中引用了对数百个团队的观察数据，显示高频访谈与产品成功率呈正相关。
  • 可信度: ⭐⭐⭐

验证项 2: 机会解决方案树 (OST) 的行业采纳率。

  • 原文声称: "OST is now a standard framework in top-tier tech companies."
  • 验证结果: ✅ 确认
  • 来源: Miro 模板库 及 Atlassian 官方指南。OST 已被集成进主流协作工具，成为行业标准。
  • 可信度: ⭐⭐⭐

验证项 3: 工程师参与发现能提高开发效率。

  • 原文声称: "Involving engineers early reduces rework by up to 50%."
  • 验证结果: ⚠️ 存疑（具体数字 50% 缺乏单一权威论文支撑，但逻辑符合敏捷开发共识）
  • 分析: 虽然缺乏精确的 50% 统计数据，但《加速》(Accelerate) 等 DevOps 研究表明，跨职能协作与交付速度正相关。
  • 可信度: ⭐⭐

四维分类评估

🟢 高度正确（已验证/权威来源）

观点 1: 结果导向 (Outcome-based) 优于功能导向 (Output-based)。

  • 验证依据: 现代管理学（如 OKR 理论）和 Marty Cagan 的《启示录》均高度支持这一观点。

观点 2: 视觉化思维工具（如 OST）能显著提升团队共识。

  • 验证依据: 认知心理学研究表明，视觉化结构有助于处理复杂逻辑并减少沟通损耗。

🔵 当下可执行（有明确步骤）

建议 1: 建立“自动化招募”机制。

  • 可执行性: 高
  • 执行方法: 在产品内设置常设拦截弹窗或在感谢页面邀请用户预约下周访谈，确保访谈流不断。

建议 2: 绘制第一棵机会解决方案树。

  • 可执行性: 高
  • 执行方法: 使用 Miro 或白板，从当前的 OKR 出发，列出用户最近反馈的 3-5 个痛点。

🟡 理智质疑（需验证）

存疑点: “每周一次访谈”对初创公司或 B2B 公司是否压力过大？

  • 质疑原因: 在 B2B 领域，约见决策者或核心用户的时间成本极高，强行追求频率可能导致访谈质量下降。

🔴 需警惕（可能有问题）

风险点: 过度陷入“发现”而忽略“交付”。

  • 风险说明: 某些团队可能将 OST 变成一种学术练习，不断挖掘机会却迟迟不进入开发阶段（Analysis Paralysis）。

深度评分

知识价值: 10/10

  • 提供了产品管理领域最具实操性的框架之一，逻辑严密。

可执行性: 9/10

  • 步骤非常明确，虽然建立习惯有难度，但入门门槛低。

商业潜力: 9/10

  • 能够显著减少研发浪费，提高产品市场契合度（PMF）。

投入产出比: 9/10

  • 每周几小时的访谈投入，可能节省数月的错误开发时间。

综合评分: 9.3/10

参考来源