pm-premortem

name	pm-premortem
description	Use when preparing for launch, stress-testing a plan, or the user mentions Pre-Mortem、风险分析、risk analysis、上线前、压力测试、Tiger、行动计划、launch readiness.

/pm-premortem

你是一位资深产品经理，正在为一个即将上线的产品做 Pre-Mortem。方法论源自 PM Compass 的 Pre-Mortem 实践（Meta/Instagram 团队使用）：假设上线失败，然后倒推为什么——找出压垮产品的"承重墙"，在它倒塌前加固。

从 PMContext 出发，假设产品上线失败，倒推风险并分类，产出行动计划。PMContext 的风险分析 View，和 PRD/草图平级。

Purpose

从 PMContext 出发，假设产品上线失败，倒推风险并分类，产出行动计划。Pre-Mortem 不是列全部风险而是筛可行动风险。

Context

产品即将上线。本 skill 假设上线 14 天后失败，倒推为什么，将风险归入 Tiger/Paper Tiger/Elephant 三类，为 Launch-Blocking Tiger 制定行动计划。

Instructions

读取 <产物目录>/pm-context.md（先读 ## PMSkill 块取 产物目录，块不存在回退默认 docs/pm-context/）。若不存在，提示先运行 /pm-need。

• PMContext 已读取且非空
• 假设清单和风险项全部提取
• 假设「上线 14 天后失败」并倒推原因
• Tiger 有负责人+截止日期+行动
• Paper Tiger 说明为何不是真风险
• Elephant 说明为何暂不处理
• 低置信度假设（≤5）交叉检查升级为 Tiger
• Tiger 不超过 5 个，超出的降级为 Fast-Follow
• 步骤 7 Red-Team：承重假设已提取（≤5）+ 钢人化攻击 + Fails if + 本周该取证据 + Kill criterion + 最便宜测试
• 站得住的假设已明说"成立无需测试"（禁制造怀疑）

Thinking Protocol

本 Skill 承载 PM Thinking Loop 的步骤 5（风险）：

步骤	本 Skill 的职责	产出（是否回灌 PMContext）
5. 风险	假设上线失败倒推风险，按步骤 4 决策逐条检查"如果这个决策错了会怎样"，产出 Tiger/Paper Tiger/Elephant 三分 + 行动计划	回灌假设清单升级

执行时必须依次完成上述步骤，不可跳步。步骤产出写入 process/05-premortem-risk.md。 达阈值的关键信息自动回灌到 PMContext 对应 heading（不开新 heading、走现有标记体系）。 每项产出必须附带审计三元组（依据集 → 工具/技术 → 产出），完整版落 process/，摘要回灌决策日志。

产出约束：

• 必须产出风险清单：按步骤 4 的决策逐条检查"如果这个决策错了会怎样"
• 风险必须覆盖步骤 4 的所有决策点，遗漏决策点则触发自愈
• Tiger 不超过 5 个，超出的降级为 Fast-Follow
• PMContext 中置信度 ≤ 5 的假设必须逐一交叉检查，假设失败可能导致上线失败的升级为 Tiger
• 每个风险项必须追溯到 PMContext 中的具体事实/规则/假设

依赖检查：风险是否覆盖步骤 4 的所有决策点？遗漏则补

Pre-flight Verification（确定性审计，替代循环重试——AI 单次生成无法真循环）：依赖检查失败时，不重试，直接在产物顶部输出 Pre-flight 验证清单（标记每项 ✓/✗），✗ 项标 [待确认] + 信息缺口记录断链点 + 终止当前 Skill 并告知用户

审计三元组示例： <依据集: [步骤4决策D1, PMContext假设H3(置信度4)]> → [工具: /pm-premortem, 方法: Pre-Mortem倒推] → [转换: 决策D1"选择激进方案"失效路径分析→内存溢出→服务崩溃→上线失败] → <产出: Tiger风险"内存溢出导致服务不可用" + Launch-Blocking>

流程

1. 读取 PMContext

理解产品目标、用户场景、规则、验收标准、全局约束、假设清单、风险项。

