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.