When Did You Last Remove a Feature?
Less is more.
The other week I received this email from Grammarly.
Email from Grammarly, notifying me that they will be discontinuing their desktop appsWhile this is terrible news for me (as I do use the Mac app) the product nerd in me was all celebration.
All great product companies do this.
Last year, Spotify announced it would be sunsetting Spotify Live, Medium sunset their Profiles and Themes, and Airbnb has hit paused on Experiences to focus on their core offering.
80% of Features are Rarely or Never used
An often quoted study done by the Standish Group, known as the Standish Chaos report, found that 64% of features were rarely to never used.
A more recent analysis showed a much scarier picture.
Analysis done by Pendo on feature usage from anonymous data across hundreds of their customers found that 80% of the features were rarely or never used!
“Using an aggregation of anonymized Pendo usage data over a three-month period, we determined that an average of 12% of features generate 80% of average daily usage volume. Meanwhile, 80% of features are rarely or never used. These percentages vary only slightly by size of company, making us confident that we can use them as a proxy for the broader software industry.” - Pendo
Given the spread of different organizational sizes and industries with little differences in results, they were confident that it’s representative of the broader industry.
This paints a picture of where most products are at. Whether we believe it or not, there’s a high likelihood that the majority of your features are rarely or never used.
Unused Features are Dead Weight
You may be thinking, but who cares? Can’t it just stay there? It’s not like it’s causing any problems.
The cost is often hidden.
It’s hidden in increased complexity, usability, maintenance, and future product development.
Unused features are dead weight.
From a software point of view, it’s more code that you need to maintain. That’s code that needs to be refactored, extended, and potentially altered for new features.
The more code you have, the more complex your code base is and the more difficult it is to maintain and extend. This slows down future development.
From a non-software perspective, additional benefits and services that aren’t being used are still things you need to maintain and support. You must keep supporting them on the off-chance that one day someone does decide to use them.
There’s always a cost.
And even if none of this was true, there’s still the cost of focus.
It’s one more additional thing that needs to be discussed and considered and take up space in our minds day-to-day.
For example, the AirBnb announcement on pausing Experiences was in response to focusing on improving their core services. As much as they want to do Experiences, and probably will in the future, they know that continuing to develop and support Experiences would be time, energy, resources, and people who could have otherwise worked on improving what the vast majority of users use day-to-day.
Successful companies are well aware of this cost, and they proactively remove unused or low-usage features, products, and services from their business.
Here’s a quick reflection:
When was the last time you removed a feature or sunsetted a product?
Could simplifying your product improve the experience?
How aware are you of what features get used the most vs least?
Top Posts
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…