continuous-discovery

持续发现习惯框架

构建可持续的每周客户发现实践框架，使产品团队持续朝着期望成果前进。发现不是开发前的阶段——它嵌入在产品工作的持续节奏中，确保每个决策都有最新证据支持。

核心原则

好的产品发现需要持续节奏，而非一次性事件。 每周与客户交谈、可视化映射机会、在构建前测试假设的团队，始终优于依赖直觉、利益相关者意见或季度研究周期的团队。基准：产品三人组（产品经理、设计师、工程师）每周至少一次客户接触点。

评分

目标：10/10。 根据下方七项快速诊断标准对发现实践评分——从3分开始，每项回答“是”加1分（最高10分）。区间：9-10 = 每周节奏、活跃的机会解决方案树、系统化假设测试，每个发布的功能都可追溯到客户机会；5-6 = 有一些发现但临时、仅PM参与或与交付脱节；≤3 = 凭直觉和利益相关者驱动，无定期客户接触。报告当前分数、未达标项及每项的具体修复措施。

框架

1. 机会解决方案树

核心概念： 机会解决方案树（OST）将期望成果（顶部）与客户机会（中部）以及潜在解决方案和实验（底部）可视化连接，使隐性产品思维显性化并共享。

为何有效： 大多数团队从业务成果直接跳到解决方案，跳过客户需求；OST强制先理解机会空间，防止构建无人想要的功能。

关键见解：

• 四层：成果 > 机会 > 解决方案 > 实验
• 机会是客户需求、痛点和愿望——从客户视角表述
• 树是活的工件，随团队学习每周更新
• 将大机会拆分为更小的子机会以使其可操作
• 同时追求多个机会——不要孤注一掷

产品应用：

场景	应用	示例
季度规划	在承诺功能前映射机会空间	“提高试用转付费转化率” → 发现用户为何不转化
功能优先级排序	跨机会比较解决方案，找到最高杠杆赌注	针对“找不到内容”的三个方案 vs. 针对“混乱引导”的两个方案
利益相关者对齐	将树作为共享战略可视化	向领导解释为何选择机会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——深入介绍四种假设类型、重要性vs.证据2x2矩阵、测试设计菜单，以及如何为信念飞跃假设设定成功标准。

5. 机会优先级排序

核心概念： 将机会相互比较——而非孤立评估——使用机会规模、市场、公司和客户因素，找到最高杠杆赌注。

为何有效： 团队默认听从最响亮的利益相关者、近因偏见或直觉；结构化头对头比较迫使进行明确的权衡讨论，并在实施前暴露分歧。

关键见解：

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

产品应用：

场景	应用	示例
季度规划	对前5-7个OST机会进行排名	通过结构化标准比较“找不到内容” vs. “无实时协作”
冲刺规划	选择当前证据最强的机会	选择拥有最多访谈数据和可测试方案的机会
投资组合决策	按风险和影响分配精力	60%高置信度，30%中等，10%探索性

对顶级机会进行排名时，请参见 references/prioritization-methods.md——包含机会规模方法、对比技术、如何权衡数据，以及如何避免分析瘫痪。

6. 养成习惯

核心概念： 持续发现只有作为三人组的可持续每周习惯才有效——自动化招募、创建轻量级仪式，并将发现嵌入现有工作流程，而非视为额外工作。

为何有效： 依赖“找时间”的发现每周都会输给交付压力；结构性支持（自动化招募、固定时段、共享工件）消除了每周决策，使习惯得以持续并产生复利。

关键见解：

• 整个三人组参与——不仅仅是PM
• 自动化招募：应用内拦截、顾问小组、自动填充时段的排程工具
• 锁定重复日历时间——依赖“找时间”的发现永远不会发生
• 访谈后立即填写快照，而非数天后
• 从每周一次访谈开始；将洞察连接到OST，再从那里连接到冲刺规划

产品应用：

场景	应用	示例
团队启动	第一周建立节奏	自动化招募、锁定周四时段、快照模板
扩展发现	从每周一次增长到三次	增加流失用户时段和潜在客户时段
管理者支持	领导者保护时间并要求证据	每次一对一会议中问“这周从访谈中学到了什么？”

伦理边界： 尊重参与者时间——保持访谈30分钟，公平补偿，切勿将销售话术伪装成发现。

根据自身场景调整习惯时，请参见 references/case-studies.md——包含B2B SaaS、消费者移动端、平台和增长团队中持续发现的工作演练。

常见错误

错误	为何失败	修复
将发现作为开发前的阶段	洞察过时；团队基于旧假设构建	将发现嵌入每周工作，与交付并行
仅PM与客户交谈	设计师和工程师在传递中失去上下文	整个三人组一起访谈
从成果跳到解决方案	跳过机会空间	构建OST使其显性化
问客户想要什么	得到功能请求，而非需求	基于故事的访谈：“告诉我你上次……的经历”
测试容易的假设，而非风险高的	虚假信心；致命假设未测试	按重要性和证据映射；先测试高风险
孤立评分机会	每件事看起来都重要	使用结构化标准头对头比较
访谈爆发后停止	无复利学习	自动化招募；锁定重复时间

快速诊断

问题	如果否	行动
每周至少一次客户对话？	决策缺乏最新证据	自动化招募；锁定每周时段
有活跃的机会解决方案树？	战略隐性和未共享	从成果和访谈数据构建OST
三人组全部参与访谈？	洞察经过一人过滤	邀请设计师和工程师参加下一次
构建前测试假设？	在未测试前提上赌博	映射下一个功能的假设；测试风险最高的
能否将发布的功能追溯到客户机会？	交付与发现脱节	将待办项链接到OST机会
访谈快照对全团队可见？	知识困在一个人脑中	共享快照看板，每次访谈后填写
比较机会而非仅列出？	按意见排序	对前5个进行结构化比较

延伸阅读

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

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

关于作者

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