Product bets need kill criteria, not optimism

Most roadmap bets start with a confident story. A customer segment is underserved. A workflow is too slow. A new capability will unlock adoption, retention, revenue, or strategic position. The story may be right. The problem is not optimism itself. The problem is optimism without a decision rule.

Product bets need kill criteria, not because teams should become timid, but because bets are not wishes. A bet is a deliberate commitment of time, attention, design capacity, engineering capacity, go-to-market focus, and opportunity cost. If the team cannot say what would make the bet stop, change, or continue, it has not made a product decision. It has made a calendar reservation.

The useful move is simple: turn each roadmap bet into a small decision contract before the work starts. The contract should name the hypothesis, expected signal, review date, kill criteria, continue criteria, owner, and next action. That does not make product work deterministic. It makes learning usable.

Optimism is not a decision rule

Optimism is often treated as a cultural virtue in product teams. Founders need it. PMs need it. Designers and engineers need enough belief to push through ambiguous work. But optimism becomes dangerous when it substitutes for decision discipline.

A roadmap item can survive for months because every weak signal is interpreted generously. Low adoption becomes a messaging issue. Slow activation becomes a timing issue. Missing revenue becomes a sales enablement issue. The team keeps moving because stopping would feel like admitting failure.

That is why the roadmap needs a bet ledger, not just a sequence of features. A ledger records what the team believed, what evidence it expected, and what decision the evidence should trigger. If that operating habit is missing, start with the pattern described in Roadmaps need bet ledgers and then add explicit stop, change, and continue criteria to the most expensive bets.

Strategy helps here because strategy is not a list of priorities. Roger Martin’s Playing to Win framing treats strategy as a set of choices about where to play and how to win, not as a comforting inventory of good ideas. A roadmap bet should therefore express a choice: we believe this problem, for this segment, solved in this way, will create this kind of advantage or outcome. See Roger Martin’s strategy writing for the broader choice-based frame: Roger Martin on strategy.

Without that choice, kill criteria become arbitrary. With that choice, the team can ask: did the evidence weaken the bet, strengthen it, or show that we chose the wrong path?

What belongs in kill criteria?

Kill criteria should be written before the team is emotionally attached to the work. They do not need to be complex, but they do need to be specific enough to guide a real review.

A practical decision contract can fit on one roadmap card:

• Hypothesis: what we believe will become true if the bet works.
• Target segment: who must show the signal for the bet to matter.
• Expected signal: the observable behavior, business result, operational change, or qualitative evidence we expect.
• Review date: when the decision will be made, not when the team will vaguely check progress.
• Continue criteria: what evidence justifies more investment.
• Change criteria: what evidence says the problem is real but the approach is wrong.
• Kill criteria: what evidence says the bet should stop.
• Owner: who is accountable for convening the decision.
• Next action: what happens after stop, change, or continue.

The important part is separating stop from change. Many roadmap bets should not be killed at the first disappointing signal. If the customer pain is validated but the workflow is confusing, that may be a change decision. If the intended segment does not care, does not adopt, or does not experience the problem often enough, that may be a stop decision.

For example, imagine a B2B product team betting on an admin dashboard redesign. A weak contract says, “Improve admin experience.” A better contract says, “We believe operations managers at mid-market accounts will complete weekly reconciliation faster and with fewer support escalations if we redesign exception handling.” The continue signal might be repeated use by the intended operators and fewer support conversations about the same failure mode. The change signal might be strong demand for exception visibility but confusion around permissions. The kill signal might be that the target users do not own the task, use the workflow rarely, or keep solving the problem outside the product.

This is also where strategy and prioritization meet. If your roadmap already struggles because every stakeholder priority feels equally important, revisit Product strategy needs choice maps, not priority stacks. Kill criteria are easier to write when the team has already named the choices that matter.

What question should the review answer?

A roadmap review should not ask, “Did we ship?” Shipping is a progress update. The review should ask, “What decision does the evidence support now?”

That question changes the meeting. Instead of defending the original plan, the team compares evidence against the pre agreed contract. The PM does not need to perform confidence. Engineering does not need to argue from sunk cost. Sales does not need to protect a promise forever. Everyone can return to the same artifact and ask whether the bet still deserves scarce capacity.

The review should end with one of three decisions.

Continue means the evidence is strong enough to keep investing under the same hypothesis. The next action might be expanding the segment, hardening the experience, or increasing go-to-market focus.

Change means the original path is not working, but the learning points to a better path. The next action might be narrowing the segment, changing the workflow, adjusting packaging, or running a smaller experiment.

Stop means the bet no longer deserves investment. The next action should be explicit: archive the work, remove it from the roadmap, communicate the decision, preserve useful learning, and reallocate capacity.

This is close to the logic behind good experiment readouts. Evidence is only useful when it changes a decision. If the team already runs experiments but struggles to convert readouts into action, Experiment readouts need decision rules is a useful companion pattern.

Avoid finance theater

Kill criteria can go wrong. The most common failure is turning them into finance theater: a spreadsheet ritual that pretends every product bet can be evaluated like a guaranteed project with clean forecasts.

That punishes uncertainty instead of clarifying learning. Early product work often contains unknown customer behavior, integration constraints, adoption friction, internal readiness issues, and market timing. If kill criteria demand certainty too early, teams will choose only safe, incremental work. The organization will look disciplined while quietly starving real discovery.

The antidote is to make criteria evidence-based, not punishment-based. A kill criterion should not say, “If this does not hit a polished revenue forecast by week four, cancel it.” A better version says, “If we cannot observe meaningful engagement from the target segment after the agreed exposure window, and interviews show the problem is not urgent, stop.” That criterion protects learning. It also protects the company from dragging a weak bet across quarters.

John Cutler’s product operating writing often pushes teams to look at the real system of work, incentives, queues, and decision patterns rather than only the visible artifacts. That lens matters here: kill criteria will reflect the culture around them. If leaders punish bad news, teams will hide ambiguity. If leaders reward clear learning, teams will surface it. See John Cutler’s product writing for the broader operating-system perspective.

Rich Mironov’s product leadership writing is also a useful counterweight because it keeps returning to the practical conflicts between product intent, executive pressure, sales demands, and delivery reality. Kill criteria need that realism. They are not a purity test for PMs. They are a way to keep product leadership honest about what the company is actually choosing. See Rich Mironov’s Product Bytes.

Audit one roadmap bet

Do not start by redesigning the entire roadmap process. Start with one active bet that is large enough to matter and ambiguous enough to drift.

Open the roadmap card and add seven lines: hypothesis, expected signal, review date, stop criteria, change criteria, continue criteria, owner. Then ask the uncomfortable question: if none of these signals appear, are we really willing to stop?

If the answer is no, the team has discovered something important. Maybe the bet is not a bet at all. Maybe it is a strategic commitment, a compliance requirement, a customer promise, or an executive mandate. That work can still be valid, but it should not pretend to be evidence-led discovery.

If the answer is yes, the roadmap has become more honest. The team can still be optimistic. It can still push hard. But it now knows what optimism must eventually face: a decision.