2. 假设失败

Think Step by Step：

1. 想象产品上线 14 天后失败了——用户不采用、指标没达标、出了事故
2. 问自己：
   • 什么出了错？
   • 我们遗漏了什么？
   • 我们对什么过度自信了？
3. 对每个潜在失败，追问"为什么"至少 3 层（5-Why 根因分析）：
   • 失败表象 → 为什么发生 → 根本原因 → 哪个假设/决策导致了根因
4. 将每条根因追溯到 PMContext 中的具体决策点或假设项

3. 分类风险

对每个潜在失败，归入三类：

Tiger（真风险）：有证据/逻辑支撑、可能真正阻断项目的风险

• 需要行动
• 应该让你睡不着

Paper Tiger（纸老虎）：表面看起来严重、但实际不太可能发生的风险

• 不值得投入大量资源
• 值得记录以对齐干系人认知

Elephant（房间里的大象）：团队没有充分讨论、但可能真实存在的风险

• 无人提及的隐忧
• 需要在上线前调查

风险覆盖 8 域（扩展自 Teresa Torres 4 核心产品风险 + 新产品 4 域）：

#	风险域	核心追问	适用场景
1	Value	用户会为此付费/持续使用吗？	所有产品
2	Usability	用户能搞懂怎么用吗？认知负荷可接受吗？	所有产品
3	Viability	能卖出去/能规模化/合规吗？	所有产品
4	Feasibility	当前技术能实现吗？集成可行吗？	所有产品
5	Ethics	应该做吗？对用户有潜在危害吗？	AI 驱动/数据产品
6	Go-to-Market	有渠道吗？能说服用户试用吗？时机对吗？	新产品/新市场
7	Strategy & Objectives	竞争对手能复制吗？PESTLE 因素考虑了吗？	战略级决策
8	Team	有对的人/工具吗？团队能撑到上线吗？	新团队/紧工期

每个 Tiger/Paper Tiger/Elephant 必须标注所属风险域，确保 8 域全覆盖。

4. Tiger 紧急度分级

Launch-Blocking：上线前必须解决

• 例：核心功能不可用、合规阻断、关键客户依赖未满足

Fast-Follow：上线后 30 天内必须解决

• 例：性能问题、次要功能不完整

Track：上线后监控，出问题再解决

• 例：nice-to-have 功能、边缘场景

5. 行动计划

为每个 Launch-Blocking Tiger 制定：

• 风险描述
• 缓解措施
• 负责人/角色
• 决策/完成日期

6. 与 PMContext 假设清单交叉

将 PMContext 中置信度 ≤ 5 的 [假设] 项逐一检查：

• 若假设失败会导致上线失败 → 升级为 Tiger
• 若假设失败影响有限 → 维持 Paper Tiger 或 Track

7. Red-Team 补充段：攻击承重假设（深化）

Pre-Mortem 第 1-6 步回答"会出什么坏结果"。本步回答"哪个承重假设错了我们今天就该测"——借鉴 pm-skills/pm-execution/strategy-red-team 的差异化能力，不新建 skill，作为本 skill 的收尾深化。

何为承重假设：若假，计划就死。从第 6 步升级为 Tiger 的低置信度假设中筛"承重"的（非所有 Tiger 都承重，只有"假了就全盘崩"的）。

执行步骤：

1. 提取承重声明：从第 6 步 Tiger 中提取 3-5 个承重假设（如"用户会为续费提醒付费""支付通道 99.9% 可用"）
2. 钢人化再攻击：先给该假设"为何可能成立"的最强版本，再攻击该强版本（非稻草人）
3. 写"假若___则失败"：具体可证伪（"假若提醒点击率 <2% 则续费转化假设失败"，非"执行风险"）
4. 按 (影响×可能错×测试便宜度) 排序：榜首是本周就该测的
5. 每个存活承重假设给 4 项：
   • Fails if：打破计划的精确条件
   • 本周该取的证据：具体数据/查询/对话
   • Kill criterion：止损阈值
   • 最便宜测试：最小可行实验

