Back to Details

postmortem

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/em:postmortem — Honest Analysis of What Went Wrong

/em:postmortem — 对问题根源的坦诚剖析

Command: 
/em:postmortem <event>
Not blame. Understanding. The failed deal, the missed quarter, the feature that flopped, the hire that didn't work out. What actually happened, why, and what changes as a result.
命令： 
/em:postmortem <事件>
不追责，重理解。无论是失败的交易、未达标的季度业绩、折戟的功能模块，还是不合适的招聘，都要弄清楚实际发生了什么、原因何在，以及后续要做出哪些改变。

Why Most Post-Mortems Fail

为何多数事后复盘以失败告终

They become one of two things:
The blame session — someone gets scapegoated, defensive walls go up, actual causes don't get examined, and the same problem happens again in a different form.
The whitewash — "We learned a lot, we're going to do better, here are 12 vague action items." Nothing changes. Same problem, different quarter.
A real post-mortem is neither. It's a rigorous investigation into a system failure. Not "whose fault was it" but "what conditions made this outcome predictable in hindsight?"
The purpose: extract the maximum learning value from a failure so you can prevent recurrence and improve the system.
它们往往会沦为以下两种情况之一：
追责大会 —— 有人被当作替罪羊，大家开始自我防御，真正的问题根源无人深究，最终同样的问题会换种形式再次出现。
粉饰太平 —— "我们学到了很多，以后会做得更好，这里有12条模糊的行动项。" 但实际上没有任何改变，同样的问题会在不同季度重演。
真正的事后复盘绝非如此。它是对系统故障的严谨调查。核心不是"这是谁的错"，而是"哪些条件导致这个结果在事后看来是可预见的？"
核心目的： 从失败中汲取最大的经验教训，从而避免重蹈覆辙并优化系统。

The Framework

实施框架

Step 1: Define the Event Precisely

步骤1：精准定义事件

Before analysis: describe exactly what happened.
  • What was the expected outcome?
  • What was the actual outcome?
  • When was the gap first visible?
  • What was the impact (financial, operational, reputational)?
Precision matters. "We missed Q3 revenue" is not precise enough. "We closed $420K in new ARR vs $680K target — a $260K miss driven primarily by three deals that slipped to Q4 and one deal that was lost to a competitor" is precise.
在分析之前，先准确描述实际发生的情况。
  • 预期结果是什么？
  • 实际结果是什么？
  • 结果差距首次显现是在何时？
  • 造成了哪些影响（财务、运营、声誉层面）？
精准性至关重要。"我们未达成第三季度营收目标"的表述不够精准。而"我们新增ARR为42万美元，目标为68万美元——差额26万美元主要源于3笔交易推迟到第四季度，以及1笔交易被竞争对手抢走"则足够精准。

Step 2: The 5 Whys — Done Properly

步骤2：5 Whys — 正确实施方法

The goal: get from what happened (the symptom) to why it happened (the root cause).
Standard bad 5 Whys:
  • Why did we miss revenue? Because deals slipped.
  • Why did deals slip? Because the sales cycle was longer than expected.
  • Why? Because the customer buying process is complex.
  • Why? Because we're selling to enterprise.
  • Why? That's just how enterprise sales works.
→ Conclusion: Nothing to do. It's just enterprise.
Real 5 Whys:
  • Why did we miss revenue? Three deals slipped out of quarter.
  • Why did those deals slip? None of them had identified a champion with budget authority.
  • Why did we progress deals without a champion? Our qualification criteria didn't require it.
  • Why didn't our qualification criteria require it? When we built the criteria 8 months ago, we were in SMB, not enterprise.
  • Why haven't we updated qualification criteria as ICP shifted? No owner, no process for criteria review.
→ Root cause: Qualification criteria outdated, no owner, no review process. → Fix: Update criteria, assign owner, add quarterly review.
The test for a good root cause: Could you prevent recurrence with a specific, concrete change? If yes, you've found something real.
目标：从表面问题（症状）深挖到根本原因。
错误的5 Whys示例：
  • 为何未达成营收目标？因为交易推迟了。
  • 为何交易推迟？因为销售周期比预期更长。
  • 为何？因为客户的采购流程很复杂。
  • 为何？因为我们面向企业客户销售。
  • 为何？企业销售本来就是这样。
→ 结论：无能为力，这就是企业销售的常态。
正确的5 Whys示例：
  • 为何未达成营收目标？3笔交易推迟到了下一季度。
  • 为何这些交易推迟？它们都没有确定拥有预算审批权的内部支持者（champion）。
  • 为何我们在没有确定内部支持者的情况下推进交易？我们的资质审核标准没有要求这一点。
  • 为何我们的资质审核标准没有要求这一点？8个月前制定标准时，我们的客户群体是SMB（中小企业），而非企业客户。
  • 为何当目标客户群体（ICP）转变后，我们没有更新资质审核标准？没有负责人，也没有标准审核流程。
