I've spent 15 years shipping software. Roughly half the features I helped build were a waste of time. Not because the engineering was bad — the features themselves shouldn't have existed.
The Numbers Are Brutal
The Standish Group found that 45% of features in a typical software product are never used. Another 19% are rarely used. That's 64% of everything your team builds — the late nights, the sprint planning, the code reviews — delivering close to zero value.
Pendo's 2019 Feature Adoption Report painted an even grimmer picture: 80% of features in the average cloud product see low to no adoption. Eight out of ten things you ship might as well not exist.
Think about what that means in dollars. A team of five engineers costs roughly $750K-$1M per year fully loaded. If 64% of their output goes unused, that's $480K-$640K burned annually on features nobody wanted. Scale that to a 50-person engineering org and you're staring at millions in waste.
Why We Keep Building the Wrong Stuff
Feature requests are opinions wearing a requirements costume. A customer says "I need an export to PDF button." What they actually mean is "I need to share this report with my boss who won't log into your tool." The solution might be a shareable link, not PDF export. But we heard "PDF" and started coding.
I watched a team spend three months building an elaborate dashboard customization system because the VP of Sales asked for it. After launch, exactly 4 out of 2,000 users touched it. The VP included. He'd moved on to his next idea before the ink was dry on the PRD.
Stakeholder loudness correlates with authority, not insight. The highest-paid person in the room gets their feature built. HiPPO-driven development (Highest Paid Person's Opinion) is the default at most companies, even ones that claim to be "data-driven." Nobody wants to tell the SVP their pet feature is a bad idea.
We confuse building with progress. Shipping feels productive. Killing a feature feels like failure. So we keep adding, never subtracting, and the product grows into a bloated mess that confuses new users and buries the features people actually care about.
What Good Teams Do Differently
The best product teams I've worked with share a ruthless habit: they validate before they build.
Watch behavior, ignore words. User interviews are useful for understanding problems, not for designing solutions. People are terrible at predicting their own behavior. Instead, instrument what users actually do. Heatmaps, session recordings, analytics funnels — these tell you what matters. Surveys tell you what people think matters. Big difference.
Ship the smallest possible version. Don't build the feature. Build a smoke test. A fake door test. A landing page. A manual process that mimics the feature. If nobody engages with the lightweight version, they won't engage with the polished one either.
Set a kill threshold. Before launch, agree on what "success" looks like. Below 10% adoption after two weeks? Kill it. No debates, no extensions, no "let's give it another month." The sunk cost fallacy kills more features-that-should-die than any other cognitive bias.
Subtract more than you add. For every feature you ship, ask: can we remove one? The best products aren't the ones with the most features — they're the ones where every feature pulls its weight. Apple's original iPod had fewer features than any competing MP3 player. It won because of what it didn't have.
The Feature Bloat Death Spiral
There's a pattern I've seen destroy products:
- Ship too many features
- Product becomes confusing for new users
- Onboarding completion drops
- Support tickets spike
- Team spends more time maintaining old features than building valuable new ones
- Product stagnates
- Users churn to a simpler competitor
Every unused feature has a maintenance cost. Bug fixes, security patches, documentation updates, onboarding complexity, cognitive load on the engineering team. A feature that nobody uses still costs you every single sprint.
The Fix Is Cultural, Not Technical
No tool or framework solves this. It requires a cultural shift: the willingness to say "no" to features, the discipline to measure adoption honestly, and the courage to kill things that aren't working.
Half the features, twice the quality. That's the goal. Your users don't want more options — they want the right options, working flawlessly.
The most valuable skill in product development isn't knowing what to build. It's knowing what not to build.
Top comments (0)