The Feature Nobody Uses But Everyone Maintains

"Vibe code, launch, and abandon" is the culture being championed right now.

Build fast. Ship fast. Move on. The pitch is compelling — AI makes building cheap, momentum matters, iteration beats perfection. None of that is wrong.

The problem is the word "abandon." Features don't get abandoned. They get inherited.

By the engineer who wasn't consulted when the decision was made. By the team that now owns a product nobody planned to maintain. By the roadmap that lists it as active because nobody has been given permission to mark it otherwise.

I ran a portfolio audit with a product leadership team — director of design, director of engineering, director of product. We were trying to understand why morale was lower than it should have been and why we weren't hitting velocity targets. When the numbers came back, upwards of thirty percent of the team's capacity was maintaining features nobody had planned to own. That was the answer. Not a slow team — a team carrying weight nobody had made visible. I'd been in that team's position before. Maintaining things I had no permission to stop, because nobody had ever asked what the carrying cost was.

This is what happens when the first two problems compound. When you can't name which products are dying and can't get permission to kill them, you end up maintaining them forever. The delivery problem isn't that your team is slow. It's that upwards of thirty percent of their capacity is keeping things alive that nobody planned to own.

What maintenance drag actually looks like

There's a metric most product leaders can't produce on demand.

What percentage of your team's current capacity is maintaining features nobody uses?

Not KTLO for infrastructure. Not bug fixes on active products. Features — shipped, visible on the roadmap, consuming engineering time — that have no meaningful user activity, no active owner, and no sunset plan.

In every portfolio audit I've run, the answer is higher than anyone expected. Not five percent. Not ten. In mature product organizations, it regularly sits at thirty to fifty percent of delivery capacity. Half the team's throughput is life support for products nobody would build today.

The ratio that tells you most is simple: for every new initiative on your roadmap, how many products have a clear sunset plan? A product leader in one of my workshops called this the leading indicator for invisible maintenance debt. Most teams can answer the first number immediately. Almost none can answer the second.

Silent graduation

Features don't arrive in production with a maintenance plan attached. They graduate there.

A proof of concept works. Someone asks for it in production. It goes live. No owner is assigned. No sunset criteria are defined. No maintenance cost is priced. The feature is now a production system — running on infrastructure, consuming support capacity, generating bug reports — and nobody chose for that to happen.

I call this silent graduation. The experiment becomes permanent not through a decision, but through the absence of one.

The costs are invisible at first. One engineer patches it quarterly. Then monthly. Then it's on the sprint board every cycle. Nobody remembers who built it or why. Nobody knows if customers still use it. Nobody has been given permission to ask whether it should exist.

When you launched it, you celebrated. When it graduated silently into your maintenance backlog, nobody noticed. The difference between launching and landing a product is whether someone was responsible for the second act.

The compounding failure

This is where the clarity and empowerment problems become a delivery problem.

If your dashboard can't distinguish survival signals from activity metrics, you can't see which features are on life support. If your team doesn't have permission to say "kill it," they can't stop the silent graduation in progress. And if neither problem has been addressed, the maintenance backlog grows — quietly, consistently — until the team's throughput bends under the weight.

"Competing tasks make it difficult to slow down and define the problem." That's not a time management issue. That's what a team looks like when it's buried in KTLO work for features nobody planned to maintain. You can't run survival metrics on a product you can't see. You can't kill a zombie you've never been given permission to name.

The delivery problem is downstream of the clarity and empowerment problems. It's where the debt lands.

Subtraction is a delivery discipline

The framing most teams use: subtraction = failure. Removing a feature means the feature failed. Nobody wants to be the person who announces that.

The framing that works: subtraction is delivery. The team that removes one undead feature this quarter ships faster next quarter. The capacity that was consumed by life support becomes capacity for work that matters.

The ratio isn't features shipped versus features removed. It's capacity deployed on things worth surviving versus capacity consumed by things that already lost the argument.

Most teams don't track the second number. Which means they don't know what the undead are costing them. Which means they can't make the case for subtraction as a delivery act — they can only experience delivery getting slower and not know why.

The fix starts with the audit. Three questions:

What percentage of your current delivery capacity is maintaining features with no measurable user activity?

For every new initiative on your roadmap, how many existing products have a named sunset plan?

If you had to pitch your current maintenance portfolio for fresh funding today — how much of it would survive the conversation?

Those numbers are your maintenance drag. They're also your delivery headroom — the capacity that comes back when the undead get a formal ending.

The prompt

Find one feature your team is currently maintaining that you suspect nobody uses.

Don't assume. Pull the usage data. Check the support tickets. Ask the engineer who maintains it when they last heard from a customer about it.

If the answer confirms what you suspected — that's not a data finding. That's a delivery finding. The question now is: what would need to be true to stop?

Whether you're the VP who could authorise that conversation or the PM who's been quietly maintaining it — you now have the first number. That's where subtraction starts.