continuous-discovery

持续发现习惯框架

用于建立可持续的每周客户探索实践，让产品团队持续朝着期望的结果迈进。探索不是开发前的一个阶段，而是融入产品工作的持续节奏中，确保每项决策都有最新证据作为依据。

核心原则

良好的产品探索需要持续的节奏，而非一次性活动。 每周与客户交流、以可视化方式梳理机会，并在构建前验证假设的团队，表现始终优于依赖直觉、利益相关者意见或季度研究周期的团队。基准：产品三人组（产品经理、设计师、工程师）每周至少与客户接触一次。

评分

目标：10/10。 根据下方七项快速诊断逐项评估探索实践——从 3 分起步，每项回答“是”加 1 分（最高 10 分）。分档：9-10 = 每周保持稳定节奏，拥有持续更新的机会解决方案树，系统地测试假设，且每项发布的功能都能追溯到客户机会；5-6 = 有一些探索活动，但临时性较强、仅由产品经理负责，或与交付脱节；≤3 = 由直觉和利益相关者意见驱动，且没有定期的客户接触。报告当前得分、未通过的项目，以及每项对应的具体改进措施。

框架

1. 机会解决方案树

核心概念： 机会解决方案树（OST）以可视化方式将期望结果（顶部）、客户机会（中部）、潜在解决方案和实验（底部）连接起来，让隐含的产品思路变得明确，并成为团队共识。

作用原理： 大多数团队从业务结果直接跳到解决方案，完全跳过客户需求；OST 则迫使团队先理解机会领域，避免开发出无人需要的功能。

关键见解：

• 四个层级：结果 > 机会 > 解决方案 > 实验
• 机会是客户的需求、痛点和愿望——从客户视角进行描述
• 这棵树是一个持续更新的成果，团队每周学习后都会对其进行更新
• 将大型机会拆分为更小的子机会，使其切实可行
• 同时探索多个机会——不要把所有赌注都押在一个机会上

产品应用：

场景	应用方式	示例
季度规划	在确定功能前梳理机会领域	“提高试用转付费转化率” → 探索用户未转化的原因
功能优先级排序	比较不同机会对应的解决方案，找出杠杆效应最大的选择	针对“找不到内容”的三个解决方案，与针对“引导流程令人困惑”的两个解决方案进行比较
利益相关者达成共识	将这棵树用作共享的策略可视化图示	向领导层说明为什么选择机会 X 而非 Y

伦理边界： 切勿挑选机会来证明预先决定的解决方案合理——这棵树必须反映通过研究发现的需求。

构建或审查机会解决方案树时，请参阅 references/opportunity-trees.md——其中补充了四层结构图、良好与不佳结果对照表、解决方案生成技巧、每周更新节奏、树状图健康与衰退的信号、两个完整示例，以及四种反模式。

2. 体验映射

核心概念： 当前状态体验地图逐步记录客户如今如何实现目标，揭示可转化为树上机会的痛点。

为何有效： 团队往往以为自己了解客户当前的体验；根据访谈数据绘制地图，能发现从团队内部视角看不到的差距、权宜之计和情绪。

关键见解：

• 绘制当前状态，而非未来的理想状态——先了解现实
• 记录每个步骤中的行动、想法和感受
• 与完整的三人组协作，根据访谈数据绘制，而非依赖假设
• 体验地图涵盖客户的完整体验；旅程地图只涵盖客户与产品的接触点
• 痛点和情绪强烈的时刻会成为 OST 上的机会

产品应用：

场景	应用	示例
新的问题领域	设计前绘制端到端地图	小企业主如何处理发票，从创建发票到催款
流失分析	绘制流失用户的体验，找到失败点	用户在引导流程第 4 步放弃——他们手头缺少所需数据
跨职能协作	一起绘制地图	一场三小时的协作会议产出一份团队共享的参考资料

在绘制新问题领域或流失流程的地图时，请参阅 references/experience-mapping.md——其中提供当前状态地图模板、体验地图与旅程地图的区别，以及协作绘图练习。

3. 访谈快照

