跳转至

Deep Research: Continuous Discovery Habits (the Book) is Finally Here!

  • Source: https://www.producttalk.org/continuous-discovery-habits/
  • Snapshot: ../../sources/md/www-producttalk-org-continuous-discovery-habits-0bd7e1e218e1.md
  • Category: Discovery & Product Strategy (product_discovery)
  • Chapters: 01-method, 02-discovery, 05-validation, 19-iteration

TL;DR

Teresa Torres 的《持续发现习惯》为现代产品开发确立了新标准：通过产品三人组（Product Trio）的紧密协作，建立每周与用户互动的习惯，利用机会解决方案树（OST）将业务成果（Outcomes）与用户机会及实验连接起来，从而代替传统的猜功能、做功能模式，确保构建的产品真正创造价值。

核心观点

  1. 产品三人组（Product Trio）是最小作战单元 产品发现不再是产品经理的独角戏。产品经理、设计师和工程师必须共同参与发现过程，共同对决策负责。这能确保方案在具备商业价值的同时，也兼顾可用性和技术可行性。
  2. 从输出（Outputs）转向成果（Outcomes） 不要以交付了多少功能来衡量成功，而要看改变了什么用户行为或创造了什么业务价值。发现工作的起点必须是明确的业务目标。
  3. 持续发现是一种习惯，而非项目 发现工作不是每个季度做一次的大调研，而是通过每周的小型活动（如与客户交谈）持续进行的。小频次、持续性的投入比突击式的大规模研究更有效。
  4. 机会解决方案树（OST）是核心导航图 使用 OST 将杂乱的思考结构化：业务成果 (Outcome) → 客户机会/痛点 (Opportunity) → 解决方案 (Solution) → 假设实验 (Assumption Test)。这不仅是可视化的工具，更是对齐团队认知的神器。
  5. 测试假设，而不是验证创意 传统的验证想法往往周期长且带有证实偏差。更高效的做法是提取想法背后的关键假设（如：用户想要这个吗？由于技术原因做得到吗？），并针对这些假设进行快速、低成本的测试。
  6. 客户访谈是为了挖掘机会，而非询问需求 不要问用户你想要什么功能，而是通过访谈了解他们的具体故事、背景和痛点，从中识别出潜在的机会空间。
  7. 管理好利益相关者 展示你的 OST 而不是死板的路线图。通过展示思考过程（你是如何从目标推导到当前方案的），让利益相关者理解决策背后的逻辑，从而获得支持而非微管理。

可落地做法

1. 建立持续访谈机制（产品/运营）

  • 自动化招募：不要每次临时找人。在产品中植入自动触发器（例如：用户完成某操作后），邀请其参与简短交流。
  • 每周节奏：设定硬性指标，例如每周至少与一位客户进行 15 分钟视频通话。
  • 故事挖掘：访谈时用一句固定开场，例如跟我讲讲你上次……的经历，收集具体事实而非观点。

2. 绘制并维护 OST（产品/工程/设计）

  • 启动会：三人组围坐在一起，先画出顶层的业务成果。
  • 机会映射：将访谈中收集到的用户痛点转化为机会节点，挂在成果之下。
  • 方案头脑风暴：针对选定的高优先级机会，发散多个解决方案。不要直接跳进代码实现。

3. 快速假设测试（工程/QA/评测）

  • 拆解假设：对于一个候选方案，列出它成立必须满足的条件（价值假设、可用性假设、可行性假设、商业假设）。
  • 最小实验：针对最危险的假设设计测试。
    • 示例：与其开发完整功能，不如先放一个假按钮或落地页（Fake Door Test）看点击率。
  • AI 辅助：利用 LLM 模拟用户对假设进行初步压力测试，或让 AI 协助设计实验步骤。

检查清单：持续发现健康度自查

此清单可用于周会或 Sprint 回顾：

  • 结构化思维检查 (OST Check)
    • [ ] 我们当前的冲刺任务是否能直接追溯到 OST 上的某个机会节点？
    • [ ] 这个机会节点是否连接到一个明确的业务成果？
    • [ ] 我们是否为同一个机会考虑了至少 2-3 个备选解决方案？
  • 客户接触检查 (Customer Touchpoint)
    • [ ] 过去 7 天内，三人组是否至少共同参与了一次客户访谈？
    • [ ] 我们是否不仅听到了用户的意见，还收集到了具体的过去行为故事？
  • 实验验证检查 (Assumption Testing)
    • [ ] 在开始写代码前，我们是否识别并测试了风险最大的假设？
    • [ ] 我们的测试周期是否短于 2 天？（如果是构建 MVP，通常太慢了）
  • 团队协作检查 (Trio Health)
    • [ ] 工程师是否在方案设计阶段就介入，而不仅仅是接需求文档？
    • [ ] 设计师是否理解业务目标，而不仅仅是画图？

常见坑与对策

常见坑 (Pitfall) 表现 对策 (Solution)
验证剧场 (Validation Theater) 做调研只是为了证明自己是对的，忽略反面证据。 引入比较思维：永远不要只测试一个方案，同时测试两个方案，强迫自己选择表现更好的那个。
功能工厂 (Feature Factory) 团队只关注交付速度（Output），不关心是否达成了业务目标（Outcome）。 改变 OKR 设定方式，停止考核发布数量，转而考核指标变动。产品三人组需对结果负责。
把 OST 当任务列表 将 OST 填满已经决定要做的功能，只是为了看起来科学。 逆向检查：如果这个功能不做了，对应的机会是否还能通过其他方式满足？如果不能，说明是先射箭后画靶。
工程师缺席 只有 PM 见客户，工程师只看文档。 强制要求工程师轮流参与访谈。这能通过技术视角发现低成本的高价值方案。
分析瘫痪 花太多时间画完美的树，而不去行动。 OST 是动态草稿，不是完美文档。先画个粗糙的，通过行动去修正它。

可用于丰富《AI 辅助软件产品》的写作点

这本书的方法论非常适合作为 AI 辅助产品开发的基座逻辑。AI 不会改变以用户为中心的本质，但能极大地加速发现循环。

  • 第 01 章 方法论 (01-method)

    • 结合点：将产品三人组扩展为 Product Trio + AI Agent。
    • 论述：在 AI 时代，AI Agent 可以作为第四位成员，实时整理访谈记录、自动更新 OST 分支、甚至预演假设测试。持续发现的频率可以从每周提升到每日甚至实时。

  • 第 02 章 需求发现 (02-discovery)

    • 结合点：AI 增强的 OST (AI-Augmented OST)。
    • 具体写法：
      1. 利用 LLM 分析海量用户反馈（工单、评论），自动提取机会节点，生成 OST 的草稿供人类审核。
      2. 合成用户访谈：在真人访谈前，利用 Persona Agent 进行模拟访谈，预挖掘可能的机会点，提高真人访谈的质量。

  • 第 05 章 验证与原型 (05-validation)

    • 结合点：生成式假设测试 (Generative Assumption Testing)。
    • 具体写法：
      1. 引用书中的测试假设而非方案观点，介绍如何用 AI 快速生成验证所需的物料（Landing Page 文案、原型图代码）。
      2. 利用 AI 对假设进行预评分：输入假设和已知用户数据，让模型预测潜在风险，优先测试高风险项。

  • 第 07 章 工程实现 (07-engineering)

    • 结合点：工程师在发现阶段的新角色。
    • 论述：借助 AI 编码工具（Cursor/Copilot），工程师实现原型的时间大幅缩短。这使得工程师有更多精力参与前期的 OST 构建和机会评估，真正实现 Teresa Torres 倡导的工程参与发现。