How usage data consistently reveals that a small fraction of features drive nearly all engagement, and what that means for design priorities.
The Usage Reality Check
Here’s a pattern that plays out in nearly every mature software product: a small percentage of features account for the vast majority of user engagement. The exact numbers vary, but the shape is remarkably consistent. Typically, about 20% of features drive 80% or more of usage. The remaining 80% of features are used rarely, by a small minority of users, or not at all.
This isn’t a new insight. Microsoft famously revealed that 80% of Office users use only 20% of the features. Pendo’s research across thousands of SaaS products found that on average, 80% of features are rarely or never used. The data is clear and consistent across industries.
Yet product teams continue to add features at a relentless pace, rarely removing anything and almost never questioning whether the feature they’re building will join the 80% that nobody uses. This is a structural problem in how products are built, and it has direct consequences for user experience.
Why Unused Features Hurt
Every feature you add has a cost, even if nobody uses it. It adds complexity to the interface. It creates more options to consider, more menus to navigate, more settings to understand. It increases the cognitive load on every user, not just the users of that feature.
There’s a paradox in product design: the more features you add, the harder it becomes for users to find and use the features that matter most. Navigation becomes deeper. Search becomes noisier. The interface becomes cluttered with options that most people will never click. Each feature individually might be valuable to someone, but the aggregate effect is a product that feels overwhelming to everyone.
Unused features also carry engineering costs: maintenance, testing, compatibility checks, performance impact, and security surface area. They slow down development velocity because every change to the system must account for all existing features, including the ones nobody uses.
The Courage to Say No (and to Remove)
The first step is accepting that not every feature request deserves to be built. Most feature requests represent one user’s solution to their problem, and there’s usually a better or more general solution that serves more people without adding complexity.
Establish clear criteria for what earns a place in your product. How many users will this serve? How frequently will they use it? Does it align with the core jobs-to-be-done? Is there a way to solve this need without adding a new feature — perhaps by improving an existing one?
Even more powerful — and more difficult — is the practice of removing features. Regularly audit your feature usage data and identify candidates for deprecation. Features that serve a tiny percentage of users can often be replaced with workarounds, integrations, or manual processes without meaningfully harming the experience for those few users, while significantly improving the experience for everyone else.
Sunset features with care and transparency. Give users notice, provide migration paths, and explain the reasoning. Most users understand and appreciate a product that’s actively working to stay focused and usable.
Designing for the 20%
Once you’ve identified your core 20% of features, design the hell out of them. Make them faster, smoother, more delightful. Remove friction from the most common workflows. Optimize the experiences that the majority of users have every day.
This is where the real return on design investment lives. A 10% improvement to a feature used by 90% of users has far more impact than a new feature that will be used by 5%. Yet most teams are structurally biased toward new features over improvements to existing ones.
Shift your team’s mindset from “what should we build next?” to “what should we make better?” The answer, almost always, is the features your users already rely on every day.