kill-criteria-exit-ramps

What this skill does

# Kill Criteria & Exit Ramps

---

## Common Patterns

### Pattern 1: Upfront Kill Criteria (Before Launch)

**When**: Starting new project, experiment, or product

**Process**: (1) Define success metrics ("10% conversion"), (2) Set time horizon ("6 months"), (3) Establish kill criteria ("If <5% after 6 months, kill"), (4) Assign decision rights (specific person), (5) Document formally (signed PRD)

**Example**: New feature — Success: 20% adoption in 3 months, Kill: <10% adoption, Decision: Product VP makes call

### Pattern 2: Go/No-Go Gates (Milestone-Based)

**When**: Multi-stage projects with increasing investment

**Structure**: Stage 1 (cheap, concept) → Go/No-Go → Stage 2 (moderate, MVP) → Go/No-Go → Stage 3 (expensive, launch) → Go/No-Go

**Example**: Gate 1 (4wk, $10k): 15+ customer interviews show interest → GO. Gate 2 (3mo, $50k): 40% weekly active (got 25%) → NO-GO, kill

**Benefit**: Small investments first, kill before expensive stages

### Pattern 3: Trigger-Based Exit Ramps

**When**: Ongoing projects with uncertain outcomes

**Common triggers**: Time-based ("not profitable by Month 18"), Metric-based ("churn >8% for 2 months"), Market-based ("competitor launches"), Resource-based ("budget overrun >30%"), Opportunity-based ("better option emerges")

**Example**: SaaS — Trigger 1: MRR growth <10%/mo for 3 months → Evaluate. Trigger 2: CAC payback >24mo → Evaluate. Trigger 3: Competitor raises >$50M → Evaluate

**Note**: Triggers prompt evaluation, not automatic kill

### Pattern 4: Pivot vs. Kill Decision

**When**: Project isn't working as planned — should you pivot or kill?

**Framework**:

**Pivot if**:
- Core insight is valid but execution is wrong
- Customer pain is real, solution is wrong
- Market exists, go-to-market is wrong
- Learning rate is high (discovering new insights rapidly)
- Resource burn is sustainable (not desperation mode)

