From thinking-frameworks-skills
Defines kill criteria, exit ramps, and go/no-go gates for projects. Guides continue/pivot/kill decisions and counters sunk cost fallacy in initiatives.
npx claudepluginhub lyndonkl/claude --plugin thinking-frameworks-skillsThis skill uses the workspace's default tool permissions.
---
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
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.