Survival Metrics: How Product Teams Know When to Stop

Your roadmap is full of things that should be dead.

That initiative from last quarter that nobody talks about? Still consuming engineering hours. The integration nobody uses? Still getting maintenance patches. The feature your biggest customer mentioned once in a feedback session? Still "in progress" on every review deck.

The problem isn't that your team builds bad things. The problem is that your team doesn't know when to stop building things.

The Default State Is "Go"

Here's what most product organizations get wrong: they only measure success.

Revenue growth. User engagement. Conversion rates. Adoption numbers. Your dashboards are full of metrics that tell you when something's working. But they tell you nothing about when something isn't working — or worse, when something's working just enough to stay alive but not enough to justify the resources it's eating.

I call this the zombie project problem. And every product team I've worked with has at least two on their roadmap right now.

The enemy isn't bad product judgment. It's the sunk cost fallacy dressed up in quarterly business reviews. Your team invested nine months and $400K into a feature. Nobody wants to be the person who says "kill it." So the default state is Go. Keep building. Keep iterating. Keep hoping.

That's how roadmaps become graveyards.

What Are Survival Metrics?

Survival metrics answer one question: "Should this thing still exist?"

They're not success metrics. They're not growth metrics. They're the metrics that tell you when to stop, when to pivot, and when to invest more.

Every initiative on your roadmap should have three to five survival metrics defined before work begins. Not after. Before. Because if you can't articulate what would make you kill a project, you're not making a strategic decision. You're making a bet with no exit plan.

This is the difference between a strategy that makes decisions and a strategy that avoids them.

The AWS Tripwire

A team I worked with had a simple but effective survival metric: the 10% AWS budget tripwire.

If infrastructure costs for a new feature exceeded 10% of the projected first-year revenue, the team stopped. Not paused — stopped. They had a forced conversation: Is this still worth building? Has something changed? Do we need to rethink the architecture, the scope, or the entire initiative?

Most of the time, the answer was "rethink the scope." Occasionally, it was "kill it." Twice, it was "this is more expensive than we expected, but the market signal is strong enough to invest more."

That's the power of a survival metric. It doesn't make the decision for you. It forces the decision to happen.

Without that tripwire, the team would've done what most teams do: kept building, kept spending, and discovered it was a bad bet six months later when someone finally asked the uncomfortable question.

Three Qualities of a Good Survival Metric

Not every metric qualifies. A good survival metric has three qualities:

• It's a tripwire, not a target. You're not trying to hit it. You're watching for it. When you cross it, it triggers a conversation — not a celebration.
• It's defined before work starts. If you set it after you've invested, you've already contaminated it with sunk cost bias. The whole point is that you decided what "too far" looks like when you had no emotional attachment to the outcome.
• It answers "stop, pivot, or invest." A good survival metric doesn't just say "this is failing." It forces one of three actions. Stop the initiative. Pivot the approach. Or invest more because the signal justifies the cost.

If your metric doesn't do all three, it's a vanity metric with a scary name. And if you're relying on single-point projections instead of ranges, you've already set yourself up to miss the tripwire entirely.

Why Teams Resist This

You'd think every product team would want survival metrics. They don't.

Survival metrics make failure explicit. And most organizations don't have the culture to handle explicit failure.

When you define a tripwire upfront, you're admitting this initiative might not work. You're creating a paper trail that says "we will stop if X happens." That's uncomfortable for leaders who sold the roadmap to their board. It's uncomfortable for PMs who tied performance reviews to shipping this feature. It's uncomfortable for everyone trained to believe persistence equals competence.

Here's the thing: the failure was going to happen anyway. The survival metric just makes it visible sooner. And visible failure is cheaper than invisible failure — every time.

How to Start Using Survival Metrics

You don't need to overhaul your planning process. You need one change to your roadmap reviews.

For every initiative, ask three questions:

• What are the survival metrics?
• Have any been tripped?
• What's the recommendation: stop, pivot, or invest?

If an initiative doesn't have survival metrics, it doesn't belong on the roadmap. You're spending real money and real engineering hours on something with no exit criteria. That's not strategy. That's hope.

If a metric has been tripped and nobody flagged it, you have a culture problem. The system only works when people feel safe enough to say "this tripwire got hit, and I think we should stop."

The Real Enemy: Sunk Cost Disguised as Commitment

Let me name the enemy clearly: sunk cost thinking disguised as strategic commitment.

"We've come too far to stop now." That's not strategy. That's a gambling fallacy.

"The market just needs more time." Maybe. But did you define what "more time" means before you started? If you didn't, you're rationalizing, not strategizing.

"Our biggest customer is waiting for this." Are they paying for it? Have they committed to renewal contingent on this feature? Or are they "waiting" the same way everyone's "waiting" for something they mentioned once in passing?

Survival metrics cut through all of this. They separate strategic conviction from emotional attachment. They give you the language to say "we're stopping this" without it sounding like "we failed." Because stopping is the strategy — when the evidence says stop.

What Changes When You Get This Right

Teams that use survival metrics don't ship less. They ship better.

They kill bad bets faster. They redirect resources to initiatives with strong signals. They have roadmap reviews that produce decisions instead of status updates. And they build a culture where saying "we should stop" is valued as much as saying "we should build."

That's what good product leadership looks like. Not the courage to start things — the discipline to stop them.

And if your strategy isn't producing these kinds of decisions, it's worth asking whether you have a strategy at all — or just a list of things you're hoping will work.

Ready to build survival metrics into your roadmap?

I run a half-day workshop — Survival Metrics: Roadmap Review Reset — where your product team defines 3-5 survival metrics for every active initiative. No prebuilt curriculum. Everything is built around your team's specific roadmap and context.

The output: a decision framework your team uses at every review. Stop, Pivot, or Invest — for every initiative.

Book a Clarity Call — 30 minutes, no pitch. Just clarity on whether this is right for your team.

Not ready for a call? Subscribe to The Adam Thomas for frameworks and honest takes on product leadership, delivered biweekly.