核心概念： 基于故事的访谈会捕捉具体的过往经历（而非观点或预测），并将每次访谈提炼为一页快照，供整个团队阅读和参考。

为何有效： 客户很难准确预测自己未来的行为；以真实的过往事件为依据，能揭示他们实际做了什么、感受如何，而快照则将每次访谈转化为不断扩充的证据库。

关键见解：

• 询问具体的过往行为：“说说你上一次……的经历”，而不是“你会使用……吗？”
• 每份快照都记录故事、关键引述、发现的机会和标识符
• 三人组一起开展访谈，避免在转述过程中丢失见解
• 自动化招募流程，让访谈每周都能进行，无须付出巨大努力
• 多份快照中的模式能揭示机会；单次访谈只能揭示故事

产品应用：

场景	应用	示例
每周节奏	固定安排 30 分钟的访谈时段	通过应用内提示招募参与者；轮流担任主持人
发现机会	从故事中提取需求并添加到 OST 上	数据导出的权宜之计成为一个机会节点
团队协作	公开分享快照	创建一块不断积累快照、呈现各种模式的看板

伦理界限： 切勿引导参与者得出特定结论——应围绕过往行为提出开放式问题，让故事自行揭示重要之处。

在开展访谈或设置招募流程时，请参阅 references/interview-snapshots.md——其中介绍基于故事的访谈结构、一页快照格式、如何综合分析多份快照，以及如何自动化每周招募。

4. 假设测试

核心概念： 在构建之前，找出解决方案所依赖的假设，按重要性和证据进行梳理，然后优先对风险最高的假设开展快速小规模测试。

为什么有效： 每个解决方案都建立在一系列关于吸引力、可行性、技术可行性和易用性的假设之上；大多数团队要么完全不测试，要么只测试容易验证的假设，结果花费数月打造建立在错误前提上的解决方案。

关键见解：

• 四类假设：吸引力（用户想要吗？）、可行性（我们能维持下去吗？）、技术可行性（我们能构建出来吗？）、易用性（用户会用吗？）
• 用 2x2 矩阵梳理：重要性 vs. 证据；重要性高、证据少的假设是需要优先测试的信念飞跃假设
• 设计能产生证据的最小测试：单题调查、伪装按钮测试、原型、数据挖掘
• 在开展测试前设定成功标准：“满足……即视为验证通过”
• 一项假设测试应耗时数天，而不是数周

产品应用：

场景	应用	示例
构建之前	测试首选候选方案中风险最高的假设	“用户会把报告分享给经理”→在构建分享功能前，先测试伪装按钮
比较解决方案	测试每个候选方案中风险最高的假设，快速淘汰较弱的选项	A 的风险最高的假设未通过，B 的通过 → 推进 B
降低路线图风险	找出已承诺功能中尚未测试的假设	Q3 功能假设用户想要实时通知——目前还没有证据

道德边界： 切勿欺骗参与者——伪装按钮测试应说明该功能即将推出，而不是在未作说明的情况下伪造功能。

为高风险假设设计测试时，请参阅 references/assumption-mapping.md——其中深入介绍了四类假设、重要性与证据的 2x2 矩阵、测试设计选项，以及如何为信念飞跃假设设定成功标准。

5. 机会优先级排序

核心概念： 不要孤立地看待机会，而要相互比较，并结合机会规模、市场、公司和客户因素，找出杠杆效应最大的押注。

为什么有效： 团队往往默认听从最强势的利益相关者、受近因偏差影响，或凭直觉做决定；结构化的逐项比较能促使团队明确讨论取舍，并在实施前暴露分歧。

关键见解：

• 相对比较优于独立评分
• 根据受影响客户数量、发生频率和严重程度评估机会规模
• 权衡战略契合度、团队能力和现有证据
• 快速做出足够好的决定，然后迅速学习——避免分析瘫痪
• 随着新证据出现，重新审视排序

产品应用：

场景	应用	示例
季度规划	为 OST 中排名靠前的 5-7 个机会排序	按照结构化标准比较“找不到内容”和“没有实时协作”
冲刺规划	选择当前证据最充分的机会	选择拥有最多访谈数据且解决方案可测试的机会
产品组合决策	根据风险和影响分配精力	60% 高置信度，30% 中等，10% 探索性

