Pre mortem
7 self-contained product-thinking skills that make an AI agent reason like a sharp PM before it acts. MIT.
npx -y skills add marsloting/product-thinking-pack --skill pre-mortemAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.md
7.2 KB, as published. Nobody here has run it
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 降序）
| 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 类型（按降序选）
- Eliminate：消除根因（最优）—— 改方案让风险不存在
- Reduce probability：降低发生概率
- Reduce severity：降低发生时影响（feature flag / staged rollout）
- Improve detectability：提早发现（监控 / alert / canary）
- Transfer：转移风险（保险 / 合同条款）
- Accept：接受风险（写进 decisions-log，不再 mitigation）
模板（完整 pre-mortem 输出）
# <方案名> 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-cause5 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 首发。