The most expensive product decisions are the ones nobody made

Every product carries decisions that were never actually made. Features that exist because someone built them during a sprint and nobody questioned whether they should. Navigation structures that reflect the org chart rather than the user's needs. Workflows that follow a legacy process because "that's how it was always done" and no one has revisited whether the process still makes sense.

These are not bad decisions. They are absent decisions. Things that ended up in the product by default, by habit, or by the path of least resistance. And they are usually the most expensive ones, because they compound silently over years while everyone's attention is on the decisions that were made deliberately.

I notice this within the first week of working on any established product. There are layers that nobody owns. Not because people are careless, but because the product grew faster than the team's ability to make explicit choices about everything in it. Early on, a startup can hold the whole product in a few people's heads. At a certain scale, that stops working. Pieces start existing simply because they were built, not because someone decided the product needed them.

The cost shows up in strange ways. Onboarding takes too long because new team members have to learn not just the product, but the unspoken history of why things are the way they are. Development slows down because every change touches something that was never properly defined, so the team spends more time understanding the current state than building the next one. Users struggle not because any single screen is bad, but because different parts of the product follow different logic, built at different times by different people with different assumptions.

This is what people usually mean when they say a product has "tech debt." Some of it is technical. But a lot of it is decision debt. The accumulation of choices that were never choices.

Turning defaults into decisions

Fixing it is not about redesigning everything. It is about going through the product and asking, for each piece: was this a decision or did it just happen? If it was a decision, is it still the right one? If it just happened, should it stay?

That process is tedious. It is not the kind of work anyone gets excited about. But it is often the highest-leverage thing you can do for a product that feels heavy, slow, or hard to evolve. Not adding something new. Just finally deciding about what is already there.

The products that age well are the ones where someone periodically goes back and turns the defaults into deliberate choices. Where the implicit becomes explicit. Where the things that just happened get either validated or removed.

That is maintenance in the truest sense. Not keeping things running. Keeping things intentional.