postmortem

---
name: postmortem
description: Use when /em:postmortem — Honest analysis of what went wrong. Use after a failed launch, missed quarter, or bad hire to run a blameless 5-Whys retrospective with a change register — e.g. dissecting w
category: C-Level Advisory
version: 1.0.0
tools: []
---

# /em:postmortem — Honest Analysis of What Went Wrong

**Command:** `/em:postmortem <event>`

Not blame. Understanding. The failed deal, the missed quarter, the feature that flopped, the bad hire. What actually happened, why, and what changes as a result.

## Why Most Post-Mortems Fail

Two patterns:
- **The blame session** — someone scapegoated, defensive walls up, no real causes examined
- **The whitewash** — "We learned a lot" with 12 vague action items and zero change

A real post-mortem rigorously investigates system failure. Not "whose fault" but "what conditions made this outcome predictable?"

**Purpose:** extract maximum learning value from failure to prevent recurrence.

## The Framework

### Step 1: Define the Event Precisely

Before analysis: 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. "$260K miss driven by three deals slipping to Q4 and one lost to competitor" is precise.

### Step 2: The 5 Whys — Done Properly

**Goal:** Get from symptom to root cause.

**Bad 5 Whys example:**
Why miss revenue? Deals slipped. Why? Longer sales cycle. Why? Enterprise is complex. Why? That's how enterprise works. → Conclusion: Nothing to do.

**Good 5 Whys example:**
Why miss revenue? Three deals slipped. Why? No champion with budget authority identified. Why? Qualification criteria outdated. Why? Moved upmarket 8 months ago. Why? No owner, no review process. → Root cause: Update criteria, assign owner, add quarterly review.

**Test for good root cause:** Could you prevent recurrence with a specific, concrete change?

### Step 3: Distinguish Contributing Factors from Root Cause

**Contributing factor:** Made it worse; if removed, outcome might differ, but same class of problem recurs.

**Root cause:** Fundamental condition making outcome probable. Fix this, this class doesn't recur.

Example — failed hire:
- Contributing factors: rushed process, reference checks skipped, pressure to staff
- Root cause: No defined competency framework; interview process varies by interviewer

### Step 4: Identify Warning Signs That Were Ignored

Every failure has precursors. In hindsight, obvious. The value is making them prospectively obvious.

Ask:
- At what point was negative outcome predictable?
- What signals were visible?
- Who saw them?
- Why weren't they acted on?

**Common patterns:**
- Signal raised but dismissed by senior person
- Signal not raised (unsafe to raise)
- Seen but no clear ownership
- Available data but no one looking
- Team too optimistic for negative signals

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

- **In control:** Process, criteria, team capability, resource allocation, decisions
- **Out of control:** Market conditions, customer decisions, competitors, macro events

For out-of-control: how to be more resilient?
For in-control: what specifically changes?

### Step 6: Build the Change Register

Every post-mortem ends with specific, owned, dated commitments.

**Bad action items:** "Improve qualification" / "Better communication" / "More rigorous forecasting"

**Good action items:**
- "Ravi owns rewriting qualification criteria by March 15; hard requirement = champion identification. Reviewed weekly starting March 22."
- "Elena adds deal-slippage risk flag to CRM for opps >60d without product demo by March 10"
- "Maria runs 30-min retrospective with sales team every 6 weeks starting April 1; reviews win/loss data"

**For each action:** What changes? Who owns it? By when? How will you verify?

### Step 7: Verification Date

Most commonly skipped step. Post-mortems are theater without this.

Set a verification date: "Review whether qualification criteria updated and deal-slippage rate improved at June board meeting."

---

**Version:** 1.0.0