The Standish Group studied a batch of completed software projects and reported a number that still makes product owners wince: 64% of all features are rarely or never used. Broken down, 45% are never touched at all, 19% are used rarely, and only 17% are used always or often. In other words, roughly two-thirds of everything a typical team builds is, from the user's point of view, decoration.
That finding (first presented by Standish chairman Jim Johnson at the XP 2002 conference) is over two decades old, and the uncomfortable part is that newer data agrees with it. The waste is not a bug in how one team worked. It is the default outcome of building a lot before you have learned anything.
Most of what you build will never get used
Modern analytics tells the same story with bigger samples. Product platform Pendo, looking at anonymized usage across hundreds of applications, found that about 80% of features are rarely or never used, and that roughly 12% of features drive 80% of daily usage. They put a price tag on it too: public cloud companies spend an estimated $29.5 billion a year building features that customers barely touch.
Read that as a planning constraint, not a moral failing. Before launch, no one (including you) reliably knows which 17% of features will matter. You are guessing. The question is whether you spend twelve months acting on a guess, or twelve weeks testing it.
The cost of building things nobody wants
The feature data is about waste inside products that at least found a market. The harsher number is about products that did not. In CB Insights' analysis of startup post-mortems, the single most common reason companies failed was building something nobody wanted: 42% of failed startups cited "no market need."
That is the whole argument for the MVP in one statistic. The biggest risk in a new product is almost never "can we build it?" It is "does anyone want it?" Every extra feature you ship before answering that second question multiplies the cost of being wrong, without improving your odds of being right.
How to decide must-have vs. nice-to-have
"MVP" gets mistaken for "cheap and half-finished." It is neither. A real minimum viable product is the smallest thing that delivers the core value and lets you learn from real users. The discipline is in the cutting. A few questions that do the cutting for you:
- Does it serve the one core job? Name the single job a user hires your product to do. If a feature does not directly support that job, it is a candidate to cut, not a candidate to build.
- Will its absence stop launch? If the answer is no, it is a nice-to-have. Nice-to-haves are not bad ideas. They are good ideas with no evidence yet.
- What will it teach you? Favour the build that produces a clear signal (did people use it? did they pay?) over the build that merely produces more product.
- Can it wait for a real request? Many "essential" features survive precisely because no user ever asks them to justify themselves. Let the market pull features out of you.
Cut hard, ship the core, then let usage data, not opinions in a planning meeting, tell you what to build next.
How we think about it at True Dev
We have built software since 1997, and the most valuable thing we do for a client is often talking them out of features. We think product, not just code. That means we will help you find the core job, scope a launch you can actually ship, and design it so the first weeks of real usage teach you something. The goal is not to write less software for its own sake. It is to spend your budget on the 17% that matters and discover the rest from users instead of guessing.
If you have a product idea, the cheapest mistake is the one you catch before you build it. Start a project with us and we will help you scope the smallest launch that proves the point, or browse our services to see how we work.