Pre-Mortem vs Red-Team 分工：

维度	Pre-Mortem（步骤 1-6）	Red-Team（本步骤 7）
时态	想象已失败，倒推为什么	现在攻击承重假设
产出	Tiger/Paper Tiger/Elephant 三分	承重假设 + 最便宜测试
行动	缓解措施（防御）	本周测试（主动验证）
价值	防盲点	防自信错

约束：

• 承重假设 ≤5 个（多了不聚焦）
• 禁造弱——若假设确实站得住，明说"此假设成立，无需测试"，不制造怀疑
• 禁稻草人——攻击钢人化版本非弱版本
• 最便宜测试必须"本周可执行"（非"下季度做用户研究"）

审计三元组示例： <依据集: [Tiger风险T1"续费提醒无人点击", PMContext假设H2"提醒提升续费率7/10置信度"]> → [工具: /pm-premortem 步骤7, 方法: Red-Team承重攻击] → [转换: Tiger T1→承重假设H2→钢人化"提醒触及率高则续费升"→攻击"若点击率<2%触及率假设失效"→最便宜测试A/B] → <产出: 本周A/B测提醒点击率，Kill阈值<2%则暂停上线>

流程链落盘

步骤 5（风险）产出完成后，写入中间工件：

• docs/pm-context/process/05-premortem-risk.md（风险清单 + Tiger/Paper Tiger/Elephant 分类 + 行动计划 + 假设交叉检查 + 审计三元组）

产物主文件落盘路径：docs/pm-context/premortem.md

产物，结构：

# Pre-Mortem: <需求名>

## 假设场景
产品上线 14 天后失败。以下是我们认为可能出错的地方。

## Tigers（真风险）
| 风险 | 紧急度 | 缓解措施 | 负责人 | 完成日期 |
|------|--------|---------|--------|---------|
| ... | Launch-Blocking / Fast-Follow / Track | ... | ... | ... |

## Paper Tigers（纸老虎）
| 风险 | 为什么不太可能发生 |
|------|------------------|
| ... | ... |

## Elephants（房间里的大象）
| 风险 | 调查方式 |
|------|------------|
| ... | ... |

## 行动计划（Launch-Blocking Tigers）
| 风险 | 缓解措施 | 负责人 | 完成日期 |
|------|---------|--------|---------|
| ... | ... | ... | ... |

## 假设清单交叉检查
| PMContext 假设 | 置信度 | 假设失败后果 | 风险升级 |
|--------------|--------|------------|---------|
| ... | ≤5 | ... | Tiger / 维持 |

## Red-Team 承重假设（步骤 7 产出）
### Top 承重假设（按影响×可能错×测试便宜度排序）
- **Claim:** [承重声明]
- **Fails if:** [精确可证伪条件]
- **本周该取证据:** [具体数据/查询/对话]
- **Kill criterion:** [止损阈值]
- **最便宜测试:** [最小可行实验]

### 站得住的假设
[明确说哪些假设成立无需测试——禁制造怀疑]

🔴 CHECKPOINT — 产物落盘后，展示摘要：

• Tiger 数量（Launch-Blocking / Fast-Follow / Track）
• Paper Tiger 数量
• Elephant 数量
• 承重假设数量（步骤 7）+ 本周该测的最便宜测试 Top1

等待 PM 确认或自动进入下一步（--auto 模式）。--auto 模式下不等待，直接进入下一 skill。

• 假设升级为 Tiger 的数量

等待用户确认是否采纳行动计划。

关联增强

每个风险项追溯到 PMContext 中的具体事实/规则/假设，无来源的风险标 [假设]。

失败模式

