Your roadmap is probably the most expensive document in the company, and most of what's on it will never get used. Pendo analyzed feature usage across 615 SaaS products and found that 56% of features were never used at all. Another 24% were rarely used. Only 12% got frequent use. That's a lot of engineering spent on software nobody opens.
Key Takeaways
- Across 615 SaaS products, Pendo found 56% of features never used, 24% rarely used, and only 12% frequently used (Pendo Feature Adoption Report).
- About 12% of features drive 80% of daily usage (Pendo).
- The Standish Group similarly found 45% of features never used, plus 19% rarely.
- Building less, and validating before building, beats shipping more.
What the Data Shows
Pendo's analysis is the most concrete version of a thing every product person suspects. Looking at anonymized usage across 615 SaaS products, they found the distribution is brutally lopsided: 56% of features were never used, 24% rarely used, 8% moderately, and only 12% frequently (Pendo's Feature Adoption Report). Put the other way, roughly 12% of features generate about 80% of daily usage volume, and 80% of features are rarely or never touched. Pendo estimated the waste at around $29.5 billion in global cloud R&D spend (Pendo).
This echoes older Standish Group research finding 45% of features in a typical product are never used and another 19% rarely used, which puts roughly two-thirds of everything built at close to zero value (feature usage data).
| Usage tier | Share of features |
|---|---|
| Never used | ~56% |
| Rarely used | ~24% |
| Moderately used | ~8% |
| Frequently used | ~12% |
Why This Keeps Happening
Features get built for reasons that have little to do with usage. A big customer asks. An executive has a hunch. A competitor shipped something. The roadmap needs to look ambitious. None of those are evidence anyone will use the thing, and once it's built, nobody measures whether they did, so the feedback loop that would stop the next unused feature never closes.
There's a compounding cost too. Every shipped feature adds surface area: more code to maintain, more tests, more edge cases, more UI to confuse users, more dependencies and more places for bugs. An unused feature isn't free after launch; it charges rent forever.
A Concrete Version
A team spends a quarter building a sophisticated custom-reporting module because two enterprise prospects asked about it during sales calls. It ships. Six months later, usage data shows 3% of accounts have opened it once, and under 1% use it monthly. Meanwhile the search function, which nearly every user touches daily, is slow and mediocre because nobody had time for it. The quarter would have returned far more if it had gone into the 12% of surface area that everyone actually uses.
The Honest Counterpoint
Low usage doesn't automatically mean low value, and killing every rarely-used feature would be a mistake. Some features are used rarely and matter enormously: data export before a compliance audit, account deletion, the admin tool your support team relies on. Others are used by a small number of very high-value customers and pay for themselves. And some features exist to win deals rather than to be used, which is a real, if uncomfortable, business function. The lesson is to measure usage and value deliberately rather than assuming, and to let evidence rather than volume drive the roadmap.
What This Means for Teams
If most features go unused, then the highest-return engineering decision is usually building less. Instrument usage so you know what's actually touched. Validate demand before committing a quarter. And be willing to remove features that nobody uses, since deletion reduces maintenance, surface area, and complexity all at once. That discipline also makes your scarce senior capacity go further, which matters more than raw output, as the SPACE framework and the build-vs-buy logic both argue. See available engineers.
Frequently Asked Questions
How many software features actually get used?
Pendo's analysis of 615 SaaS products found 56% of features were never used, 24% rarely used, and only 12% frequently used. Roughly 12% of features drive about 80% of daily usage.
Why do teams keep building unused features?
Because features get built on requests, hunches, and competitive pressure rather than evidence, and because most teams never measure post-launch usage, so the feedback loop that would prevent the next unused feature never closes.
Does an unused feature cost anything after launch?
Yes. It adds code to maintain, tests, edge cases, UI complexity, and dependencies. Unused features charge rent forever in maintenance and added surface area for bugs.
Should we delete rarely-used features?
Often, but carefully. Some rarely-used features are critical (data export, account deletion, admin tools) or serve high-value customers. Measure usage and value deliberately rather than cutting on volume alone.
The Bottom Line
Most of what you build will never be used: the data says 56% of features go untouched and only about 12% drive most usage. That makes "build less, validate first, measure after" one of the highest-return disciplines in engineering. Point your scarce capacity at the small slice of surface area people actually live in, and be willing to delete the rest.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
