Knowing When to Kill It: Sunsetting Bets and Products on Purpose

Kill a product bet when it misses the success criteria you set before you started — not when leadership loses patience or a competitor ships something shinier. The discipline is designing kill criteria at launch, reviewing them on a fixed cadence, and treating sunk cost as irrelevant to the decision. Most portfolios don't fail from bad bets; they fail from good bets nobody was willing to end.

Quick Answer: Write your kill criteria before you build, review them on schedule (not on vibes), and separate "is this working" from "have we invested enough to feel bad about stopping." If a bet misses its pre-set bar for two consecutive review cycles, sunset it — the humane way, not the quiet way.

Most roadmap frameworks obsess over what to build next. Almost none of them teach you how to stop building something you already shipped. That asymmetry is expensive. A portfolio with no kill mechanism accumulates zombie bets — features nobody loves, nobody hates enough to escalate, and nobody owns enough to end. They sit there consuming maintenance hours, cluttering the UI, and quietly taxing every future roadmap decision.

Why Product Leaders Avoid Killing Things

Product leaders avoid kill decisions because stopping feels like admitting failure in a discipline that rewards visible momentum, and because the psychological and political costs of ending something are immediate while the benefits are diffuse and delayed. The result: portfolios skew toward starting new things over finishing or ending old ones.

Three forces reinforce each other here, and none of them are irrational — they're predictable, well-documented biases operating exactly as designed.

Sunk cost fallacy is the best-known offender. Behavioral economists Richard Thaler and Daniel Kahneman documented decades ago that people weight past investment when it should be functionally irrelevant to a forward-looking decision — the money and time already spent are gone either way. A PM who spent eighteen months on a bet feels the eighteen months as a reason to continue, when it's actually a reason to be more rigorous about whether continuing pays off from here.

Loss aversion compounds it. Kahneman and Amos Tversky's prospect theory found people feel losses roughly twice as intensely as equivalent gains — so killing a feature (a visible, attributable loss) feels worse than the diffuse, invisible gain of redirecting that capacity toward something better. And organizational identity ties a bet to a person's reputation: if you championed the feature, ending it reads as ending part of your credibility, which is precisely why kill decisions shouldn't rest on the champion's gut feel alone.

None of this means kill decisions should be ruthless or fast. It means they need to be pre-committed, criteria-based, and owned by more than one person — so the decision isn't hostage to whoever feels the sunk cost most acutely.

Designing Kill Criteria Before You Build

Design kill criteria at the same time you write the success criteria for a bet — ideally in the same document, reviewed by the same stakeholders, before a single line of code ships. A kill criterion is simply the inverse threshold: the specific, measurable condition under which you've agreed, in advance, to stop.

This is a direct application of the pre-mortem technique, popularized by psychologist Gary Klein in Harvard Business Review: instead of asking "will this succeed," a team imagines the project has already failed and works backward to identify why. Klein's research found pre-mortems increase teams' ability to correctly identify failure reasons because they remove the social pressure of appearing disloyal to a plan already in motion — you're diagnosing a hypothetical failure, not criticizing a colleague's live idea.

Applied to sunsetting, a pre-mortem-style kill-criteria template answers four questions before launch:

A few rules make this template hold up under pressure months later, when the people who wrote it may not be the people reviewing it.

1. Set the threshold as a number, not a feeling. "If it's not gaining traction" is unenforceable; "if adoption is under 5% after two quarters" is not.
2. Set the review date at launch, not after you see early results. Moving the goalposts once data starts trickling in defeats the entire point of pre-committing.
3. Name a reviewer who didn't build it. The champion's judgment is valuable input, not the final call — this is the same logic behind why you'd never let an author be their own sole editor.
4. Write the failure criteria in the same breath as the success criteria, ideally the same paragraph, so there's no later argument about whether a bar was "always the plan" or invented retroactively to justify a decision already made.

This is exactly the discipline this framing owes to teaching, not to a tool — but it's also precisely the kind of criteria that gets forgotten if it lives only in a launch deck nobody reopens. Whatever a bet's original success (and failure) bar was, it needs to survive as an artifact the team actually revisits, not a slide buried in a quarter-old deck.

Reviewing Kill Criteria Honestly

Reviewing kill criteria honestly means treating the scheduled review as a real decision point with two live outcomes — continue or kill — rather than a formality that always defaults to continuing because momentum is the path of least resistance. The review only works if "kill" is genuinely on the table every time.

Three honesty checks catch the most common ways teams quietly evade their own criteria.

Check the Metric, Not the Narrative

Numbers get reinterpreted under pressure. A bet that missed its adoption threshold gets reframed as "early but promising" or "the real signal is retention, not adoption" — a moving target invented after the fact. If the metric said kill, the review's job is to confirm the metric is still the right one to have chosen, not to find a replacement metric that says continue.

This is the same discipline behind treating your roadmap as outcome-based rather than a features checklist: if you defined the outcome honestly up front, the review is arithmetic, not negotiation. Teams that skip that step end up negotiating the definition of success every single review cycle, which is functionally the same as having no kill criteria at all.

Separate "Working" From "Worth More Than the Next Bet"