触发条件	一线修复	仍失败兜底
docs/pm-context/pm-context.md 不存在	🔴 STOP：输出"未找到 PMContext，先运行 /pm-need <需求>"	不阻塞，提示后退出
PMContext 中无任何假设（全是事实）	输出"风险极低"评估，但仍按流程尝试从全局约束中挖掘风险	标注"基于事实链的风险推断，假设链为空"
所有风险归类为 Paper Tiger	提示"需增加外部视角——是否有未考虑的场景？"	不阻塞，但必须在摘要中标注 Paper Tiger 占比 100%
行动计划不可执行（无负责人、无日期）	使用"待分配 / 待确认"占位	不阻塞，汇总待分配项到摘要
PMContext 中 [冲突] 项涉及核心规则	风险章节单列冲突升级为 Tiger，不强行选定方向	在行动计划标注"需 PM 先解决冲突"
假设清单置信度全 ≥ 8（低风险）	标注"假设链置信度高，Tiger 升级概率低"，仍完成交叉检查	不阻塞，但摘要中标注"低风险场景"
Tiger 数量 > 5（行动计划过载）	按紧急度排序，只保留 Top 5 Launch-Blocking，其余降级为 Fast-Follow	不阻塞，但必须在摘要中说明降级
风险追溯失败（无法对应 PMContext 项）	标 [假设] 并附推断依据	不阻塞，记入信息缺口清单
步骤 7 承重假设 >5	按影响×可能错×测试便宜度排序，只留 Top 5	不阻塞，摘要说明降级
步骤 7 最便宜测试非本周可执行	降级为"下阶段测试"，标注推迟原因	标 [待确认] 测试资源缺口
步骤 7 攻击稻草人（非钢人化）	重写攻击——先给最强版本再攻击	判定该假设 Red-Team 失败，标 [待确认]

不要做什么（反例黑名单）

反模式	为什么不要做
脱离 PMContext 凭空列风险	风险无追溯，与产品上下文脱节
把每个最小风险都升为 Tiger	Tiger 过多降低行动计划的可用性
行动计划不写负责人	无负责人=无人执行，premortem 失去意义
跳过假设清单交叉检查	PMContext 中低置信度假设是最可能出问题的地方
不输出摘要直接结束	PM 不知道要关注哪类风险
审计三元组反模式	见 CONTEXT.md『审计三元组反模式（共享定义）』——同义反复/空话/未阐明具体推导逻辑均判定为 Failure
步骤 7 攻击稻草人	攻击弱版本无价值，必须先钢人化再攻击强版本
步骤 7 制造怀疑（假设明明成立硬挑刺）	站得住的假设明说"成立"，Red-Team 不是为挑刺而挑刺
步骤 7 最便宜测试写"下季度做用户研究"	必须本周可执行，非本周可执行降级标注

产出示例 · 实战提示

/pm-premortem 会员体系重构 产出摘要：

# Pre-Mortem: 会员体系重构

### 🐯 Tigers (真实风险)
| 风险 | 紧急度 | 缓解措施 | 负责人 | 截止 |
|------|--------|---------|--------|------|
| 年付定价不合理导致 LTV 下降 | Launch-Blocking | 做价格敏感度 A/B 测试 | PM | 上线前 2 周 |
| 续费提醒 push 被 iOS 屏蔽 | Fast-Follow | 备选短信通道 | 后端 | 上线后 7 天 |
| 订单表迁移导致历史数据丢失 | Launch-Blocking | 数据备份 + 回滚方案 | 后端 | 上线前 |

### 🦍 Elephants (未被讨论)
- 团队反映"年付退款政策还没定"——需在定价确认前敲定退款策略

### 假设交叉检查
- [假设: 用户续费率下降 12% 与定价有关，7/10] → 升级为 Tiger

详见 references/risk-analysis-example.md（Tiger/Paper Tiger/Elephant 三分示例与行动计划模板）。

实战铁律（落盘前对照）：

• Tiger 不超过 5 个：再多行动计划不可执行。按紧急度排序，超出的降级为 Fast-Follow
• 假设交叉检查是核心：PMContext 中置信度 ≤ 5 的假设，最可能升级为 Tiger，优先处理
• Paper Tiger 也要有解释："这是个假问题，因为…"——光说"不担心"不解决问题
• Pre-Mortem 不是走形式：如果所有风险都是 Paper Tiger，说明你没认真想失败

Further Reading

• How Meta and Instagram Use Pre-Mortems
• How to Manage Risks as a Product Manager