→ 根本原因：资质审核标准过时，无负责人，无审核流程。 → 解决方案：更新标准，指定负责人，新增季度审核机制。
优质根本原因的检验标准： 是否可以通过具体、明确的改变来避免问题重演？如果是，那你找到了真正的根源。

Step 3: Distinguish Contributing Factors from Root Cause

步骤3：区分影响因素与根本原因

Most events have multiple contributing factors. Not all are root causes.
Contributing factor: Made it worse, but isn't the core reason. If removed, the outcome might have been different — but the same class of problem would recur.
Root cause: The fundamental condition that made the outcome probable. Fix this, and this class of problem doesn't recur.
Example — failed hire:
  • Contributing factors: rushed process, reference checks skipped, team under pressure to staff up
  • Root cause: No defined competency framework, so interview process varied by who happened to conduct interviews
The distinction matters. If you address only contributing factors, you'll have a different-looking but structurally identical failure next time.
多数事件都有多个影响因素，但并非所有都是根本原因。
影响因素： 会加剧问题，但并非核心原因。即使消除该因素，结果可能不同，但同类问题仍会重演。
根本原因： 导致结果必然发生的核心条件。解决这个问题，同类问题就不会再发生。
示例——招聘失败：
  • 影响因素：流程仓促、跳过背景调查、团队招聘压力大
  • 根本原因：未定义能力框架，导致面试流程因面试官不同而存在差异
这种区分至关重要。 如果你只解决影响因素，下一次仍会出现看似不同但本质相同的失败。

Step 4: Identify the Warning Signs That Were Ignored

步骤4：识别被忽略的预警信号

Every failure has precursors. In hindsight, they're obvious. The value of this step is making them obvious prospectively.
Ask:
  • At what point was the negative outcome predictable?
  • What signals were visible at that point?
  • Who saw them? What happened when they raised them?
  • Why weren't they acted on?
Common patterns:
  • Signal was raised but dismissed by a senior person
  • Signal wasn't raised because nobody felt safe saying it
  • Signal was seen but no one had clear ownership to act on it
  • Data was available but nobody was looking at it
  • The team was too optimistic to take negative signals seriously
This step is particularly important for systemic issues — "we didn't feel safe raising the concern" is a much deeper root cause than "the deal qualification was off."
每一次失败都有前兆，事后看来往往显而易见。这一步的价值在于让这些信号在事前也变得清晰。
思考以下问题：
  • 负面结果最早可在何时预见？
  • 当时有哪些可见信号？
  • 谁看到了这些信号？他们提出时发生了什么？
  • 为何没有采取行动？
常见模式：
  • 信号被提出，但被上级驳回
  • 没人敢提出信号，因为缺乏安全感
  • 看到了信号，但没有明确负责人采取行动
  • 数据可用，但没人关注
  • 团队过于乐观，未重视负面信号
这一步对于系统性问题尤为重要——"我们不敢提出担忧"比"交易资质审核存在问题"的根源更深。

Step 5: Distinguish What Was in Control vs. Out of Control

步骤5：区分可控与不可控因素

Some failures happen despite correct decisions. Some happen because of incorrect decisions. Knowing the difference prevents both overcorrection and undercorrection.
  • In control: Process, criteria, team capability, resource allocation, decisions made
  • Out of control: Market conditions, customer decisions, competitor actions, macro events
For things out of control: what can be done to be more resilient to similar events? For things in control: what specifically needs to change?
Warning: "It was outside our control" is sometimes used to avoid accountability. Be rigorous.
有些失败是尽管做出了正确决策仍会发生，有些则是因错误决策导致。明确二者的区别可以避免过度纠正或纠正不足。
  • 可控因素： 流程、标准、团队能力、资源分配、决策制定
  • 不可控因素： 市场环境、客户决策、竞争对手行动、宏观事件
对于不可控因素：如何增强对类似事件的韧性？ 对于可控因素：具体需要做出哪些改变？
警示： "这超出了我们的控制范围"有时会被用来逃避责任，需严谨判断。

Step 6: Build the Change Register

步骤6：建立变更登记册

Every post-mortem ends with a change register — specific commitments, owned and dated.
Bad action items:
  • "We'll improve our qualification process"
  • "Communication will be better"
  • "We'll be more rigorous about forecasting"
Good action items:
  • "Ravi owns rewriting qualification criteria by March 15 to include champion identification as hard requirement. New criteria reviewed in weekly sales standup starting March 22."
  • "By March 10, Elena adds deal-slippage risk flag to CRM for any open opportunity >60 days without a product demo"
  • "Maria runs a 30-min retrospective with enterprise sales team every 6 weeks starting April 1, reviews win/loss data"