**Kill if**:
- No customer pain (nice-to-have, not must-have)
- Market too small (can't sustain business)
- Burn rate too high relative to progress
- Team doesn't believe in vision
- Better opportunities available (opportunity cost)
- Regulatory/legal blockers

**Example**: Mobile app with low engagement
- **Situation**: Launched fitness app, 10k downloads, 5% weekly active (target was 40%)
- **Pivot option**: Interviews reveal users want meal tracking not workout tracking → Pivot to nutrition app
- **Kill option**: Users don't care about fitness tracking at all, market saturated → Kill, reallocate team

**Decision**: Pivot if hypothesis valid but execution wrong. Kill if hypothesis invalid.

### Pattern 5: Portfolio Kill Criteria (Multiple Projects)

**When**: Managing portfolio of projects, need to kill some to focus

**Process**:
1. **Rank by expected value**: ROI, strategic fit, resource efficiency
2. **Define minimum threshold**: "Top 70% of portfolio gets resources"
3. **Kill bottom 30%**: Projects below threshold, regardless of sunk cost
4. **Reallocate resources**: Winners get resources from killed projects

**Example**: Company with 10 projects, capacity for 7
- Rank by: (Expected Revenue × Probability of Success) / Resource Cost
- Kill: Projects ranked #8, #9, #10 (even if they're "almost done")
- Reallocate: Engineers from killed projects to top 3

**Principle**: Opportunity cost matters more than sunk cost. "Almost done" doesn't justify continuing if better alternatives exist.

### Pattern 6: Sunk Cost Trap Avoidance

**When**: Team resists killing project due to past investment

**Technique**: **Pre-mortem inversion**
1. Ask: "If we were starting today with zero investment, would we start this project?"
2. If answer is "No" → Kill (sunk costs are irrelevant)
3. If answer is "Yes, but differently" → Pivot
4. If answer is "Yes, exactly as-is" → Continue

**Example**: Failed enterprise sales push
- **Situation**: 18 months, $2M spent, 2 customers (need 50 for viability)
- **Inversion**: "If starting today, would we pursue enterprise sales?" → "No, we'd focus on self-serve SMB"
- **Decision**: Kill enterprise sales, pivot to SMB (sunk $2M is irrelevant)

**Trap**: "We've invested so much, we can't quit now" → This is sunk cost fallacy
**Escape**: Only future costs and benefits matter. Past is gone.

---

## Workflow

Use this structured approach when defining or applying kill criteria:

```
□ Step 1: Define success metrics and time horizon
□ Step 2: Establish objective kill criteria
□ Step 3: Assign decision rights and governance
□ Step 4: Set milestone gates or trigger points
□ Step 5: Document formally (signed agreement)
□ Step 6: Monitor metrics regularly
□ Step 7: Evaluate at gates/triggers
□ Step 8: Execute kill decision (if triggered)
```

**Step 1: Define success metrics and time horizon** ([details](#1-define-success-metrics-and-time-horizon))
Specify quantifiable success criteria (e.g., "20% conversion") and evaluation period (e.g., "6 months post-launch").

**Step 2: Establish objective kill criteria** ([details](#2-establish-objective-kill-criteria))
Set numeric thresholds that trigger stop decision (e.g., "If <10% conversion after 6 months"). Make criteria objective, not subjective.

**Step 3: Assign decision rights and governance** ([details](#3-assign-decision-rights-and-governance))
Name specific person who makes kill decision. Define escalation process. Avoid "team consensus" (leads to paralysis).

**Step 4: Set milestone gates or trigger points** ([details](#4-set-milestone-gates-or-trigger-points))
For multi-stage projects: define go/no-go gates. For ongoing projects: define triggers that prompt evaluation.

**Step 5: Document formally** ([details](#5-document-formally))
Write kill criteria in PRD, project charter, or investment memo. Get stakeholders to sign/approve before launch (prevents moving goalposts).

**Step 6: Monitor metrics regularly** ([details](#6-monitor-metrics-regularly))
Track metrics weekly/monthly. Dashboard with kill criteria thresholds clearly marked. Automate alerts when approaching thresholds.

**Step 7: Evaluate at gates/triggers** ([details](#7-evaluate-at-gatestriggers))
When gate or trigger hit, conduct formal evaluation. Use pre-mortem inversion: "Would we start this today?" Decide: continue, pivot, or kill.

**Step 8: Execute kill decision** ([details](#8-execute-kill-decision))
If kill triggered: communicate decision, wind down project, reallocate resources, conduct postmortem. Execute quickly (avoid zombie projects).

---

## Guardrails

### 1. Set Kill Criteria Before Launch (Not After)

**Danger**: Defining kill criteria after project starts leads to moving goalposts

**Guardrail**: Write kill criteria in initial project document, before emotional/financial investment. Get stakeholder sign-off.

**Red flag**: "We'll figure out when to stop as we go" — this leads to sunk cost trap

### 2. Make Criteria Objective (Not Subjective)

**Danger**: Subjective criteria ("team feels it's not working") are easy to ignore

**Guardrail**: Use quantifiable metrics (numbers, dates, milestones). "5% conversion" not "low adoption". "6 months" not "reasonable time".

**Test**: Could two people independently evaluate criteria and reach same conclusion? If not, too subjective.

### 3. Assign Clear Decision Rights

**Danger**: "Team decides" or "we'll discuss" leads to paralysis (everyone has sunk cost)

**Guardrail**: Name specific person who makes kill decision. Define what data they need. Escalation path for overrides.

**Example**: "Product VP makes kill decision based on 6-month metrics. Can be overridden only by CEO with written justification."

### 4. Don't Move the Goalposts

**Danger**: When kill criteria approached, team lowers bar or extends timeline

**Guardrail**: Kill criteria are fixed at launch. Changes require formal process (written justification, senior approval, new document).

**Red flag**: "Let's give it another 3 months" when 6-month criteria not met

### 5. Sunk Costs Are Irrelevant

**Danger**: "We've invested $2M, can't stop no