# Pre Mortem

> Run pre-mortem (Klein) and FMEA-style failure-mode analysis BEFORE shipping a plan, feature, launch, campaign, or strategic decision. Use whenever 用户 says "这个方案有什么风险" / "上线前最后过一遍" / "万一失败了什么原因" / "risk register" / "what could go wrong" / "事先复盘" / "失败推演". Forces "imagine it failed in 6 months — write the autopsy" perspective shift, distinguishes pre-mortem (causes) from FMEA (severity × probability × detectability), produces concrete risk register with mitigation owner. Stops optimism bias, surfaces blind spots before they ship. Self-contained methodology — no external docs required.

- Skill: `marsloting/pre-mortem` (Agent Skill)
- Install (CLI): `npx skillmds@latest add marsloting/pre-mortem`
- Raw SKILL.md: https://api.skillmd.com/api/skills/marsloting/pre-mortem/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: marsloting (https://skillmd.com/u/marsloting)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/marsloting/pre-mortem

---


# Pre-mortem 失败推演 + Risk Register

## 何时触发

- 任何方案 / 上线 / campaign / 战略决策定稿前
- "上线前最后过一遍"
- "这有什么风险"
- "万一 X 怎么办"
- 五维碰撞测试发现某维度有问题但不严重时（追加 pre-mortem 量化）
- 用户 表达"我感觉哪里不对但说不上来"
- 团队过度乐观信号（"肯定能做完" / "一定会成功"）

## 何时不触发

- 已经上线后的事故复盘 → 用 `root-cause`
- 单一选项是否做的二元决策 → 用 `decision-matrix`
- 创意发散阶段（pre-mortem 是收敛阶段工具）

## 核心方法：Klein Pre-mortem

**Gary Klein 1989 经典方法**——把 post-mortem 提前。

### 视角切换（关键）

不要问："这个方案会有什么风险？"（人会下意识防守）

要问：**"假设 6 个月后这个方案彻底失败了。现在写一份 autopsy——失败的原因都有哪些？"**（视角切换 → 大脑进入归因模式 → 风险被主动挖出）

### 5 步流程

#### Step 1：场景设定

```
现在是 <T+6 个月> / <上线后 X 周> / <campaign 结束后>
方案 / 项目 / 决策已经彻底失败
你正在写失败 autopsy
```

明确"失败"的具体形态：用户没用 / 业务指标没达 / 团队解散 / 老板砍项目 / 技术债不可维护 / 法务被告 / 公关危机。

#### Step 2：穷举失败原因（每人独立写）

每个参与者**独立**列出至少 5 条失败原因。**不要先讨论**——独立列完后再合并。

理由：群体讨论会触发从众效应，独立列才能拿到 diverse 输入。

类型清单（每类至少 1 条）：

| 类别 | 检查点 |
|---|---|
| **用户层** | 用户根本不需要 / 用户用法和我们想的不一样 / 用户切换成本太高 |
| **市场层** | 竞品先发 / 时机错 / 用户教育成本太高 |
| **技术层** | 实现复杂度被低估 / 性能不满足 / 第三方依赖崩 / 数据迁移踩坑 |
| **团队层** | 关键人离职 / 技能不匹配 / 沟通断 / 优先级被抢 |
| **流程层** | 评审流程没走完 / 法务卡住 / 安全 review 不过 |
| **外部层** | 政策变 / 合作方违约 / 黑天鹅事件 |

#### Step 3：合并 + 概率 / 影响 评分（FMEA 量化）

合并所有人列的原因，去重。每条按 FMEA 三维评分：

| 维度 | 含义 | 范围 |
|---|---|---|
| **Severity (S)** | 失败影响多大 | 1 (轻微) - 10 (灾难) |
| **Probability (P)** | 多大可能发生 | 1 (几乎不) - 10 (高度可能) |
| **Detectability (D)** | 多容易事先发现 | 1 (容易) - 10 (难) |

**RPN (Risk Priority Number) = S × P × D**，最高 1000，最低 1。

#### Step 4：Risk Register（按 RPN 降序）

```markdown
| ID | 失败原因 | S | P | D | RPN | Mitigation 动作 | Owner | 截止 |
|---|---|---|---|---|---|---|---|---|
| R1 | <原因 1> | 8 | 6 | 7 | 336 | <具体动作> | 用户 | 5-15 |
| R2 | <原因 2> | 9 | 4 | 3 | 108 | <具体动作> | F | 5-12 |
| ... |
```

