Removing Features Without Pissing Off Your Users
Let’s talk about Feature Bloat, Time to Value, Aha Moments, Hyrum’s Law, and the Sunk Cost Fallacy.
Feature Bloat Kills Products
Products with a ton of features tend to make the user experience worse for most people. Despite this, most products (especially enterprise ones) eventually end up with “feature bloat.”
While feature bloat might not necessarily make you lose your top enterprise customers (they’re the ones who requested all these features anyways), it alienates the vast majority of your normal, non-power users. This can create a vacuum of innovation that emerging competitors can take advantage of (e.g., Atlassian vs. Trello, which ultimately led to an acquisition)
Users and stakeholders always advocate for new features, but they rarely tell you to remove a feature. This doesn’t mean removing features won’t improve the product.
The pain of losing a feature is immediate, but the benefits aren’t apparent until later down the road. In this article, I’ll explain why feature bloat is bad and how to remove features without pissing off your users.
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away”.
— Antoine de Saint-Exupery
More Features can be a Bad Thing
Excessive features often lead to poor information architecture (IA), which makes it harder for new users to experience their first “aha moment,” which ultimately increases the time to value (TTV) and impacts user retention.
IA can be understood as the hierarchical relationship and connections between parts of your product. Good IA is critical as it makes in-product navigation easy and intuitive. Unfortunately, many product teams recklessly tack on new features onto their IA without considering the ripple effects it has on the end-to-end experience.
The “aha moment” is the point at which your users experience true product value for the first time; TTV is how long it takes them to reach that point. This is critical, as users who experience their “aha moment” have a much higher retention rate.
These three related concepts can make or break your product’s new user retention. Users who experience their “aha moment” at an earlier point tend to have a much higher retention rate.
Coffee Machine TTV Example
Let’s take a look at coffee machines as an example. The TTV would be the time between unboxing the machine and getting their first sip of coffee (the “aha moment”).
Traditional coffee machines come with thick instruction manuals, tons of gauges, buttons, switches, and levers. Most new customers would get frustrated at the amount of time and effort required to get a simple cup of coffee.
On the other hand, Keurig has just a couple intuitive steps: open pod slot, place pod in, close slot, and press button.
Even if other coffee makers produce better coffee, it’s needlessly complex for most users, and it takes them forever to experience their “aha moment” (if at all).
Good products adopt a similar mindset. Users who use your product hire it for a specific “job” (according to JTBD). Most of those users are satisficers (we often incorrectly assume our users are maximizers); as long as the job is accomplished at a “good enough” level, they’re content.
As your product grows, features are often added to accomplish secondary and tertiary goals some of your users might have (or to help power users). While this might be perceived as “improving the product,” it usually has the opposite result. Instead, focus on other more productive areas of the product to work on; I like using the Kano model as a framework for this.
This does not mean we should just ruthlessly gut all features not related to the core JTBD. We need to consider how removing features impacts some of our users. Enter: “Hyrum’s Law” or the “Law of Implicit Dependencies.”
Hyrum’s Law
A Google engineer “Hyrum Wright” once said, “with a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.”
Although he referred to API design specifically, we can extrapolate his thought to extend into the realms of product and design. Reworded, “Hyrum’s Law” can be interpreted as “at a certain scale, anything your product offers will be (correctly or incorrectly) used by someone out there.
FeedbackPanda Hyrum’s Law Example
An interesting example of this comes from FeedbackPanda, a tool for student feedback templates. The team tried to deprecate an extra unused input field that allowed users to enter a particular ID associated with their students.
Within minutes, they received several angry customer complaints. Turns out, a lot of teachers used the ID field as a private note about each student like, what their favourite color was, and now it was all gone.
Instead of a knee-jerk reaction to add the feature back, you should evaluate the feature in detail using the following decision tree.
Evaluating Features for Removal
I consider three factors when my team and I debate whether or not we should remove a (non-prerequisite or core) feature. Features that should be removed fall beneath your team’s designated “minimum usage” threshold or ones that do not correlate with higher retention rates.
In the FeedbackPanda example, the feature does meet the usage bar and does correlate with higher retention; however, the feature is not being used as intended. Therefore the team should redesign the feature to match its use case. When redesigning features, you should be careful of modifying the IA as a feature’s usage and value are closely related to its location.
The use of the student ID field is unintended. The user’s intent wasn’t to enter a student ID but rather to use it as a private freeform note area. Therefore the obvious solution would be to implement a notes feature.
If your team does decide to revise a feature you planned to remove, make sure to implement tracking to measure its usage and consider whether or not it negatively impacts the TTV. Furthermore, the revised feature exists on the same screen (ideally in a similar location). In this example, the notes screen would no longer be as valuable if moved to another part of the product.
Removing Features vs. Sunk Cost
Sometimes removing a feature has some pushback from stakeholders. In most cases, the marketing or sales team is resistant to removing features because it might hinder their ability to close new clients (more features = more perceived value).
Although sales teams are evaluated based on the volume of sales, businesses aren’t. The health of a business is often measured using APRU (average annual recurring revenue per user). The “annual” and “recurring” part of APRU implies the importance of having a healthy retention (which is linked to all the concepts I discussed earlier).
On the other hand, some stakeholders think the resources spent adding the feature are a sunk cost, but we shouldn’t let the Sunk-Cost Fallacy cloud our thinking.
Sunk-Cost Fallacy is the tendency to follow through on an endeavor if we have already invested time, effort, or money into it, whether or not the current costs outweigh the benefits. Consider that most of the cost for a feature is not in the initial development but in the long-tail time after it is launched (maintenance, customer support, documentation, etc.).
A responsive and straightforward product with a temporarily disgruntled customer is better than a slow and complex behemoth that allows every customer to do everything. Don’t be afraid to champion the removal of certain features over implementing new ones.
“If you design for everyone, you delight no one. That leads to mediocre products”.
— Alan Cooper
Ready to level up your design skills and reach your full potential? Subscribe to The Ambitious Designer newsletter for weekly doses of UX insights, frameworks, and practical career advice.
