Product Debt: Shipping Got Cheap. Undoing Didn't.

When building something costs almost nothing, teams keep building. AI coding tools removed the old natural brake on product scope: development time. A feature that used to need a quarter of negotiation and a sprint of work now takes an afternoon.

One commenter put the shift in one line: building became faster, and validation and adoption became slower and harder. The scarce resource is no longer engineering capacity. It is knowing what deserves to exist.

• The cost of building a feature dropped by an order of magnitude.
• The cost of deciding, validating, adopting and maintaining it did not.
• So the volume of features grows faster than anyone's ability to make them fit together.

Technical debt lives in the code. Users rarely see it directly. Product debt lives somewhere worse: in the user's head.

Product debt is a pile of disconnected, poorly thought-out features. Each one was locally reasonable when someone shipped it. Together they form a product nobody can explain in one sentence.

Every feature asks the user to learn something, make another decision, or navigate one more menu. AI made building faster. It did not make users learn faster. People absorb change at human speed, and in B2B it is even slower, because a whole organisation on the client side has to understand the change and roll it into its own processes.

And users do not file a ticket saying "your product is too complex now". They quietly leave for something simpler.

We are not the ones buried under the features. Our users are, and they don't complain. They leave.

Here is the data point that made this concrete for me.

On a connected-device product we work on, an API had been bolted onto the side of the system to solve a specific need. It worked for a while, and it caused a steady trickle of problems. Eventually the architecture was reworked properly and that functionality was folded into a broader, cleaner API. Nobody killed the feature. It was simply rebuilt the way it should have been from the start.

According to Jira, building the original side API took about three weeks. Retiring it took three months.

The software runs on premium devices installed at customer sites, and many of them are often offline. We could not switch the old API off until the entire fleet had updated to a version that no longer needed it. So the team spent weeks persuading customers that they really did need to install the update, and that time produced nothing new for anyone.

Anything that leaves your servers (device firmware, SDKs, public APIs, partner integrations, data formats other people depend on) turns "we'll just remove it later" into a multi-month project.

Jira tells you how long a feature took to build. Nothing tells you how long it will take to get rid of it.

• Build: about 3 weeks, fully under our control.
• Remove: about 3 months, largely outside our control, dependent on every customer's update behaviour.
• And this was the good case: the change was clearly right and nobody was arguing about the feature's value.

The most common pushback in the discussion was fair: don't reject features, put up a filter. Require discovery in every spec. Set a revenue bar a feature has to clear. Ask "what does this replace?" before "what can we add?". Make everyone on the team wear a product hat.

All of that is good practice. But from where I sit it has three limits.

First, a process-driven "no" is still a "no". You can run an idea through every filter, prove together that it is not worth building, and still leave people frustrated. The energy cost is shared out, not removed.

Second, filters require maturity. Companies with a mature product setup already have these filters, because they have the common sense to build them. The companies drowning in features usually have nobody internally whose job is to build that process, and often nobody asking for it.

Third, metrics are retrospective. Usage, retention and value metrics are essential, and they will show you a lot of waste. But they show it after the money has been spent. At that point the feature exists, and the only way out is decommissioning, which, as above, costs more than building. Before launch you mostly cannot know. A startup still searching for product-market fit honestly does not know which feature will land. Firing several shots is sometimes the rational strategy.

So we are back where we started: you can't reliably predict what will work, and removing what didn't work is more expensive than building it.

If you cannot reliably predict which features will earn their place, and you cannot afford to say no to everything, the remaining lever is the cost of being wrong. Treat reversibility as a product and architecture requirement, not an afterthought.

A good line from the discussion fits here: find the Minimum Viable Problem before building the next Minimum Viable Product.

• Label every feature at birth: experiment or commitment. Experiments get an expiry date when they launch, not when someone finally gets annoyed.
• Keep experiments at the edge: behind flags, outside the core data model, outside public APIs and device contracts.
• Put "cost to remove" next to "cost to build" in every estimate. If removal is expensive, the feature needs a higher bar.
• For anything that leaves your servers (devices, SDKs, integrations), design the version-gap and sunset path before the first release, not after.
• Track adoption per feature from day one, so the decommission decision is a number, not an argument.
• Schedule removal the way you schedule releases. Mature products need periodic cleanup phases, and removal belongs in them.

My original post on LinkedIn ended with that question. After 36 comments my answer is: not from willpower. Willpower runs out and the team keeps shipping.

It comes from three places. Architecture that keeps mistakes cheap. Data that turns arguments into numbers. And sometimes an outside voice. An external product lead can say "not this" to a founder in a way an employee often cannot, and takes the friction that would otherwise burn out the internal team.

When building is free, the most valuable product skill is not shipping. It is keeping the product small enough that users still understand it.