There is an uncomfortable finding that shows up again and again in software, in study after study and in the honest usage data of almost any product: most of the features a team builds are rarely or never used. A large share of what gets shipped, argued over, and celebrated ends up as a button almost no one clicks. This is not because the teams are bad at their jobs. It is because building a feature and getting a feature used are two entirely different things, and almost everyone treats shipping as the finish line when it is really only the start. The gap between what is built and what is used is one of the quietest and most expensive problems in software.
The reason it matters is that an unused feature is not free. It feels free, because once it is shipped the cost seems paid. But every feature that exists has to be maintained, tested, and kept working while everything around it changes. It sits in the interface, making the things people actually use harder to find. It adds complexity that makes every future change slower and riskier. A product is not improved by the features it contains; it is improved by the features people use, and everything else is weight the product has to carry.
Shipping is a cost, not a finish line
The mental model that causes the damage is treating a shipped feature as a completed asset. It is more accurate to treat it as a liability that has to earn its keep. Shipping is the moment the ongoing cost begins, not ends. From that point on the feature must be maintained, kept compatible, supported when it confuses someone, and carried along in every future change to the system. If people use it, that cost buys real value and is well spent. If they do not, the cost is pure waste that quietly accumulates. The question that should follow every feature is not "did we ship it" but "is it used", and most teams never ask the second question at all.
Why unused features pile up
Features accumulate because the forces pushing to build are strong and the forces pushing to not build are weak. A customer asks for something, and saying yes feels like good service. A senior person is convinced a feature is essential, and arguing is costly. A competitor has it, so it feels risky not to match. In every case building feels productive and refusing feels obstructive, so the default is yes. The trouble is that a request is not evidence of use. The person asking may not use it much themselves, and the many who never asked will never touch it. Multiply that by every well-intentioned request over a few years and you get a product bloated with features that each made sense in isolation and that collectively no one can navigate.
Unused features tax the ones people use
The real damage of an unused feature is not its own wasted cost; it is what it does to everything else. Each one adds to the surface that must be maintained and tested, so a team spends more of its time keeping dead weight alive and less building what matters. Each one clutters the interface, so the features people need are buried among the ones they do not, and the product feels more confusing than it should. Each one adds complexity to the system, so every future change is slower and more likely to break something. A product with a few well-used features is sharp and fast to improve. A product carrying years of unused ones is slow, confusing, and expensive to touch, and the unused features are what made it so.
Build on evidence, not on requests
The way out starts with a simple discipline most teams skip: measure what is actually used. Instrument the product so you can see which features people use, how many of them, and how often, instead of guessing from impressions or the volume of requests. The picture is almost always stark, a small core doing nearly all the work and a long tail barely touched, and that picture changes decisions. You stop building on the strength of the last confident request and start building on evidence of what people actually do. You can tell a genuinely valuable feature from one that only sounded good in a meeting. And you gain the thing that makes good products good: the ability to say no to building, backed by data, rather than saying yes to everything and hoping.
A worked example
A company came to us with a product that had grown slow to change and confusing to use, and they assumed they needed to rebuild it. Before agreeing, we instrumented it and looked at what customers actually used. The result was the usual one, only starker than they expected: a small set of features accounted for almost all activity, and a large number of things they had spent real money building and maintaining were hardly touched at all. The product was not failing because it lacked features; it was struggling under the weight of the ones no one used. Rather than rebuild, we helped them retire the genuinely dead features after checking the data, simplify the interface around the core people actually relied on, and put in place a habit of measuring usage before adding anything new. The product became faster to change and easier to use, not by building more, but by carrying less.
Fewer features, better used
The instinct in software is almost always to add, because adding is visible, feels like progress, and answers whoever is asking. But a product is only as good as the parts of it that get used, and everything else is cost dressed up as value. The teams that build software people love are not the ones that ship the most; they are the ones that build on evidence of use, are willing to say no, and treat removing an unused feature as normal and healthy rather than as failure. Before you build the next feature, the question worth asking is not whether someone wants it, because someone always does. It is whether, once built, it will actually be used, and whether you will ever check.
Building software that stays lean and genuinely used, by deciding what is worth building, measuring what actually gets used, and cutting what does not, is central to how we approach our custom platforms and applications work. Book a discovery call and we will help you build fewer features that more people use.
Frequently asked questions
Why do so many software features go unused?
Because most features are built in response to requests and opinions rather than evidence that people will actually use them. A customer asks for something, a senior person is sure it is needed, or a competitor has it, and the feature goes on the roadmap without anyone testing whether real usage will follow. Saying yes feels productive and saying no feels obstructive, so the default is to build. Add to that the fact that a request for a feature is not proof anyone will use it, and that the person asking often would not use it much either, and you get the familiar result: a product steadily accumulating features that made sense to build at the time and that almost no one touches now.
What is the cost of building features nobody uses?
The cost is much larger than the time spent building them, because an unused feature does not simply sit there harmlessly. It adds to the code that has to be maintained, tested, and kept working as everything around it changes. It adds clutter to the interface, making the features people do use harder to find. It adds complexity that slows down every future change, because more moving parts mean more that can break. And it consumes attention and roadmap space that could have gone to something people actually want. A feature is not a one-off cost you pay when you build it; it is a standing cost you pay for as long as it exists, whether anyone uses it or not.
How do you know which features are actually used?
You measure it, which most teams do not. Instrument the product so you can see which features are actually used, by how many people, and how often, rather than relying on impressions or on who shouted loudest for something. The data is usually sobering: a small share of features accounts for the overwhelming majority of use, and a long tail is barely touched. Once you can see real usage, decisions change. You build the next thing based on evidence of what people do, not on the last confident request, and you can finally tell the difference between a feature that is genuinely valuable and one that merely seemed like a good idea when someone asked for it.
Should you remove features that are not used?
Often yes, and the reluctance to do so is why products bloat. Every feature you keep is a feature you maintain, so removing one that is genuinely unused reduces complexity, cleans up the interface, and frees effort for what matters. The caution is to check the data first: confirm a feature really is unused rather than used quietly by a few people who depend on it, and communicate before removing anything customers can see. But the instinct to keep everything forever, just in case, is exactly what turns a sharp product into a bloated one. Treating removal as a normal, healthy part of product work, not an admission of failure, is what keeps software lean enough to keep improving.