For each action:
  • What exactly is changing?
  • Who owns it?
  • By when?
  • How will you verify it worked?
每一次事后复盘都要以变更登记册收尾——明确具体的承诺、负责人和截止日期。
糟糕的行动项：
  • "我们将优化资质审核流程"
  • "我们将加强沟通"
  • "我们将更严谨地进行预测"
优质的行动项：
  • "Ravi负责在3月15日前重写资质审核标准，将确定内部支持者列为硬性要求。新标准从3月22日起在每周销售站会中进行审核。"
  • "Elena需在3月10日前在CRM中添加交易推迟风险标记，针对任何超过60天未进行产品演示的在办机会。"
  • "Maria从4月1日起每6周与企业销售团队开展一次30分钟的回顾会，分析赢单/丢单数据。"
每个行动项需包含：
  • 具体要改变什么？
  • 负责人是谁？
  • 截止日期？
  • 如何验证行动有效？

Step 7: Verification Date

步骤7：验证日期

The most commonly skipped step. Post-mortems are useless if nobody checks whether the changes actually happened and actually worked.
Set a verification date: "We'll review whether qualification criteria have been updated and whether deal slippage rate has improved at the June board meeting."
Without this, post-mortems are theater.
这是最常被跳过的步骤。如果没人检查改变是否真的发生并奏效，事后复盘就毫无意义。
设定验证日期："我们将在6月的董事会会议上审核资质审核标准是否已更新，以及交易推迟率是否有所改善。"
没有这一步，事后复盘就只是走个过场。

Post-Mortem Output Format

事后复盘的输出格式

EVENT: [Name and date]
EXPECTED: [What was supposed to happen]
ACTUAL: [What happened]
IMPACT: [Quantified]

TIMELINE
[Date]: [What happened or was visible]
[Date]: ...

5 WHYS
1. [Why did X happen?] → Because [Y]
2. [Why did Y happen?] → Because [Z]
3. [Why did Z happen?] → Because [A]
4. [Why did A happen?] → Because [B]
5. [Why did B happen?] → Because [ROOT CAUSE]

ROOT CAUSE: [One clear sentence]

CONTRIBUTING FACTORS
• [Factor] — how it contributed
• [Factor] — how it contributed

WARNING SIGNS MISSED
• [Signal visible at what date] — why it wasn't acted on

WHAT WAS IN CONTROL: [List]
WHAT WASN'T: [List]

CHANGE REGISTER
| Action | Owner | Due Date | Verification |
|--------|-------|----------|-------------|
| [Specific change] | [Name] | [Date] | [How to verify] |

VERIFICATION DATE: [Date of check-in]
EVENT: [事件名称及日期]
EXPECTED: [预期结果]
ACTUAL: [实际结果]
IMPACT: [量化影响]

TIMELINE
[日期]: [发生的事件或可见情况]
[日期]: ...

5 WHYS
1. [为何X发生？] → 因为 [Y]
2. [为何Y发生？] → 因为 [Z]
3. [为何Z发生？] → 因为 [A]
4. [为何A发生？] → 因为 [B]
5. [为何B发生？] → 因为 [根本原因]

ROOT CAUSE: [清晰的一句话描述]

CONTRIBUTING FACTORS
• [因素] — 如何产生影响
• [因素] — 如何产生影响

WARNING SIGNS MISSED
• [某日期可见的信号] — 为何未采取行动

WHAT WAS IN CONTROL: [列表]
WHAT WASN'T: [列表]

CHANGE REGISTER
| Action | Owner | Due Date | Verification |
|--------|-------|----------|-------------|
| [具体变更内容] | [姓名] | [日期] | [验证方式] |

VERIFICATION DATE: [检查日期]

The Tone of Good Post-Mortems

优质事后复盘的基调

Blame is cheap. Understanding is hard.
The goal isn't to establish that someone made a mistake. The goal is to understand why the system produced that outcome — so the system can be improved.
"The salesperson didn't qualify the deal properly" is blame. "Our qualification framework hadn't been updated when we moved upmarket, and no one owned keeping it current" is understanding.
The first version fires or shames someone. The second version builds a more resilient organization.
Both might be true simultaneously. The distinction is: which one actually prevents recurrence?
追责易，理解难。
目标不是确定谁犯了错，而是理解为何系统会产生这样的结果——从而优化系统。
"销售人员未正确审核交易资质"是追责。 "当我们转向高端市场后，资质审核框架未更新，且无人负责维护其时效性"是理解。
第一种说法会解雇或羞辱某人，第二种说法则会打造一个更具韧性的组织。
两种说法可能同时成立。区别在于：哪一种能真正避免问题重演？