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:

Rank by expected value: ROI, strategic fit, resource efficiency
Define minimum threshold: "Top 70% of portfolio gets resources"
Kill bottom 30%: Projects below threshold, regardless of sunk cost
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

Ask: "If we were starting today with zero investment, would we start this project?"
If answer is "No" → Kill (sunk costs are irrelevant)
If answer is "Yes, but differently" → Pivot
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

Gate	Investment	Timeline	Success Criteria	Decision
Gate 1: Concept	$10k	4 weeks	15+ customer interviews showing strong interest	GO / NO-GO
Gate 2: MVP	$50k	3 months	40% weekly active users (50 beta users)	GO / NO-GO
Gate 3: Launch	$200k	6 months	10% conversion, <$100 CAC	GO / NO-GO

Pivot vs. Kill Decision Framework

Factor	Pivot	Kill
Customer pain	Real but solution wrong	No pain, nice-to-have
Market size	Large enough	Too small
Learning rate	High (new insights)	Low (stuck)
Burn rate	Sustainable	Too high
Team belief	Believes with changes	Doesn't believe
Opportunity cost	Pivot is best option	Better options exist

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.

kill-criteria-exit-ramps