Even a bet clearing its own bar can still be the wrong use of capacity if something else in the portfolio would produce more outcome per unit of engineering time. This is a portfolio-level judgment, not a bet-level one — it requires comparing this bet's marginal return against the next-best alternative, the same comparative lens used in any RICE or Kano-style prioritization exercise.

A bet that's "fine" is still competing against everything else that could occupy that team next quarter. Fine is a bar, not a ceiling — and a portfolio that only kills things that are actively failing will still bloat with mediocre-but-not-dead bets that starve better ideas of capacity.

Watch for Criteria That Quietly Expanded

A bet's original scope was "let 15% of active users complete task X." Eighteen months later, the same feature is being judged against "let 40% of users complete tasks X, Y, and Z" — nobody voted on the expansion; it just happened as new capabilities got bolted on. Compare the current review against the original written criteria, not the current, inflated mental model of what the feature was supposed to do.

If you can't find the original success criteria in writing, that's the actual problem — and it's worth fixing before you evaluate a single bet, because every future kill decision inherits the same ambiguity.

The Humane Sunsetting Sequence

A humane sunsetting sequence tells users, the internal team, and the roadmap about the decision in that order — with enough lead time and enough honesty that nobody is surprised, and gives affected users a real off-ramp instead of a dead link. Rushing this sequence, or reversing the order, is where sunsetting decisions turn into PR problems.

For Users: Lead Time, Alternatives, and Data Portability

Users experiencing a sunset should never learn about it from a feature silently disappearing. Give them:

• Advance notice, scaled to how embedded the feature is — weeks for a minor toggle, months for something workflow-critical.
• A clear reason, framed honestly ("this didn't reach enough people to justify continued investment") rather than corporate euphemism.
• A migration path, even if the alternative is "here's how to do this with feature Y" or a data export, not a replacement feature.
• A named point of contact for users who need more than a broadcast email — this matters disproportionately for your highest-usage accounts, who deserve a direct conversation, not a mass notice.

If the feature touches a workflow you've mapped as part of a customer journey, walk that same map in reverse: every touchpoint the feature created is a touchpoint that needs a graceful exit, not just a removal.

For the Team: Say Why, Not Just What

The internal team — especially whoever built and maintained the bet — deserves the actual reasoning, not a one-line Slack notice. Frame the kill as the criteria working, not the team failing. A bet that hit its pre-agreed kill threshold is a successful test, in the same sense a scientific experiment that disproves a hypothesis is successful — it answered the question it was designed to answer.

This reframe only lands if it's true, which is exactly why steps one and two in this article matter: criteria set honestly before launch make the kill defensible after the fact, instead of feeling like an arbitrary call from above.

For the Roadmap: Show Where the Capacity Goes

The single most motivating part of a kill decision — and the most commonly skipped — is being explicit about what the freed capacity now funds. "We're stopping X" lands very differently paired with "so we can put that team on Y, which scored higher on our last prioritization pass" than left as a standalone announcement. Communicating that reallocation with the same rigor you'd apply to communicating roadmap uncertainty turns a kill from a retreat into a visible reallocation toward something the team already believes in.

Sunsetting as a Portfolio-Level Skill

Sunsetting is a portfolio-level skill, not a one-off cleanup task, because a portfolio without a routine kill mechanism structurally drifts toward carrying too many mediocre bets and starving the few that could be great. Treat "what should we stop" as a standing agenda item at the same cadence as "what should we start."

A useful discipline: at every quarterly roadmap review, require at least one kill decision to be on the table alongside the new bets under consideration — not because something must always die, but because the question must always be asked. A roadmap built on now-next-later honesty already tells stakeholders what won't happen soon; extending that same honesty to what's actively being retired is a small addition with an outsized trust payoff.

It also connects directly to how you frame new bets. If you write success criteria through a jobs-to-be-done lens — what job is the customer hiring this feature to do — your kill criteria fall out naturally: if the feature isn't getting hired for that job at a meaningful rate, the job is going unmet by this solution, and that's your answer regardless of how much engineering effort went in.

Where Prodinja Fits

The single most common reason kill reviews devolve into gut calls is that nobody can find the original success criteria six or twelve months later. Prodinja's Library is designed to hold the original success criteria for each bet alongside the spec that shipped it, so the review isn't a debate about what was originally promised — it's a straightforward comparison between what was written down at launch and what actually happened. That objective trigger is the difference between a kill decision and a kill argument.

Key Takeaways

• Write kill criteria before you build, in the same document as your success criteria, using a pre-mortem-style template with a named reviewer, a fixed date, and a numeric threshold.
• Sunk cost is irrelevant to a forward-looking decision — past investment explains why a bet is hard to kill, but it's never a valid reason to continue one that's missing its bar.
• Review the metric, not the narrative — a missed threshold shouldn't get reinterpreted into a different metric that happens to say continue.
• "Working" and "worth more than the next best bet" are different questions — a portfolio only stays sharp if it compares marginal returns, not just pass/fail on an isolated bet.
• Sunset in order: users first, team second, roadmap third — each audience needs a different kind of honesty, and skipping the lead time for users is the fastest way to turn a quiet decision into a public complaint.
• Frame a kill as the criteria working, not the team failing — that reframe only holds if the criteria were actually set honestly up front.
• Make "what should we stop" a standing agenda item, reviewed with the same rigor and regularity as "what should we start."