Feature Creep vs Feature Debt

We've all been there. The roadmap looks clean. The MVP is tight. Then comes the phrase that haunts every product owner's dreams: “Wouldn't it be cool if…”

What follows is never a single decision. It's a hundred small, individually reasonable ones, each costing a few days and none of them obviously wrong — until a year later, when a two-line change takes a sprint and nobody can explain why the settings screen has four tabs.

The Mirage of More

Feature creep isn't usually malicious. It's born from enthusiasm, and from a belief that sounds obviously true: more utility equals more value. Economic theory calls the limit of that diminishing marginal utility — each addition is worth a little less than the last. In software it's worse than diminishing. Past a certain point it goes negative, because every new feature is also a tax on every existing one.

When you add a feature, you aren't just adding a button. You're adding:

• New code paths to test, maintain and eventually migrate.
• Cognitive load for the user — one more option in every decision they make (Hick's Law).
• A constraint on every future feature that has to coexist with it.
• Documentation, onboarding copy and support scripts.
• A support surface: the tickets, the edge cases, the one enterprise customer who now depends on it.

The costs land in different budgets, on different quarters, in front of different people. That's the whole reason this keeps happening to smart teams: the benefit is concentrated and immediate, and the cost is diffuse and deferred. It is structurally hard to see.

Try it yourself: the trap

Notice how easy it is to add a feature compared to the effort required to claw the satisfaction score back.

Creep versus debt

The two words get used interchangeably and they describe different things. Creep is a behaviour — the steady widening of scope past the product's original argument. Debt is the residue that behaviour leaves in the codebase and the interface. You can have creep without much debt if you are ruthless about implementation. You can also inherit crushing debt from a product that never crept at all, just aged.

The Psychology of Addition

Why is subtraction so hard? A study published in Nature (2021) gave people a range of problems — a Lego structure, an essay, a travel itinerary, a grid puzzle — and asked them to improve each one. Across the board, participants systematically defaulted to adding components rather than removing them, even where subtraction was the cheaper and better answer. Prompting them that removal was allowed, or giving them more time to think, narrowed the gap. Left to instinct, they added.

Product organisations then take that instinct and pour incentives on top of it. Nobody has ever been promoted for the feature they deleted. Roadmaps are written as lists of additions, launch posts announce arrivals, and the performance review asks what you shipped. Subtraction is invisible labour in a system that pays for visible artefacts.

Two other biases finish the job. Omission bias makes the harm of a bad addition feel smaller than the harm of a removal, because one is something we did and the other is something we broke. The endowment effect makes every existing feature feel more valuable than it is, purely because it already exists — which is why the argument for deletion always sounds riskier in the room than the data says it is.

Subtraction adds value.— Matthew May

The Debt Collector Calls

Feature debt accumulates like financial debt, but with variable interest rates you don't get told about in advance. A feature you added for a single client two years ago might block a critical infrastructure upgrade today. That gives it an effective interest rate of 1000% — and you only find out the day the payment is due.

Signs you are drowning in feature debt:

• Onboarding new engineers takes months, not weeks.
• Simple changes cause regressions in unrelated parts of the app.
• “We can't touch that” becomes a common phrase in engineering meetings.
• Estimates have quietly tripled for work that looks identical to last year's.
• Your settings menu looks like the cockpit of a 747.

Three kinds of feature debt

Lumping it all together is why the conversation stalls. In practice there are three kinds, and they have wildly different repayment costs:

• Surface debt — clutter in the interface. A menu with nineteen items, four ways to start the same task. Cheap to fix, and the fix is almost always deletion. This is the debt users feel every day.
• Structural debt — the feature has grown roots into the data model, the permissions system, the billing logic. Expensive but tractable, and usually worth scheduling deliberately rather than ambushing a sprint with it.
• Conceptual debt — the product now contradicts itself. Two features imply two different mental models, and no amount of refactoring fixes that, because the problem isn't in the code. This is the expensive one, and the only cure is a decision about what the product actually is.

Conceptual debt is what kills products, and it's the kind teams are least equipped to name — it doesn't show up in a linter, a bug count or a latency graph. It shows up as a support team that can no longer explain the product in one sentence.

Running a subtraction audit

The counterweight to a roadmap of additions is a recurring, scheduled hunt for things to remove. Every quarter, half a day, whole product team in one room. The shape that's worked for me:

1. Inventory honestly. Every feature, with its 30-day active usage next to it. Not opinions — numbers. Most teams discover a long tail used by under 2% of accounts.
2. Sort by cost, not by usage. A rarely-used feature that costs nothing to keep can stay. A moderately-used one that blocks three roadmap items is the real candidate.
3. Write the obituary before the decision. One paragraph: who used this, why we built it, what we're replacing it with. If you can't write a paragraph a customer would accept, you're not ready to remove it.
4. Deprecate loudly, delete quietly. Announce, give a window, offer a path. Then remove the code — a feature that's hidden but still in the codebase is debt you've stopped collecting value from.

The first audit is uncomfortable and the second one is fun. By the third, someone on the team will propose a removal unprompted, which is the point: you're not running an exercise, you're installing a reflex.

The Solution: the Power of “No”

Fighting feature creep requires a cultural shift, not a process document. It means celebrating the features you didn't build. It means refactoring is treated as first-class work rather than a chore done on weekends. And it means the person who says no has to be armed with something better than taste.

Three habits do most of the work:

• One in, one out. A new surface in the primary navigation costs an existing one. Scarcity forces the ranking conversation you'd otherwise avoid.
• Ask for the sentence, not the feature. “What does this let a customer do that they can't do today?” If the honest answer is “the same thing, differently,” you have a redesign on your hands, not an addition.
• Price the no. Never block — trade. We can ship it this cycle if the migration slips two weeks. Making cost visible turns a gatekeeper into a partner, and it's a far harder position to overrule.

Next time you feel the urge to add, ask:

Knowing whether it worked

Subtraction is easy to argue for and hard to prove, which is why it loses to features in most planning meetings. Instrument it like anything else. The numbers I watch after a removal:

• Time to first meaningful action for new accounts. This is the one that moves most reliably when clutter goes.
• Support contacts per hundred active accounts, split by topic. Deleting the fourth way to do something usually deletes a category of ticket with it.
• Change lead time — how long from a small change being agreed to it being live. This is your interest payment, made visible.
• Churn among the affected cohort. Always check. Roughly once in ten, the long tail turns out to be load-bearing for a customer segment you underestimated, and you want to learn that from a dashboard rather than a renewal call.

Do this two or three times and something changes in the room. Removal stops being the risky option that needs defending, and starts being a normal move with a known payoff — which is the only durable defence against “wouldn't it be cool if.”