Kasra VaziriFeature Adoption: Why Most of What You Ship Goes Unused
Most software features are rarely or never used. Here's what the feature adoption data really says — and how to ship less, cut more, and build what sticks.
Open your product's analytics and sort every feature by usage. Now scroll to the bottom. That long tail of things almost nobody touches — you paid for every one of them. In roadmap weeks. In maintenance. In the quiet cognitive tax your users carry each time they open a more cluttered app. Feature adoption is the metric that decides whether all that building was worth it, and for most teams the honest answer is bleak.
It's not a new problem. It's just one we've gotten very good at ignoring.
The numbers are worse than you think
Pendo analyzed product usage across hundreds of companies and found that 80% of features in the average software product are rarely or never used. The median feature adoption rate — the share of users who ever touch a given feature — came in at a humbling 6.4%. They put a price tag on it too: an estimated $29.5 billion a year spent by cloud companies building things that mostly sit there.
That tracks with the classic finding everyone half-remembers. Two decades ago, a Standish Group study reported that 64% of delivered features were rarely or never used — 45% never, 19% rarely. Different decade, different methodology, same verdict. We are spectacularly good at shipping things nobody asked for.
So why do we keep doing it?
Why we keep building what nobody adopts
Three forces, and you've felt all of them.
The roadmap rewards output, not outcomes. Velocity charts, "shipped" counts, sprint burndowns — they all measure motion. None of them measure whether a single human's life got better. It's easy to look productive and create nothing of value.
No is expensive; yes is cheap. Every stakeholder request, every "quick win," every competitor-parity feature is one awkward conversation to decline and zero to accept. So the backlog grows in the path of least resistance, and the product accretes features the way a hull accretes barnacles.
We confuse launch with adoption. The demo works, the feature ships, the channel gets its 🎉, and almost nobody goes back three weeks later to ask whether anyone actually used the thing. Launch is an event. Adoption is a verdict — and it comes in late, when we've already moved on.
The AI rush is pouring fuel on the fire
Right now every product team on earth is bolting AI onto something. The pressure is real and the speed is intoxicating — which is exactly the problem. This is the same dynamic behind vibe coding's hidden bill: we can build faster than we can think about whether we should.
But faster shipping of unused features isn't progress. It's just faster waste, with a bigger compute invoice attached. The proof is already showing up — Gartner predicts that at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, citing unclear business value as a top cause. An AI feature nobody adopts is still a feature nobody adopts. The model on the front of it doesn't change the math.
What feature adoption actually asks of you
Treating adoption seriously isn't complicated. It's just uncomfortable, because it forces decisions before and after the fun part.
Define adoption before you build. Not "users will love this" — a number. What share of which users, doing what, within how many days, counts as success? If you can't answer that, you're not specifying a feature, you're funding a hope.
Instrument it on day one. You cannot manage what you refuse to measure. The feature isn't done when it ships; it's done when you can see who's using it and who isn't.
Write a kill criterion. Decide, in advance, what number means "this didn't work, and we remove or rework it." Pre-committing to that is the only thing that reliably beats the sunk-cost reflex three months later.
The bravest thing on your roadmap is a deletion
We celebrate launches. We should celebrate removals at least as loudly.
Every feature you cut makes the ones that remain easier to find, faster to ship around, and cheaper to maintain. Less surface area means fewer edge cases, less documentation, less onboarding confusion, fewer "wait, how does this interact with that" bugs. Subtraction compounds, the same way addition does — just in your favor.
This is the part of the job that doesn't demo well. Nobody puts "deprecated four features" on a launch graphic. But the products you actually love are not the ones with the most switches. They're the ones where someone had the discipline, and the spine, to keep cutting until only the essential remained.
The takeaway
Feature adoption isn't a vanity number you glance at after a launch. It's a discipline — the practice of deciding what deserves to exist in your product, then proving it earned the right to stay. Define success before you build. Measure what sticks. Delete what doesn't, out loud, without apology.
In an era where anyone can generate a working feature in an afternoon, the scarce skill isn't building more. It's the judgment to build less, and the nerve to cut the rest. Ship fewer things. Make more of them matter. That's the whole game.
Sources
Pendo — The 2019 Feature Adoption Report — 80% of features rarely or never used; 6.4% median adoption; ~$29.5B spent on unused features.
Mike Cohn / Standish Group — Are 64% of Features Really Rarely or Never Used? — the classic CHAOS finding: 45% never used, 19% rarely.
Gartner — 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025 — unclear business value a leading cause.