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.
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
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
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
When: Project isn't working as planned — should you pivot or kill?
Framework:
Pivot if:
Kill if:
Example: Mobile app with low engagement
Decision: Pivot if hypothesis valid but execution wrong. Kill if hypothesis invalid.
When: Managing portfolio of projects, need to kill some to focus
Process:
Example: Company with 10 projects, capacity for 7
Principle: Opportunity cost matters more than sunk cost. "Almost done" doesn't justify continuing if better alternatives exist.
When: Team resists killing project due to past investment
Technique: Pre-mortem inversion
Example: Failed enterprise sales push
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.
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).
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
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.
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."
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
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?"
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
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
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)
Before launching project, answer:
| 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 |
| 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 |
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.
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.
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.