version: "1.0.1" name: kill-criteria-exit-ramps description: Establishes pre-defined, objective conditions for stopping projects and specific decision points for continue/pivot/kill evaluations. Guides through defining kill criteria, setting go/no-go gates, avoiding sunk cost fallacy, and executing disciplined stopping decisions. Use when defining stopping rules for projects, avoiding sunk cost fallacy, setting objective exit criteria, deciding whether to continue/pivot/kill initiatives, or when users mention kill criteria, exit ramps, stopping rules, go/no-go decisions, project termination, or sunk costs.

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) Specify quantifiable success criteria (e.g., "20% conversion") and evaluation period (e.g., "6 months post-launch").

Step 2: Establish objective kill criteria (details) 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) 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) For multi-stage projects: define go/no-go gates. For ongoing projects: define triggers that prompt evaluation.

Step 5: Document formally (details) 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) Track metrics weekly/monthly. Dashboard with kill criteria thresholds clearly marked. Automate alerts when approaching thresholds.

Step 7: Evaluate at gates/triggers (details) 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) 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 now" — sunk cost fallacy

Guardrail: Use pre-mortem inversion: "If starting today with $0 invested, would we do this?" Only future matters.

Principle: Past costs are gone. Only question: "Is future investment better here or elsewhere?"

6. Kill Quickly (Avoid Zombie Projects)

Danger: Projects that should be killed linger, draining resources ("zombie projects")

Guardrail: Kill decision → immediate wind-down. Announce within 1 week, reallocate team within 1 month.

Red flag: Project in "wind-down" for >3 months — this is zombie mode, not killing

7. Opportunity Cost > Sunk Cost

Danger: Continuing project because "almost done" even if better opportunities exist

Guardrail: Portfolio thinking. Ask: "Is this the best use of these resources?" If not, kill even if 90% done.

Principle: Opportunity cost of not pursuing better option often exceeds benefit of finishing current project

8. Postmortem, Don't Blame

Danger: Kill decisions seen as "failure", teams avoid them

Guardrail: Normalize killing projects. Celebrate disciplined stopping. Postmortem focuses on learning, not blame.

Culture: "We killed 3 projects this quarter" = good (freed resources for winners), not bad (failures)

Quick Reference

Kill Criteria Checklist

Before launching project, answer:

• [ ] Success metrics defined? (quantifiable, e.g., "20% conversion")
• [ ] Time horizon set? (e.g., "6 months post-launch")
• [ ] Kill criteria established? (e.g., "If <10% conversion after 6 months, kill")
• [ ] Decision rights assigned? (specific person, not "team")
• [ ] Documented formally? (in PRD, signed by stakeholders)
• [ ] Monitoring plan? (who tracks, how often, dashboard)
• [ ] Wind-down plan? (how to kill if criteria triggered)

Go/No-Go Gate Template

Pivot vs. Kill Decision Framework

Resources

Navigation to Resources

• **Templates**: Kill criteria document, go/no-go gate template, pivot/kill decision framework, wind-down plan
• **Methodology**: Sunk cost psychology, portfolio management, decision rights frameworks, postmortem processes
• **Rubric**: Evaluation criteria for kill criteria quality (10 criteria)

Related Skills

• expected-value: For quantifying opportunity cost of continuing vs. killing
• hypotheticals-counterfactuals: For pre-mortem analysis ("what if we had killed earlier?")
• decision-matrix: For comparing continue/pivot/kill options
• postmortem: For learning from killed projects
• portfolio-roadmapping-bets: For portfolio-level kill decisions

Examples in Context

Example 1: Startup Feature Kill

Context: SaaS launched "Advanced Analytics", kill criteria: <15% adoption after 3 months

Result: 12% adoption → Killed feature, reallocated 2 engineers to core. Saved 6 months maintenance.

Example 2: Enterprise Sales Pivot

Context: B2B SaaS, pivot trigger: <10 customers by Month 12

Result: 7 customers → Pivoted to self-serve SMB. Hit 200 SMB customers in 6 months, 4× faster growth.

Example 3: R&D Portfolio Kill

Context: 8 R&D projects, capacity for 5. Ranked by EV/Cost: A(3.5), B(2.8), C(2.5), D(2.1), E(1.8), F(1.5), G(1.2), H(0.9)

Decision: Killed F, G, H despite F being "80% done". Top 3 projects shipped 4 months earlier.