复杂产品取舍决策：用框架、ROI 与向上沟通评估…

当面临 build vs buy、技术/设计投资、优先级排序或向高层解释取舍等竞争目标时，用它系统化决策。

适用场景

解决思路

1. 做框架选择：把当前取舍场景匹配到正确的决策模板，而不是从零开始讨论。
2. 做 ROI 计算：建模拟选路径的长期业务影响与运营成本。
3. 做干系人沟通：改进向领导呈现取舍的方式，让领导看到说“是”的隐藏成本。
4. 做偏差检测：识别当前思考中的沉没成本谬误、Just One More Engineer 神话等常见陷阱。
5. 在 shaping 阶段暴露兔子洞：让资深工程师尽早参与，在承诺高保真设计前识别技术复杂性和基础设施约束；Ryan Singer 类比：家装效果图再漂亮，若没检查墙里有没有电，成本和时间会剧变。
6. 量化不作为的风险：对重大技术或设计投入，比较现在做与不做的成本和风险；问 1 年以上对增长、质量、留存有多少收益？不做会怎样？成功概率多大？
7. 用 SaaS 满足基础需求：不要重造轮子，核心功能买第三方方案，把内部工程集中在专有层；Austin Hay 的理念是 build and buy now，买工具达到 90%，再用另外 10% 构建独特能力。
8. 使用 Five Techniques for Communicating Tradeoffs：用 Tara Seshan 的五步法把取舍讲清楚，防止领导默认“两个都做”。
9. 使用 Magic Lenses（4 Classic Lenses + Custom）：把多个产品方案绘制到多个 2x2 图表上，每个图表代表不同决策视角，以评估多方案。
10. 使用 Technical/Design Investment Evaluation Framework：对不直接驱动近期结果的大型技术/设计工作，用 Airbnb 的场景化评估框架决定是否投入。
11. 使用 Build AND Buy：用混合采购/构建框架替代二元 build vs buy 争论。
12. 使用 Traffic Light Decision Matrix：在会议中用颜色编码的视觉表格，按特定标准评估三个选项，替代扁平优缺点列表。
13. 使用 Weighted Decision-Making Spreadsheet：用加权标准电子表格评估选项。
14. 使用 The 'Optimizing For' Framework：用心理模型做优先级排序和取舍。
15. 使用 SCQA Tradeoff Decision Document：用 Situation-Complication-Question-Answer 框架、bottom-line-up-front 向领导呈现优先级取舍的结构化文档。
16. 使用 Should We Do This Ourselves? Document：用年度战略文档评估应自建内部能力还是使用第三方供应商。
17. 使用 Build/Buy/Partner decision framework for large companies：像 Atlassian 进入新市场时那样评估内部构建、收购还是合作。
18. 用澄清问题帮助用户：问“哪个单一澄清问题能帮团队过滤优先级并解决这个具体取舍？”
19. 问如果选择内部构建，预测的长期维护和运营成本是什么？
20. 问这个项目如何影响更广的公司路线图，相比团队具体目标？
21. 问开发开始后可能遇到哪些基础设施约束或技术兔子洞？
22. 问我们是在优化短期指标，还是在为巨大的长期客户价值打基础？
23. 问在什么具体条件下，备选决策会优于我们倾向的决策？
24. 标记二元 build-vs-buy 陷阱：团队常以为必须完全自建或买死板工具，而混合方案通常更高效。
25. 标记忽略英雄主义成本：领导常忽略短期硬推“两个都做”会如何随时间损害团队士气和运营稳定性。
26. 标记高估激进重设计成功率：激进变更统计上比渐进改进更可能失败，却常因感知上的简单而被选中。
27. 标记 Just One More Engineer 谬误：相信单个额外资源能修复根本上有缺陷的项目结构或竞争劣势。
28. 需要完整工件清单时查看 references/artifacts.md；需要 14 位嘉宾的 13 条来源洞察时查看 references/guest-insights.md。
29. 必要时结合相关技能：Roadmap Prioritization、Goal Setting Okrs、Planning Cadence、High Stakes Decisions。

适用边界 · 注意事项

• 决策简单、可逆、成本低时，不要使用重型框架；直接选一个快速验证。
• 没有足够数据或无法量化长期影响时，不要把 ROI 模型当作精确预测；需标注假设和不确定性。
• 紧急故障响应或需要立即执行时，不适合先做完整干系人沟通和框架评估。