Pre-Committing Kill Criteria So You Stop Funding Product Bets That Won't Work

The feature graveyard is a real place. It exists in every SaaS product's codebase — a collection of capabilities that someone championed, the team built, customers largely ignored, and nobody had the political will to remove. Each gravestone represents months of engineering time, design cycles, and opportunity cost. The tombstone inscription is always the same: "We kept hoping it would catch on."

The mechanism by which product teams end up funding bets that will not work is well-documented in behavioral economics. Daniel Kahneman's research on loss aversion and the sunk cost fallacy explains why teams continue investing in failing bets: the psychological cost of acknowledging a mistake grows proportionally with the investment made, making discontinuation progressively harder over time. By the time a failing bet has consumed six months of engineering effort, the team has built a narrative that makes stopping feel like a much larger failure than it actually is.

Kill criteria are the structural intervention that breaks this pattern. They convert the discontinuation decision from an emotional judgment (made after investment has accumulated) into a mechanical check against pre-specified conditions (agreed to before the sunk cost existed). Marty Cagan, in Inspired, identifies the willingness to kill a bet as one of the defining characteristics of strong product leadership. Kill criteria make this willingness into a system rather than a personality trait.

The Two Dimensions Every Kill Criterion Needs

Kill criteria fail when they are one-dimensional. The most common single-dimension kill criterion is a usage threshold: "if fewer than 5% of users activate this feature by day 30, we stop." This is better than nothing, but it misses the scenarios where:

1. Usage is low but the users who do use it love it (an ICP targeting problem, not a product problem)
2. Usage is high but the feature is not generating the desired outcome (an activation quality problem)
3. Usage appears healthy in aggregate but the bet is not viable for business reasons (a margin or support cost problem)

Effective kill criteria cover two dimensions:

Dimension 1 — Value risk: Will customers want it enough to change their behavior? This is where usage thresholds belong. But they need to be specific about which users, in which context, performing which action. "5% of all active users activate the feature" is less useful than "15% of users who reach the [specific workflow step] complete the first [specific action]."

Dimension 2 — Viability risk: Can the business support this at scale? This covers support cost per feature user, gross margin impact, required headcount, infrastructure cost, and regulatory exposure. A feature that achieves strong adoption but requires human intervention for 30% of use cases may not be viable even if customers love it.

The qualitative criterion in the last row is often the most powerful. Usage numbers can be manipulated by positioning, in-app prompting, and notification volume. But if a discovery session can produce no customers who describe the feature as essential to their workflow, the bet is almost certainly not working.

For teams using continuous discovery practices, the customer interview cadence should include specific questions about new features within their kill-criteria window. Structured qualitative data from six to eight interviews is often more decisive than 30-day activation metrics.

Setting Kill Criteria for Different Bet Sizes

Not all product bets are the same size, and the kill criteria should be calibrated accordingly.

Small bets (under 2 engineer-weeks): A single metric threshold evaluated at a defined point. "If this UI change does not improve click-through on the secondary CTA by 10% in 14 days, revert it." The criteria can be set quickly because the consequence of either decision (ship or revert) is low-cost.

Medium bets (2-8 engineer-weeks): Two to three criteria covering both activation and at least one qualitative signal. The evaluation point should be no later than four weeks after launch. The decision options include full continuation, scope reduction, or discontinuation.

Large bets (over 8 engineer-weeks): Kill criteria should be set at multiple stages, not just at launch. Pre-launch kill criteria (for discovery and prototyping stages) should trigger before significant engineering investment is made.

The Cagan-inspired product discovery principle applies here: validate before you build. Large bets should have kill criteria at the prototype stage — before any production code is written — that answer the question "have we seen enough evidence that customers will use this to justify engineering investment?" If the prototype kill criterion is triggered (fewer than 3 of 8 test participants showed genuine enthusiasm without prompting), the bet ends with zero engineering cost.

This connects to the Opportunity-Solution Tree framework: each solution candidate on the OST should have kill criteria at the prototype validation stage before it graduates to the development backlog.

The Politics of Kill Criteria: Getting Buy-In Before You Need It

Kill criteria only work if stakeholders agree to them before the work starts. A PM who tries to invoke kill criteria after the bet is already in jeopardy will face resistance — because the stakeholder who championed the bet will dispute the criteria they never formally agreed to.

The conversation that creates buy-in has three components:

Frame the roadmap item as a hypothesis. "We believe that [feature] will [produce outcome] because [evidence]. We are going to test this belief with a [size] investment." This framing signals from the outset that the item is a test, not a commitment.

Co-define the success criteria first. Ask the stakeholder: "What would need to be true for you to consider this bet a success?" Their answer becomes the success criteria. Then ask: "What would need to be true for us to stop investing?" Their answer becomes the starting point for the kill criteria negotiation. Stakeholders are much more willing to define discontinuation conditions when they are also defining success conditions in the same conversation.

Get written agreement before launch. The kill criteria should live in the same document as the product spec or the feature brief. When evaluation time comes, the PM can point to the document both parties signed rather than asking for a retroactive judgment.

This pre-commitment protocol mirrors the clinical trial model, where stopping rules for efficacy and harm are registered before the trial begins. The analogy is useful in stakeholder conversations: "We are running this the same way a clinical trial is run — we define upfront what success and failure look like, we run the test, and we act on the result."

For teams using OKR frameworks, the kill criterion maps naturally onto the confidence rating that many OKR methodologies assign to each key result: "We are 60% confident this bet will achieve the KR. If the following conditions are met by [date], we will increase confidence. If these other conditions are met, we will stop the bet." The SaaS product team OKR design post covers how to connect kill criteria to OKR confidence ratings.

Running the Kill Criterion Evaluation Meeting

The evaluation meeting is where kill criteria either pay their value or fail. The most common failure is treating the evaluation as a progress review rather than a decision-point. Teams spend 45 minutes presenting usage data, providing context for underperformance, and scheduling a follow-up. The kill criterion is technically triggered but the decision is deferred.

The evaluation meeting should follow a strict agenda:

1. Data review (10 minutes): Present the metrics against each kill criterion. Was the criterion triggered? Yes or no. No context yet.

2. Measurement audit (5 minutes): Was the data collected correctly? Is there any instrumentation issue that would explain a triggered criterion? This is the only legitimate reason to pause before acting on a kill result. See feature adoption instrumentation for how to prevent measurement gaps.

3. Decision (15 minutes): Three options only — continue as planned, reduce scope and set new kill criteria, or discontinue. No fourth option of "wait and see."

4. Learning capture (10 minutes): What does the result tell us about the opportunity? Should it be removed from the OST, kept but deprioritized, or replaced with a different solution candidate?

The 15-minute decision time-box is deliberate. Longer decision sessions do not produce better decisions — they produce more political negotiation. When the criteria were agreed upon in advance, the decision should be straightforward. If it is not, the kill criteria were not specific enough, which is a design lesson for the next bet.

Conclusion

Pre-committed kill criteria are not about pessimism — they are about respecting the team's time and the product's focus. Every engineering week spent on a bet that will not work is a week not spent on the bet that will. Teams that pre-commit kill criteria and honor them consistently build products with fewer features, higher adoption rates, and cleaner codebases than teams that let failing bets run indefinitely.

The SaasDash roadmap health dashboard includes a kill criteria tracker that alerts the PM when a bet approaches its evaluation date. If your team is currently running bets without pre-specified discontinuation conditions, the bet audit tool will surface which active items have been in development the longest without measurable customer adoption — a useful starting point for the kill criteria conversation you should have had at launch.