Framework
You've built a feature. Shipped it. Used resources. Now decide: Keep investing or kill it?
The trap: "We've already spent $500K. We should get ROI."
But sunk cost is sunk. Future invest decision should be based on future value, not past cost.
Actionable Steps
1. Separate Past and Future
- Past: "We spent $500K building this"
- Future: "Should we spend $50K/quarter maintaining this?"
Decisions should only consider future value, not past cost.
2. Compare to Alternatives
Would $50K/quarter spent on feature X be better spent on feature Y?
If yes, kill X and do Y.
3. Recognize Sunk Cost Fallacy
It feels "wasteful" to kill something you invested in. That feeling is sunk cost fallacy. Ignore it. Make the forward-looking decision.
Key Takeaways
- Past cost is irrelevant to future decisions. Only future value matters.
- Products and features die. That's normal. Legacy code and old features get replaced. Don't let sunk cost prevent good decisions.
- Recognize the sunk cost feeling, then override it. Bias awareness is the first step.
The Sunk Cost Trap in Product Management
You have built a feature called "Collaboration AI." Here's the story:
Q1-Q2: 4 engineers, 6 months, $400K spent. It's now live. Q3: Usage is 2% of users. Engagement metrics flat. Support burden high (AI sometimes breaks). Q4: Question: Keep maintaining? Kill? Pivot?
The sunk cost trap logic:
- "We spent $400K. If we kill this, that's $400K wasted."
- "If we keep it for 2 more years, maybe it pays off."
- "We should try harder to make it work."
- Decision: Keep investing another $50K/quarter hoping it catches on.
The forward-looking logic:
- "Past $400K is gone either way. Can't get it back."
- "Question: Is $50K/quarter on this feature better than $50K/quarter on something else?"
- "Usage is 2%. Is there a path to 10%+?"
- "If not, kill it. Use the $50K on something with higher potential."
The difference: $400K sunk cost vs. $50K forward cost.
The 3-Option Decision Framework: Kill, Pivot, or Persevere
When a feature/product isn't hitting targets, you have 3 paths:
Option 1: Kill (Stop All Investment)
When to kill:
- Usage is 1-3%+ with no upward trend
- Support burden > value delivered
- Alternative solutions exist (built-in or third-party)
- Future investment unlikely to change trajectory
- Capital better deployed elsewhere
Example: "Collaboration AI" isn't driving adoption. Kill it.
Execution:
- Timeline: 3-month wind-down (don't abandon users)
- Communication: "We're focusing on core features. Here's the transition path."
- Migration: Help users export data / move to alternatives
- Lessons: "We tried AI-first collaboration. Turned out users prefer explicit actions. Lesson noted."
Costs: $20K migration + PR risk. Total cost to kill: $20K. Benefit: $50K/quarter freed up for other priorities × 8 quarters/year = $400K/year saved.
Net: $400K saved vs. $20K cost. Clear win.
Option 2: Pivot (Change Direction Without Killing)
When to pivot:
- Core idea has merit, but execution/positioning is wrong
- 5-15% usage (signal of demand, but small)
- Customer feedback suggests different use case than intended
- Small investment could unlock bigger opportunity
Example: "Collaboration AI" isn't used for real-time collab. But power users use it for "summarize meeting notes."
Pivot approach:
- "We're repositioning this from collaboration to note-taking."
- Reduce scope: Kill real-time collab features. Focus on summary generation.
- Re-launch with new narrative.
- Investment: $30K to redesign. Not $400K, but targeted spend to test new direction.
Results (after pivot):
- Usage increases from 2% to 8%
- Still not blockbuster, but viable
- Decision: "Keep as secondary feature. Revisit in 12 months."
Option 3: Persevere (Double Down)
When to persevere:
- Usage is 15%+, trending up
- Customer feedback is overwhelmingly positive
- You're seeing viral adoption (not marketing-driven)
- Market conditions favor this feature
- Competitors are doing it worse
Example: Not "Collaboration AI" (only 2% usage). But imagine usage was 20% and growing 10%/month.
Persevere approach:
- "This is working. Invest more. Make it best-in-class."
- $100K/quarter (2x current spend) to accelerate growth
- Expand roadmap: integrations, performance, advanced features
Expected outcome:
- Usage 20%+ → 40%+
- Becomes strategic differentiator
- 12+ month payback
The Kill/Pivot/Persevere Decision Matrix
Use this to decide:
| Factor | Kill | Pivot | Persevere |
|---|---|---|---|
| Usage | <2% | 5-15% | 15%+ |
| Trend | Flat or declining | Flat but signal present | Growing |
| Customer feedback | "Not useful" | "Interesting but needs..." | "Love this" |
| Future potential | None obvious | Possible with direction change | High |
| Support burden | High | Medium | Manageable |
| Alternative exists? | Yes, better one | Partial | No |
| Market dynamics | Shifting away | Neutral | Growing market |
Decision rule:
- If 3+ factors point to Kill → Kill
- If 3+ factors point to Pivot → Pivot
- If 3+ factors point to Persevere → Persevere
Real-World Case Study: Kill, Pivot, or Persevere in Action
Company: Productivity SaaS (50K users)
Q2 Review: Three Features at Crossroads
Feature A: "Smart Scheduling"
- Usage: 1.2%
- Customer feedback: "Not accurate for my calendar"
- Support tickets: 200+ per month about broken scheduling
- Market: Calendly, Fantastical already dominate
- Decision matrix: 5/7 factors = Kill
- Action: KILL
- Cost to kill: $10K (migration, communication)
- Savings: $60K/quarter maintenance + engineering
- Lesson: "Scheduling is not our core. Users already have solutions. We don't need to be better."
Feature B: "Time Blocking Templates"
- Usage: 7%
- Customer feedback: "Helpful, but needs more templates"
- Support tickets: 20/month (manageable)
- Market: Growing interest in time-blocking
- Decision matrix: 4/7 factors = Pivot
- Action: PIVOT
- New direction: "Make it template library + sharing." Not about scheduling logic.
- Re-launch as "Workflow templates" (generic use case)
- Investment: $30K to redesign
- Expected outcome: Usage 7% → 15%+
Feature C: "AI Meeting Notes"
- Usage: 18%, growing 12% MoM
- Customer feedback: "Saves hours each week"
- Support tickets: 10/month
- Market: Recording apps (Otter, Fireflies) growing but niche
- Decision matrix: 6/7 factors = Persevere
- Action: PERSEVERE
- Investment: $100K/quarter to expand
- Roadmap: Integrations with Slack, email, CRM
- Expected outcome: Usage 18% → 40%+ within 12 months
Financial outcome (Q2-Q4):
- Kill Smart Scheduling: -$10K spend, +$180K saved = $170K benefit
- Pivot Time Blocking: -$30K spend (relaunch), +$10K saved (lower maintenance now that focused) = -$20K net
- Persevere Meeting Notes: +$100K/quarter spend = -$300K cost, but expected $500K ARR in 12 months
- Net: $170K - $20K - $300K = -$150K for Q2-Q4, but foundation for +$500K ARR by end of year
Anti-Pattern: "Optimism Bias" (Persevere When You Should Kill)
The Problem:
- Feature launched 18 months ago with hopes of 20% adoption
- Currently at 3% usage
- Team says: "Give it one more quarter. It might take off."
- One more quarter, still 3%
- Two years later, still maintaining dead feature
The Fix:
- Set success criteria upfront: "If usage isn't 10% by Q3, we kill it."
- Enforce the criteria
- Bias check: "Is this hope or data?"
Prodinja Connection
The hardest product decisions involve sunk cost emotions. Prodinja's RICE/Kano prioritization studio is designed to let you score kill, pivot, and persevere as three competing options on the same scale — reach, impact, confidence, effort — using only forward-looking inputs, then watch the ranking update live as you adjust the numbers. Because the framework never asks about money already spent, past spend has nowhere to hide in the score, and a kill/pivot/persevere call gets held to the same evidence bar as any other roadmap trade-off.
Key Takeaways (Expanded)
-
Sunk cost is a cognitive bias. $400K spent is gone. Future decisions should only consider future value.
-
Use the Kill/Pivot/Persevere matrix to decide. Don't rely on intuition alone. Let data guide you.
-
Set success criteria upfront. "If usage isn't 10% by Q3, we kill this." Then stick to it.
-
Killing features is normal and healthy. Great products kill 30-50% of features over time. That's evolution, not failure.
-
Communication matters for kills. "We're focusing on core features" is better than silence. Users need migration path.