事前验尸
假设已经失败了，倒推原因
假设 [项目/计划] 半年后彻底失败了。请写一份事后复盘：1）最可能的 5 个失败原因，按概率排序；2）每个原因现在的早期信号是什么；3）哪些原因是可以现在就预防的；4）如果只能做一件事降低失败概率，是哪件。
适合什么场景
- 项目已立项、预算批了、排期已经发下去——此时改方向还来得及，但团队里已经没人愿意泼冷水。
- 上线前的最后一次评审，所有人都在讨论「怎么做得更好」，没有人问「如果它彻底失败会是什么样」。
不适合的场景
- 事情还没成形、只是一个想法时——半年后失败的原因会写得很泛（「需求不真实」），因为你还没做出任何可被检验的选择。
- 刚经历完一次真实失败、正在做事故复盘时——这时要用真实证据倒推，假设性的失败原因会把真因盖住。
示例
输入
我们计划 6 个月后上线付费会员（39 元/月），现在有 8000 个免费用户，月活 2600。
你会得到
期望 5 条按概率排序的原因，每条都能对上一个现在就能看的信号——比如「30 天留存只有 11%，说明还没形成使用习惯，付费无从谈起」。最后要收敛到一个本周就能做、成本最低的预防动作，而不是一份存档用的风险清单。
常见误用
- 把失败原因清单当风险登记表存起来，从不给每条配检查时点——半年后你只会发现自己当初在清单上打过勾。
- 只问「为什么失败」，不问「失败最早长什么样」：于是得到一堆正确但无法观测的原因（「市场竞争激烈」），一条也用不上。
可以这样改
- 把「半年后彻底失败」换成「半年后还活着但很难受」——多数项目不是猝死而是慢性消耗，这个问法挖出的原因更真。
- 加一句「哪些失败原因是我们在前两周亲手造成的」——把外部归因拉回到可控的动作上。