需要把分散功能想法和用户研究连到可衡量成果并组织产品发现时…

在持续产品发现中，用机会解决方案树把期望成果、客户机会、候选解决方案和验证实验组织成一棵可沟通、可迭代的树。

适用场景

解决思路

1. 定义期望成果：从顶部开始写一个清晰、可衡量的业务或产品成果，且能通过产品改动影响；尽量量化，例如“将 30 天留存率从 40% 提升到 55%”。
2. 识别机会领域：向下分出 3-5 个机会领域，即客户需求或痛点可被解决的地方；机会不是解决方案，而是从客户视角表述的问题、需求或愿望。
3. 添加支撑证据：为每个机会记录支持证据，包括用户研究引语、行为数据、支持工单或市场趋势；强机会应有多个证据来源。
4. 头脑风暴解决方案：为每个机会生成 2-4 个候选解决方案；此阶段不要自我审查，方案可从快速实验到大型功能，但要具体到足以评估。
5. 定义假设测试：为每个有前景的解决方案找出风险最高的假设，并设计轻量级实验来测试；好测试验证该解决方案是否真的能解决对应机会。
6. 对树进行优先级排序：所有分支并非同等重要；根据潜在影响、置信度和投入，标记优先探索哪个机会和解决方案；树是活文档，随学习迭代。
7. 可视化结构：创建树状图展示层级——顶部是成果，下面是机会，每个机会下面是解决方案，叶子节点是实验。
8. 按输出格式落地：使用 references/TEMPLATE.md 组织输出；完整树应填满每个模板部分：期望成果、可视化树、机会分支、优先级、实验待办、学习日志、下一步。
9. 完成前校验成果：确认成果可衡量且在产品团队影响范围内。
10. 完成前校验机会：确认机会以客户为中心（是需求/问题，不是功能）。
11. 完成前校验证据：确认每个机会都有支撑证据记录。
12. 完成前校验方案：确认每个机会存在多个解决方案，而不是直接跳到唯一方案。
13. 完成前校验假设与实验：确认假设明确且实验已设计。
14. 完成前校验优先级：确认优先级清晰，明确先探索哪个分支。

适用边界 · 注意事项

• 需要对已知候选清单打分和排序时，改用 define-prioritization-framework；机会解决方案树用于发现和结构化，不是排序练习。
• 只需要为团队框定一个具体问题，或准备测试单个假设时，分别用 define-problem-statement 或 define-hypothesis、measure-experiment-design。
• 尚未就希望驱动的成果达成一致时，先用 foundation-okr-writer；没有已同意成果的树只会装饰意见。