A feature should be sunset when it fails the adoption floor, maintenance cost ceiling, or strategic-fit test you defined before launch — not when a debate erupts about it two years later. Kill criteria are pre-committed exit conditions, written down at ship time, that force a scheduled, evidence-based review instead of an emotional one.
Quick Answer: Set three numeric kill criteria at launch — a minimum adoption rate, a maximum acceptable maintenance cost, and a strategic-fit check — with a review date. If a feature misses the threshold at that date, sunset it. Writing the criteria before launch is what defeats sunk-cost bias later.
Why Kill Criteria Have to Be Set Before Launch, Not After
Kill criteria only work if you write them down before you have an emotional stake in the outcome, because the moment a feature ships, everyone attached to it becomes a biased judge of its own performance. This is the mechanism behind sunk-cost bias: research from behavioral economists Hal Arkes and Catherine Blumer, going back to their foundational 1985 studies, found people escalate commitment to a losing course of action precisely because of what they've already invested, not because of what remains to be gained.
A PM who spent two quarters shipping a feature is the worst possible person to objectively decide, a year later, whether it should die. They'll find reasons: "it's early," "we haven't marketed it," "the new segment will need it." None of that is dishonest — it's just how the bias operates. Pre-committing a number closes that loophole.
The Asymmetry That Makes This Urgent
Launching is celebrated; sunsetting is invisible. No one gets promoted for retiring a feature, so the default incentive gradient always points toward keeping things alive, however quietly they're failing. That asymmetry is exactly why kill criteria need to be a process artifact, not a judgment call made in the moment.
- Launch decisions get a room full of stakeholders and a deck. Sunset decisions get made by one exhausted engineer wondering why nobody's fixed a bug in a feature three customers use.
- Kill criteria import launch-day rigor into the sunset decision, using the same discipline you'd apply when choosing a launch tier or scoping a go-to-market plan.
- Every additional live feature adds a small, permanent tax: more support surface, more QA matrix cells, more onboarding complexity, more code paths an engineer has to reason about before touching anything nearby.
What Actually Belongs in Kill Criteria
Kill criteria need three specific dimensions — adoption, maintenance cost, and strategic fit — each with a number and a date, because a vague standard like "if it's not doing well" gives everyone room to argue their way out of it later. Specificity is the whole point.
Adoption Floor
Set a minimum usage threshold tied to the feature's actual job, not to vanity metrics. If the feature is meant to be a daily habit, the floor is a weekly-active-usage percentage of the eligible user base. If it's meant to unblock a rare but critical job, the floor is a completion rate among the users who start it, not raw volume.
Anchor the floor in the underlying customer job, not the feature's mechanics — a Jobs-to-be-Done framing surfaces which job the feature was hired for, which tells you what "low adoption" actually means. A feature failing at 8% weekly usage might be fine if its job is rare and high-stakes (like a data-export tool used at contract renewal); the same 8% is a red flag for a feature meant to be core to the daily workflow.
Maintenance Cost Ceiling
Set a ceiling on the ongoing cost of keeping the feature alive: engineering hours per quarter spent on bugs and upkeep, support ticket volume attributable to it, or the number of dependent systems it complicates. This number rises over time even when usage doesn't, because the surrounding codebase keeps evolving and every added feature becomes another thing new hires have to learn and every future change has to avoid breaking.
A useful sanity check, drawn from technical-debt research (including the framing popularized by Ward Cunningham's original debt metaphor): the true cost of a feature isn't the sprint it took to build, it's the compounding interest paid every sprint after in constrained flexibility and added review surface.
Strategic Fit Check
Ask whether the feature still maps to the product's current strategy, not the strategy it was built under. Products pivot, ICPs shift, and a feature that was core to an old positioning can become dead weight under a new one even while its usage numbers stay flat. This is a yes/no gate, evaluated at the same review cadence as the numeric thresholds.
| Kill criterion | What it measures | Example threshold | Review cadence |
|---|---|---|---|
| Adoption floor | % of eligible users engaging with the feature's core job | ≥15% weekly active among eligible segment | Quarterly |
| Maintenance cost ceiling | Engineering hours + support tickets per quarter | ≤20 eng-hours/quarter, ≤10 tickets/month | Quarterly |
| Strategic fit | Alignment with current (not launch-era) product strategy | Yes/No against current strategy doc | Every strategy refresh |
| Cannibalization check | Whether the feature duplicates a better-performing one | No overlap >40% with a higher-adoption feature | Semi-annual |
The table above isn't exhaustive — some teams add a revenue-attribution row for paid add-ons — but adoption, cost, and strategic fit form the minimum viable set. Skipping any one of them leaves a loophole: a feature can pass on usage while quietly bleeding engineering time, or pass on cost while serving a strategy that no longer exists.
Building the Kill-Criteria Template at Launch
The template belongs in your launch checklist, sitting alongside the launch tier decision, because kill criteria set after the fact are really just post-hoc justifications wearing a template's clothing. Fill it in during the same meeting where you decide how big a launch this is.
The Template
- Feature name and launch date.
- Customer job this feature serves (one sentence, tied to a specific JTBD statement).
- Adoption floor, with the metric, the eligible population, and the number.
- Maintenance cost ceiling, with the metric and the number.
- Strategic fit statement: which strategic pillar or OKR this feature supports.
- Review date(s): typically 90 days (early signal), 180 days (real verdict), and 365 days (long-term check) after launch.
- Owner of the review: the PM who commits to running it, named explicitly, not "the team."
- Escalation path if the feature misses criteria: default action (sunset), and who can override it and why.
Step 8 matters more than it looks. Without a default action, "missed criteria" just triggers another debate — the exact outcome kill criteria exist to prevent. The default should be sunset unless someone makes an affirmative case to extend, not the reverse.
Who Should Own the Review
The reviewer should not be the feature's original owner alone. Pair them with someone structurally distant from the launch decision — a PM from another pod, or a product leader one level up — so the sunk-cost bias in the room has a counterweight. This mirrors why a clean PM-to-PMM handoff matters at launch: a second set of eyes that wasn't in the room for the original decision catches things the original owner is structurally unlikely to see.
Running the Review Without Getting Talked Out of It
When the review date arrives, the discipline is to check the number against the threshold first, and only then discuss context — because discussing context first is how sunk-cost bias creeps back in through the side door. If adoption is below floor, that's the finding; the conversation is about how to sunset, not whether the number counts.
Signals That the Room Is Rationalizing, Not Reviewing
- "It's still early" said about a feature past its 180-day review — early was the 90-day check; this is the verdict.
- A qualitative anecdote ("a customer loves it") substituted for the quantitative threshold with no acknowledgment that one loud fan isn't a floor.
- Scope creep on the metric itself — redefining "eligible users" or "active" mid-review to make the number clear the bar retroactively.
- No one willing to own the sunset decision, which quietly defaults to "keep it" by inertia.
What a Clean Review Looks Like
- Pull the actual metric against the pre-committed threshold — no interpretation yet.
- State plainly: met, missed, or borderline (within 10% of threshold).
- If missed, move to the mechanics of sunsetting, not to relitigating the threshold.
- If borderline, extend once, with a new fixed date — not an open-ended "let's keep watching."
- Document the decision and the reasoning in one place your team can find later, so the next review of a similar feature has precedent to draw on.
Reopening a customer journey read at this point — checking whether the feature still shows up as a meaningful moment in the customer journey — is a fast way to tell the difference between "underused but structurally important" and "underused and forgettable."
The Deprecation Communication Playbook
Communicating a sunset well means giving affected customers enough runway and enough alternative to feel handled, not blindsided — because a poorly communicated deprecation does more brand damage than the original feature's mediocrity ever did. The mechanics matter as much as the decision.
Timeline by Impact Tier
| Feature impact tier | Notice period before removal | Channels used |
|---|---|---|
| Low (rarely used, no workflow dependency) | 30 days | In-app banner, changelog |
| Medium (used regularly, has an alternative) | 60-90 days | Email + in-app banner + changelog |
| High (workflow-critical, no direct alternative) | 90-180 days | Email, in-app banner, account team outreach, migration guide |
Scale the notice period to how disruptive the removal is to a customer's actual workflow, not to how embarrassed the team is about the feature underperforming. A high-impact sunset handled with a 30-day notice generates support escalations and churn risk that dwarf whatever engineering time the sunset was meant to save.
Sunset Notice Template
Subject: [Feature name] is being retired on [date]
We're sunsetting [feature name] on [date]. Since launch, usage has stayed below the level needed to justify ongoing investment, and we'd rather focus that time on [where the effort is going instead].
What this means for you: [specific, concrete impact — e.g., "existing exports will stop working; use X instead"].
What to do: [migration path, if any, with a link]. If you have data or workflows tied to this feature, [specific action, e.g., "export your data by [date]"].
Questions? Reply to this email or reach your account team.
Name the reason honestly and briefly — "usage stayed below the level needed to justify investment" is true and respectful, versus vague language that reads as evasive. Customers generally accept a feature being retired; what erodes trust is feeling like the decision was hidden from them until the last minute.
Recording Kill Criteria So They Actually Get Reviewed
The hardest part of this whole practice isn't writing the criteria — it's remembering to check them ninety days later, in the middle of everything else competing for a PM's attention. This is a scheduling problem as much as a discipline problem, and it's worth treating it as one honestly.
One workable pattern: log the kill criteria as an Assumption in Prodinja's Journals at the moment you launch — the adoption floor, the cost ceiling, and the review date, captured while the reasoning is fresh, with real voice capture if that's faster than typing it out. Then set a Reminder tied to the review date, so the review surfaces on its own instead of depending on someone remembering to reopen an old doc. The point isn't automation deciding the feature's fate — it's making sure the honest verdict actually gets asked for, on schedule, instead of quietly skipped because nobody happened to think of it that quarter.
Key Takeaways
- Write kill criteria at launch, not after performance data arrives — pre-commitment is the only defense against sunk-cost bias, since post-hoc thresholds always bend to fit whatever the data already shows.
- Use three dimensions minimum: an adoption floor tied to the underlying customer job, a maintenance cost ceiling, and a strategic-fit check against current (not launch-era) strategy.
- Name a reviewer who wasn't the original feature owner so the review has a built-in counterweight to attachment bias.
- Default to sunset when criteria are missed, requiring an affirmative case to extend rather than an affirmative case to kill.
- Scale deprecation notice periods to workflow impact, not to team discomfort — high-impact features need 90-180 days, not 30.
- Treat the review date as a scheduling problem: log kill criteria where you'll actually see them again, and set a reminder tied to the review date so the check happens on schedule.
Frequently Asked Questions
When should you sunset a feature?
Sunset a feature when it misses a pre-committed threshold — typically an adoption floor or maintenance cost ceiling — at its scheduled review date, usually 90 to 180 days post-launch. Waiting for a "natural" moment to decide almost always means waiting until sunk-cost bias has already taken over the conversation.
What are good kill criteria for a feature?
Good kill criteria include a numeric adoption floor tied to the feature's underlying customer job, a maintenance cost ceiling in engineering hours or support tickets, and a strategic-fit check against current product strategy. Each needs a specific number and a specific review date — vague standards like "if it's not doing well" don't hold up under sunk-cost pressure.
How do you tell customers a feature is being deprecated?
Give customers a notice period scaled to impact — 30 days for low-impact features, 90 to 180 days for workflow-critical ones — through email, in-app banners, and direct account outreach for high-impact cases. State the reason honestly and briefly, and give a concrete migration path rather than a vague apology.
Isn't it risky to commit to killing a feature before you know how it'll perform?
The commitment is to a review, not an automatic kill — a borderline result can extend the deadline once, with a new fixed date. What the pre-commitment actually prevents is an open-ended "let's keep watching" that never resolves, which is how struggling features quietly live for years.
How is a kill-criteria review different from a regular feature retrospective?
A retrospective asks what went well or poorly; a kill-criteria review asks a narrower, binary question — did the feature clear its pre-set threshold or not. Keeping the review anchored to a number set before launch is what stops it from turning into a discussion the original feature owner can talk their way out of.