**红线**：
- RPN > 200 → 必须有 mitigation，mitigation 不到位前不上线
- 100 < RPN ≤ 200 → 必须有 mitigation 计划，可上线但盯紧
- RPN ≤ 100 → 标记观察，无 mitigation 也可上线

#### Step 5：Mitigation 类型（按降序选）

1. **Eliminate**：消除根因（最优）—— 改方案让风险不存在
2. **Reduce probability**：降低发生概率
3. **Reduce severity**：降低发生时影响（feature flag / staged rollout）
4. **Improve detectability**：提早发现（监控 / alert / canary）
5. **Transfer**：转移风险（保险 / 合同条款）
6. **Accept**：接受风险（写进 decisions-log，不再 mitigation）

## 模板（完整 pre-mortem 输出）

```markdown
# <方案名> Pre-mortem

## 场景设定
- 失败时点：<T+X 月>
- 失败定义：<用户没用 / 业务指标没达 / ...>

## 独立列出的失败原因（合并去重前）

### 用户 列的：
1. ...
2. ...

### F 列的：
1. ...
2. ...

## Risk Register

| ID | 原因 | S | P | D | RPN | Mitigation | Owner | 截止 |
|---|---|---|---|---|---|---|---|---|
| R1 | ... | 8 | 6 | 7 | 336 | ... | 用户 | 5-15 |

## 红线决策
- 不上线条件：RPN > 200 的项 mitigation 不到位
- 当前 ≥ 200 项：R1, R3, R7
- 当前 mitigation 状态：R1 done / R3 in progress / R7 owner 未定
- **结论**：暂不上线，等 R3 + R7 mitigation 完成

## Accept 类风险（不再 mitigation）
- R12: ... 接受理由：成本过高 / 概率过低 / 已有补偿机制
```

## Anti-Rationalization

| 逃逸路径 | 为什么不行 |
|---|---|
| "感觉风险都列得差不多了" | 每人独立列 5 条最低线。少于 5 条 = 没认真挖。"差不多了"是乐观偏差信号 |
| "我们没踩过这种坑应该不会发生" | 没踩过 = 你的样本不全，不等于不会发生。pre-mortem 是借助"假设它发生了"绕过经验偏差 |
| "RPN 200 红线太严了，业务等不及" | 红线是默认值。要降低必须 decisions-log 留痕 + 用户 拍板 + 接受 R-X 后果 |
| "Mitigation 写'盯紧点'就行" | "盯紧点"不是 mitigation。必须有具体动作 + owner + 截止时间。"盯紧"= 没人负责 = 没人做 |
| "S/P/D 评分主观不准" | 主观不等于无用。三人独立评分取平均 → 差异 > 3 时讨论 → 收敛。比"凭感觉判断风险"准一个数量级 |
| "FMEA 太工业化不适合 SaaS" | FMEA 是质量工程通用方法，跨行业有效。SaaS 风险天然契合 S/P/D 三维 |
| "项目小不需要 pre-mortem" | 项目小 = 5 步走 30 分钟。不做的成本 = 上线踩坑后 5-10 倍返工成本。不存在"小到不用 pre-mortem"的方案 |
| "悲观假设打击士气" | Klein 原始研究：pre-mortem 反而提升团队信心，因为风险被显式管理而不是悬空。"打击士气"是回避真正问题的借口 |

## 与五维碰撞测试的关系

- **五维碰撞**（collision-test）：从机制 / 协议设计角度做静态推演（计算时序 / 同类竞争 / 跨层 / 修饰叠加 / 人类认知）
- **Pre-mortem**：从场景失败角度做动态推演（用户 / 市场 / 技术 / 团队 / 流程 / 外部）
- 两者**不替代**：方案设计前过五维碰撞，方案上线前过 pre-mortem

## 关联

- 上线后真出事 → `root-cause` 5 Whys / Fishbone 找根因
- Risk Register 中的 mitigation 动作进 sprint → `product-management:sprint-planning`
- 高 RPN 项需要 A/B 验证 → `gtm-ops:growth-engine`
- 写 risk register 时套五维碰撞 → `collision-test`

## Status

v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。