pre-mortem

What this skill does

# 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:**