Deciding Whether a Feature Earned Its Place

The decision does not end at launch

Teams treat the choice to build a feature as the decision and its launch as the conclusion. But a feature, once shipped, continues to cost: it must be maintained, tested, kept compatible, and reasoned about in every future change. The question of whether it belongs does not end when it launches; it should be revisited in light of how the feature actually performed against the reasons it was built.

This is uncomfortable because it means admitting that some shipped features were not worth it. But a product that never reconsiders past additions accumulates them, and the weight of features that did not earn their place slows everything that comes after.

What earning a place means

A feature earns its place when its ongoing value to users justifies its ongoing cost to the product. A capability that many people rely on clearly earns its keep. One that almost no one uses, or that a small number use while it complicates the experience or the codebase for everyone, has not. The assessment weighs genuine value against the complexity, maintenance, and conceptual load the feature imposes on every future decision.

• Weigh a feature’s real, current value against its ongoing cost, not its launch effort.
• Notice features few use that still complicate the product for everyone.
• Reconsider features against the reasons they were built, after enough real use.

The discipline to remove

Acting on the assessment means being willing to remove features that did not earn their place, which is harder than adding them. Removal must be handled with care for the people who do use a feature, with notice and migration where appropriate. But declining to remove anything, out of reluctance to disrupt a few users or to admit a misjudgment, lets the product grow heavier indefinitely. A coherent product is maintained as much by removal as by addition.