pre-mortem

Pre-Mortem

Imagine your project has failed spectacularly—then work backward to identify why. Apply Gary Klein's "prospective hindsight" technique to catch failures before they happen.

When to Use This Skill

• Before launching a product, campaign, or major initiative
• Before making an important decision (hiring, investment, partnership)
• Starting a project to identify risks the team hasn't considered
• When overconfident and everyone agrees the plan is great
• Before committing resources to a significant undertaking
• In team planning to surface concerns people might hesitate to share

Methodology Foundation

| Aspect | Details | |--------|---------| | Source | Gary Klein (1989), cognitive psychologist, naturalistic decision making pioneer | | Expert | Klein's research shows pre-mortems increase accuracy of identifying reasons for outcomes by 30% | | Core Principle | "Prospective hindsight" - imagining an event has already occurred dramatically improves our ability to explain it. The future feels distant; the past feels real. |

What Claude Does vs What You Decide

| Claude Does | You Decide | |-------------|------------| | Structures production workflow | Final creative direction | | Suggests technical approaches | Equipment and tool choices | | Creates templates and checklists | Quality standards | | Identifies best practices | Brand/voice decisions | | Generates script outlines | Final script approval |

What This Skill Does

1. Surfaces hidden risks - Finds dangers invisible to forward-looking planning
2. Gives permission to criticize - Team members can voice concerns safely
3. Reduces overconfidence - Counters planning fallacy and optimism bias
4. Improves plans before execution - Fix problems when they're cheap to fix
5. Creates psychological safety - "We're imagining failure" feels safer than "I think this will fail"

How to Use

Run a Pre-Mortem

Run a Pre-Mortem on this project:
[describe the project, product, or decision]

It's one year from now and this has failed completely. What happened?

Stress-Test a Decision

Pre-Mortem this decision:
[describe the decision you're considering]

Assume we made this choice and it went badly. What went wrong?

Team Pre-Mortem Facilitation

Help me facilitate a Pre-Mortem session for my team.
Project: [description]
Team size: [number]
Time available: [duration]

Provide the agenda, questions to ask, and how to synthesize findings.

Instructions

When facilitating a Pre-Mortem, follow this systematic process:

Step 1: Set the Stage

## Pre-Mortem Setup

**Project/Decision:** ________________________________

**Timeline:** [Imagine we're looking back from X months/years]

**The Scenario:**
"It is [future date]. This project has failed—not just underperformed,
but failed spectacularly. The results are in and they're bad.

We're now conducting a post-mortem to understand what went wrong.
Looking back, it's obvious why this failed..."

**Rules:**
1. Failure has ALREADY happened (this is a fact in this exercise)
2. Everyone must contribute at least one reason
3. No defending the plan (we're explaining failure, not preventing it)
4. Be specific, not vague
5. "I had a bad feeling" is valid (hindsight makes it concrete)

Step 2: Individual Failure Generation (Silent)

## Individual Brainstorm (5-10 minutes)

Each person silently writes answers to:

"Looking back, this project failed because..."

1. ________________________________________________
2. ________________________________________________
3. ________________________________________________
4. ________________________________________________
5. ________________________________________________

**Prompt Questions:**
- What did we overlook?
- What assumption proved wrong?
- What external event derailed us?
- Who let us down (vendor, team member, partner)?
- What resource ran out?
- What competitor move hurt us?
- What customer behavior surprised us?
- What technical problem emerged?
- What communication failure occurred?
- What timeline assumption was wrong?

Why Silent First:

• Prevents groupthink
• Allows introverts equal voice
• Captures diverse concerns before discussion narrows focus

Step 3: Share and Cluster

## Round Robin Sharing

**Process:**
1. Each person shares ONE reason (no discussion yet)
2. Continue rounds until all reasons shared
3. Capture on whiteboard/doc as shared

**Clustering:**
Group similar failure reasons into categories:

### EXECUTION FAILURES
- ________________________________
- ________________________________

### EXTERNAL FACTORS
- ________________________________
- ________________________________

### RESOURCE CONSTRAINTS
- ________________________________
- ________________________________

### ASSUMPTION FAILURES
- ________________________________
- ________________________________

### PEOPLE/TEAM ISSUES
- ________________________________
- ________________________________

### TIMING/MARKET
- ________________________________
- ________________________________

Step 4: Analyze and Prioritize

## Risk Assessment Matrix

For each failure reason, assess:

| Failure Reason | Likelihood | Impact | Detectability | Risk Score |
|----------------|------------|--------|---------------|------------|
| [Reason 1] | H/M/L | H/M/L | Early/Late/Never | ___ |
| [Reason 2] | H/M/L | H/M/L | Early/Late/Never | ___ |
| [Reason 3] | H/M/L | H/M/L | Early/Late/Never | ___ |

**Scoring:**
- High Likelihood + High Impact + Late/Never Detection = CRITICAL
- Medium/Medium/Early = MANAGEABLE
- Low/Any/Early = MONITOR

## Priority Failures

**CRITICAL (Must Address):**
1. ________________________________
2. ________________________________
3. ________________________________

**MONITOR (Watch Closely):**
1. ________________________________
2. ________________________________

Step 5: Create Prevention/Mitigation Plans

## Prevention Strategies

For each critical risk:

### Risk: [Failure Reason 1]

**Early Warning Signs:**
- ________________________________
- ________________________________

**Prevention Actions:**
- ________________________________
- ________________________________

**If It Happens Anyway (Mitigation):**
- ________________________________
- ________________________________

**Owner:** ____________
**Review Date:** ____________

---

### Risk: [Failure Reason 2]

[Repeat structure]

---

## Tripwires (Automatic Triggers)

"If we see [sign], we immediately [action]"

1. If ______________, then ______________
2. If ______________, then ______________
3. If ______________, then ______________

Step 6: Integrate into Plan

## Updated Project Plan

### Original Assumptions (Now Questioned)
| Assumption | Pre-Mortem Concern | Validation Plan |
|------------|-------------------|-----------------|
| [Assumption] | [Risk raised] | [How to test] |
| [Assumption] | [Risk raised] | [How to test] |

### New Safeguards Added
- [ ] ________________________________
- [ ] ________________________________
- [ ] ________________________________

### Monitoring Dashboard
Track these metrics as early warning system:
1. ________________________________
2. ________________________________
3. ________________________________

### Scheduled Check-ins
- Week 2: Review assumption #1
- Week 4: Check metric #2
- Month 2: Full pre-mortem review

Examples

Example 1: Product Launch Pre-Mortem

Context: SaaS company launching new enterprise product in 3 months.

Input:

"We're launching our enterprise product in Q2. Everyone's excited. Run a Pre-Mortem—what killed us?"

Output:

The Scenario: "It's September. Our Q2 enterprise launch failed. We've burned through our runway, the product hasn't gained traction, and we're considering a pivot. What went wrong?"

Failure Reasons Generated:

EXECUTION FAILURES: 1