Every feature should earn its place

A common story in product development goes like this: execution is cheap now, so why not build more things and see what sticks?

There is some truth to that. The cost of producing software is falling. It has become easier than ever to go from an idea to a working prototype and implementation. Teams can test more ideas, explore more quickly, and get further before committing significant engineering time.

But while the cost of building a feature is going down.
The cost of carrying a feature is not.

Products rarely fail because they lack features. They fail because they lack the right features, or because the features they have are poorly conceived. They also fail more gradually, by trying to do too many things at once, causing instability, increasingly lower quality and losing clarity about the problem they exist to solve.

Every shipped feature adds surface area to the product. It creates new interactions, new failure modes, new design decisions, new support questions, and new expectations. It becomes part of what the team has to maintain and part of what users have to understand.

That is the tradeoff behind “just build it and see.” It is a is a tactic, but it is not free.

It works well for exploration. It works for prototypes, internal tools, temporary experiments, and ideas that can remain isolated until they earn a place in the product. Lower execution costs are genuinely valuable in those cases. They let teams learn faster.

In a world where building is easy, the real cost comes later.

Many teams worry that a feature might fail but failure is usually clear. You can remove it, learn from it, and move on. The harder case is a feature that succeeds just enough to survive. Some users adopt it. A few workflows start to depend on it. The team now owns it. It may not have made the product meaningfully better, but it has made the product larger.

That is how products become cluttered. Not because teams intentionally choose it, but because the threshold for adding something falls below the threshold for living with it.

Agents increase this risk. They make it easier to add things, which makes restraint more important. Previously this restraint was built in to the process as building was the expensive part, so you tried to make sure you were building the right things.

No longer it’s about whether something can be built, it is why it should be built or why it is right. It is about whether it deserves to be carried, supported, and allowed to shape the product over time.

Every feature should earn its place.

Not because implementation is expensive, but because its existence is.