用途：Outcome Thinking 用于把产品工作聚焦于结果而非产出，强调以“发生了什么改变”而不是“交付了什么”衡量成功。
主要能力：要求在定义方案前先定义期望结果；结果必须可衡量，例如“NPS 从 30 提升到 40”，而非“用户更满意”；区分 output（交付内容）与 outcome（交付后产生的变化）；建议用“[指标] 从 [当前状态] 移到 [目标状态] 于 [日期]”的格式表达结果；不接受把功能本身当作目标，功能只是实现目标的假设。
连接工作与结果：每项计划需有清晰假设，即“如果我们构建 X，指标 Y 会改善，因为 Z”；需能把任何团队当前工作连接到可衡量结果，连接不上就应质疑是否该列入路线图；建议把大结果拆解为团队可按周跟踪的前置指标；不应以“已交付”作为终点，而要测量后续发生了什么。
结果问责：上线后必须复盘结果，而非只庆祝发布；建议在计划开始时设定复盘日期；结果未达成时须诚实分析原因并调整；应区分“功能无效”与“测量过早”；不应在未弄清上一项目是否达成目标就进入下一项目。
与探索的平衡：并非所有工作都能预设结果，探索与学习是合理目标；应为探索工作设定学习结果，例如“到结束时我们会知道 X”；仍需定义探索性工作的“完成”标准；不应无限期用“我们在探索”作为缺乏方向的借口。
反模式包括：产出执念（以交付功能数量而非影响衡量成功）、结果表演（定义结果却从不上线后测量）、指标固着（优化指标的同时用户体验变差）、永久 MVP（持续交付最小版本却从不测量是否有效）、移动球门（结果出来后更改成功标准）。
使用方式：输入 /outcome-thinking 可将结果思维约束应用到当前对话；输入 /outcome-thinking <initiative> 可为所述计划定义结果。
限制：官方资料未提供具体收费、价格、平台或更详细的使用步骤，相关内容暂未提供。