postmortem
alirezarezvani/claude-skills
Blameless 5-Whys analysis to extract learning from failures and build a change register.
What is postmortem?
Run a structured post-mortem on a failed launch, missed target, or bad hire using a rigorous 5-Whys framework. This skill guides you through defining the event precisely, identifying root causes vs. contributing factors, surfacing missed warning signs, and building a concrete change register with owned, dated actions to prevent recurrence.
- Define events precisely with expected vs. actual outcomes and quantified impact
- Conduct proper 5-Whys analysis to move from symptoms to root causes
- Distinguish contributing factors from systemic root causes
- Identify warning signs that were visible but ignored
- Separate controllable factors from external conditions
- Generate a change register with specific, owned, dated actions and verification methods
How to install postmortem
npx skills add https://github.com/alirezarezvani/claude-skills --skill postmortemHow to use postmortem
- 1.Run the command `/em:postmortem <event>` with a brief description of what failed
- 2.Define the event precisely: expected outcome, actual outcome, when the gap became visible, and quantified impact
- 3.Work through the 5 Whys systematically, drilling down from symptoms to root causes
- 4.Distinguish contributing factors (made it worse) from root causes (fundamental conditions that made the outcome probable)
- 5.Identify warning signs that existed but were ignored, and why they weren't acted on
- 6.Classify what was in your control vs. outside your control
- 7.Build a change register with specific actions, owners, due dates, and verification methods
- 8.Set a verification date to check whether changes were implemented and actually worked
Use cases
- Analyzing why a product launch slipped six weeks and building process changes to prevent recurrence
- Examining a missed quarterly revenue target to identify broken qualification criteria or forecasting gaps
- Investigating a failed hire to uncover gaps in competency frameworks or interview processes
- Understanding why a major deal was lost to a competitor and updating sales strategy accordingly
- Reviewing a product feature that flopped to determine whether it was market timing, positioning, or execution
- Engineering and product leaders reviewing failed launches or technical setbacks
- Sales leaders analyzing missed revenue targets or deal losses
- Founders and executives conducting organizational post-mortems
- Team leads investigating process breakdowns or team performance issues
- Anyone responsible for preventing recurrence of system failures
postmortem FAQ
A contributing factor made the outcome worse but isn't the core reason—removing it might change the outcome but the same class of problem recurs. A root cause is the fundamental condition that made the outcome probable; fixing it prevents recurrence of that class of problem. The distinction matters because addressing only contributing factors leads to structurally identical failures in different forms.
Most post-mortems stop at surface-level explanations ('deals slipped because the sales cycle was longer'). Proper 5-Whys drilling gets to systemic causes ('qualification criteria weren't updated when ICP shifted, and no one owned keeping them current'). The test: could you prevent recurrence with a specific, concrete change? If yes, you've found something real.
Good action items are specific, owned, and dated. Instead of 'improve qualification process,' write 'Ravi owns rewriting qualification criteria by March 15 to include champion identification as hard requirement, reviewed weekly starting March 22.' Include how you'll verify it worked.
Distinguish what was in control from what wasn't. For external factors, ask what can be done to be more resilient to similar events. For controllable factors, specify what needs to change. Both may apply—the goal is understanding, not blame.
Without it, post-mortems are theater. Set a specific date to review whether changes were actually implemented and whether they reduced recurrence. This is the most commonly skipped step and the difference between learning and forgetting.
Full instructions (SKILL.md)
Source of truth, from alirezarezvani/claude-skills.
name: "postmortem" description: "/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 why the Q3 release slipped six weeks."
/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 hire that didn't work out. What actually happened, why, and what changes as a result.
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.
The Framework
Step 1: Define the Event Precisely
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.
Step 2: The 5 Whys — Done Properly
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.
Step 3: Distinguish Contributing Factors from Root Cause
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
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
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
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?
Step 7: Verification Date
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.
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]
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?
Related skills
More from alirezarezvani/claude-skills and the wider catalog.
product-manager-toolkit
Comprehensive toolkit for product managers including RICE prioritization, customer interview analysis, PRD templates, discovery frameworks, and go-to-market strategies. Use when prioritizing features, synthesizing user research, writing requirement documentation, or developing product strategy.
product-skills
Router for 12 product skills: prioritization, OKRs, UX research, design, analytics, experiments, discovery, roadmaps, and scaffolding.
product-strategist
Strategic product leadership toolkit for Head of Product covering OKR cascade generation, quarterly planning, competitive landscape analysis, product vision documents, and team scaling proposals. Use when creating quarterly OKR documents, defining product goals or KPIs, building product roadmaps, running competitive analysis, drafting team structure or hiring plans, aligning product strategy across engineering and design, or generating cascaded goal hierarchies from company to team level.
promote
Graduate proven patterns from auto-memory to permanent project rules.
qms-audit-expert
ISO 13485 internal audit expertise for medical device QMS. Covers audit planning, execution, nonconformity classification, and CAPA verification. Use when planning internal audits, executing audits, classifying findings, preparing for external audits, or managing an audit program.
quality-documentation-manager
Document control system management for medical device QMS. Covers document numbering, version control, change management, and 21 CFR Part 11 compliance. Use when working on document control procedures, change control workflows, document numbering, version management, electronic signature compliance, or regulatory documentation review.