Opportunity Solution Tree（机会解决方案树）

这棵树自上而下分四层阅读。根部是一个单一的期望成果——团队正在追逐的一个可衡量目标,比如提升激活率或缩短价值实现时间。其下分支出机会：以客户自己的语言表达的需求、痛点与渴望,通过持续发现被发掘出来。每个机会之下是候选解决方案,每个解决方案之下是验证该解决方案是否真的能推动该机会的假设检验或实验。

这个结构故意设计成一棵树,而不是一份清单。单一成果分支成许多机会,每个机会分支成若干解决方案,每个解决方案分支成多个测试。这种分支迫使团队在每一层都保留不止一个选项,这正是抵御「一开始就锁定第一个听起来靠谱的想法」的解药。

这棵树的作用是让发现决策变得可见、可被质疑。因为每个解决方案都能向上追溯到一个机会,每个机会又能追溯到成果,所以任何人都可以问「这满足了哪个客户需求,而这个需求又推动了哪个目标?」一个无法回答这些问题的功能,会在耗费一个 sprint 之前就被暴露为孤立无援的工作。

它还重新定义了优先级排序。团队不再对一份扁平的功能待办列表打分排序,而是先把机会对照成果进行比较——评估哪个需求一旦被解决最能推动目标——然后才在选定的分支内探索解决方案。Torres 把这称为「比较机会,而非比较解决方案」,这让像 RICE 这样的打分框架保持诚实,因为它确保被打分的条目是真正的客户需求,而不是预先包装好的功能。

最常见的失败是把解决方案伪装成机会来写。「增加一个 Slack 集成」是一个解决方案;真正的机会是「我记不住提及消息,因为它们存在于另一个工具里」。当机会层被功能填满时,这棵树就会坍缩成一份待办列表,其比较能力也随之消失。机会必须以客户需求的形式表达,使用客户的语言,与任何特定修复方案区分开来。

第二种失败是把这棵树当作一次性的产物。它本应随着每周新的访谈证据到来而演变——分支被增加、被修剪、被重新加权。一棵一个月都没有变化的树,通常说明发现工作已经悄然停止。第三个陷阱是完全跳过实验层,直接在某个机会下上线第一个解决方案,这会放弃这个结构本应强制执行的选项生成过程。

一棵 opportunity solution tree 的可信度,取决于每个分支下方证据的可信度。实践中,这些证据——访谈记录、支持工单、使用信号、提出该机会的账户背后的收入——通常存在于分散的工具里,于是机会容易从真实需求漂移回猜测,而成果也会失去与实际账户行为的关联。

像 AIOProductOS 这样的产品操作系统会把这些证据保存在一条共享主线上,使其可被关联：它的 Insights 信息流把反馈直接展示在 Customer-360 记录及其背后的收入旁边,于是一个机会在赢得一个分支之前,就能显示出是哪些付费账户提出了它,而根部的成果也能对照真实的产品分析进行追踪,而不是对照一个被复制到幻灯片里的数字。这棵树始终是一个发现工具;主线则让它下方的证据保持最新。