home / skills / coowoolf / insighthunt-skills / pre-mortem-kill-criteria

pre-mortem-kill-criteria skill

/decision-thinking/pre-mortem-kill-criteria

This skill helps teams implement kill criteria in pre-mortems, turning failure signals into pre-committed actions that prevent sunk-cost bias.

npx playbooks add skill coowoolf/insighthunt-skills --skill pre-mortem-kill-criteria

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.3 KB
---
name: pre-mortem-kill-criteria
description: Use before launching products or signing contracts, when needing to combat sunk cost fallacy, or when standard pre-mortems fail to change behavior
---

# Pre-Mortems with Kill Criteria

## Overview

An enhancement to the standard pre-mortem that moves beyond simply imagining failure to establishing **pre-committed actions** based on specific negative signals.

**Core principle:** Thinking about failure isn't enough; you must commit to actions BEFORE you see the signals.

## The Process

```
┌─────────────────────────────────────────────────────────────────┐
│  1. MENTAL TIME TRAVEL                                          │
│     Fast forward: Imagine the project has FAILED                │
├─────────────────────────────────────────────────────────────────┤
│  2. SIGNAL IDENTIFICATION                                       │
│     "What early clues indicated the failure?"                   │
│     List specific, observable signals                           │
├─────────────────────────────────────────────────────────────────┤
│  3. DEFINE KILL CRITERIA                                        │
│     Convert clues into measurable thresholds                    │
│     Example: "CPA > $50" or "Customer won't demo"               │
├─────────────────────────────────────────────────────────────────┤
│  4. PRE-COMMITMENT                                              │
│     Establish rule: "If [Criteria] occurs, we [Kill/Pivot]"     │
│     Write it down and share with team                           │
├─────────────────────────────────────────────────────────────────┤
│  5. ACTIVE MONITORING                                           │
│     Scan for criteria during execution                          │
│     Act immediately when triggered                              │
└─────────────────────────────────────────────────────────────────┘
```

## Key Principles

| Principle | Description |
|-----------|-------------|
| **Pre-commit** | Lock in actions before rationalization kicks in |
| **Signal focus** | Identify correlates of failure, not just the failure itself |
| **Prospective waste** | Think about future waste, not sunk cost |
| **Automatic triggers** | When criteria hit, action is mandatory |

## Common Mistakes

- Doing a pre-mortem but not changing the plan
- Identifying risks without setting a specific stop trigger
- Rationalizing signals when they appear ("it's different this time")

---

*Source: Annie Duke (First Round Capital, WSOP Champion) via Lenny's Podcast*

Overview

This skill adds explicit kill criteria to a standard pre-mortem so teams commit to stopping or pivoting before rationalization sets in. It helps teams convert vague failure scenarios into measurable, enforceable triggers and a clear plan of action. Use it to reduce prospective waste and prevent the sunk cost fallacy from derailing decisions.

How this skill works

Run a short pre-mortem where participants imagine the project has failed and list the early clues that would have indicated that failure. Convert those clues into concrete, measurable kill criteria and pre-commit to the action (kill, pause, or pivot) if any criterion is met. Monitor the defined signals during execution and act automatically when a criterion is triggered.

When to use it

  • Before launching a product, feature, or major experiment
  • When signing time- or resource-intensive contracts
  • If past projects suffered from sunk cost escalation
  • When stakeholders routinely rationalize negative signals
  • When standard risk lists don’t change team behavior

Best practices

  • Make criteria observable and measurable (numbers, behaviors, events)
  • Keep actions binary and predetermined: kill, pause, or pivot
  • Write criteria and actions down and share them publicly
  • Limit criteria to a few high-signal indicators to avoid noise
  • Assign monitoring responsibility and cadence up front

Example use cases

  • Early-stage growth test: pre-commit to kill if CPA > $50 after 1,000 impressions
  • Pilot contract: pause renewals if onboarding NPS stays below 40 after 30 days
  • Sales process change: pivot if fewer than 20% of prospects agree to demo
  • New feature launch: kill if MAU lift is <5% in the first two weeks
  • Partnership deal: cancel if integration readiness misses two deployment milestones

FAQ

How specific should a kill criterion be?

Specific and measurable: use a numeric threshold, time window, or observable behavior so the trigger is unambiguous.

What if the team disagrees when a criterion is hit?

Decide governance in advance: designate a decision owner or panel and require the pre-committed action unless a formal override process is used.