从目标成果出发，系统发掘用户机会，生成多个方案，设计实验验证。OST 强迫产品团队在做解决方案前先理解机会——这是持续发现的核心基础设施。
最常见的产品失败路径是这样的：业务设定了一个 OKR（提升留存率）→ 团队开会 → 有人说「我们应该加推送通知」→ 大家讨论推送通知要怎么做。从目标到方案，中间跳过了最关键的一步：发现用户的实际需求和痛点。
这个跳跃背后是方案偏见（Solution Bias）——人类大脑天然倾向于生成解决方案而非探索问题。一旦团队锁定了某个方案，后续的「用户研究」往往变成了为方案寻找支持，而不是真正探索机会。
OST 通过强制插入「机会层」打破这个循环。在确定任何方案之前，团队必须先问：「为什么留存率低？用户在哪个环节流失？他们未被满足的需求是什么？」只有当机会得到充分探索，方案才有意义。OST 还强制要求：每个方案必须对应一个实验，而不是直接进入开发排期——这是真正的「先学习后构建」。
以下是一棵真实的 OST 示例：目标成果是「提升周活跃用户数」，从根部向下展开两个主要机会分支，每个机会下挂载多个方案，方案下对应轻量实验。
OST 适合任何希望从「功能工厂」转变为「持续发现」模式的产品团队。它是一种工作方式，而不只是一次性工具。
Snyk 是一家开发者安全公司，帮助团队在代码中发现和修复安全漏洞。2020–2021 年，他们的目标是提升开发者采用率。传统方法可能直接跳到「增加更多集成」，但他们选择先系统地探索机会——每周持续访谈 20 名开发者，把发现的机会逐步构建成 OST。
OST 不是一次性工作坊，而是团队的持续工作方式。初次建立需要 1–2 小时；之后每周 30 分钟维护更新。关键是把 OST 嵌入团队的日常节奏，而不是让它成为一年一度的策略文档。
机会解决方案树（OST）由产品发现领域最具影响力的思想家之一 Teresa Torres 在多年产品教练实践中逐步发展成型，并于 2021 年通过著作《持续发现习惯》（Continuous Discovery Habits）正式系统化。它以可视化树状结构将结果目标、机会空间、解决方案和实验假设串联起来，帮助产品团队从"功能交付模式"转向"持续发现模式"。