为排名靠前的机会排序时，请参阅 references/prioritization-methods.md——其中介绍了机会规模评估方法、对比技巧、数据权衡方法，以及如何避免分析瘫痪。

6. 培养习惯

核心概念： 持续发现只有成为三人小组可长期坚持的每周习惯才能发挥作用——自动化招募、建立轻量的固定流程，并将发现融入现有工作流，而不是把它当作额外工作。

为何有效： 如果发现工作依赖于“找时间”，每周都会输给交付压力；结构性支持（自动化招募、固定时段、共享材料）能免去每周都要做决定的麻烦，让习惯得以延续并不断积累成果。

关键见解：

• 三人小组的所有成员都要参与，而不只是 PM
• 自动化招募：应用内拦截、顾问小组、可填满时段的日程安排工具
• 在日历中预留固定的定期时段——依赖于“找时间”的发现工作永远不会发生
• 访谈结束后立即填写快照，不要等到几天后
• 从每周一次访谈开始；将见解关联到 OST，再纳入冲刺规划

产品应用：

场景	应用	示例
团队启动	在第一周建立节奏	自动化招募、预留周四时段、快照模板
扩大发现规模	从每周一次访谈增加到三次	增加一个流失用户时段和一个潜在客户时段
管理者支持	领导者保护时间并要求提供证据	在每次 1:1 中询问：“你这周从访谈中学到了什么？”

伦理边界： 尊重参与者的时间——访谈控制在 30 分钟内，给予合理报酬，绝不要把销售推销伪装成发现访谈。

根据你的场景调整这一习惯时，请参阅 references/case-studies.md——其中提供了 B2B SaaS、消费级移动应用、平台和增长团队中开展持续发现的完整案例演练。

常见错误

错误	失败原因	修正方法
将发现作为开发前的一个阶段	见解会过时；团队基于旧假设构建产品	将发现融入每周工作，与交付并行开展
只有 PM 与客户交流	设计师和工程师在信息传递中失去上下文	三人小组共同进行访谈
从结果直接跳到解决方案	跳过了机会空间	构建 OST，明确呈现机会空间
询问客户想要什么	得到的是功能请求，而不是需求	采用故事式访谈：“跟我说说上一次……的时候”
测试容易验证的假设，而非高风险假设	产生虚假的信心；致命假设未经检验	按重要性和证据绘制假设图；优先测试高风险假设
孤立地评估机会	看起来每个机会都很重要	使用结构化标准进行直接比较
集中访谈一阵，然后停止	学习成果无法累积	自动化招募；预留固定的定期时段

快速诊断

问题	如果否	行动
每周至少与一位客户交流一次？	决策缺乏新鲜证据	自动化招募；预留每周固定时段
是否有一个持续维护的机会解决方案树？	策略隐含不明，也未共享	根据你的结果和访谈数据构建 OST
三人小组是否全员参与访谈？	见解经过一个人的过滤	邀请设计师和工程师参加下一次访谈
是否在构建之前测试假设？	基于未经验证的前提下注	绘制下一个功能的假设图；测试风险最高的假设
能否将已发布的功能追溯到某个客户机会？	交付与发现脱节	将待办事项关联到 OST 中的机会
整个团队都能看到访谈快照吗？	知识只存在一个人的脑海中	建立共享快照看板，并在每次访谈后填写
是否在比较机会，而不只是列出它们？	优先级取决于主观意见	对排名前 5 的机会进行结构化比较

延伸阅读

基于 Teresa Torres 开发的持续探索框架：

• 《持续探索习惯：发现创造客户价值和商业价值的产品》，作者：Teresa Torres

关于作者

Teresa Torres 是一位作家、演讲者和教练，曾帮助数百个产品团队（从初创公司到 Capital One 和 Calendly）采用持续探索。她创建了机会解决方案树，撰写了广受欢迎的 Product Talk 博客，并将自己的教练实践提炼为《持续探索习惯》。