Most product people are familiar with the sticky problem of feature bloat. You may also recognize the issue by its other uncomfortable names: feature fatigue, feature creep, or feature overload.
It’s the thing that happens when, for instance, the machine you bought to make the world’s best, quickest espresso also tells you the weather and time, is equipped with an AM and FM radio, has ten settings for temperature, bonus options for froth consistency (thin to thick), and comes equipped with iPhone-integrated alarm tones that tell you when your espresso is done (that part admittedly sounds sort of neat).
While the makers of this espresso machine may have listened to user wants, the inevitable loss of frustrated and confused current and potential users would indicate that the creators didn’t focus on user needs. Yeah, a handful of users may have asked for bells and whistles, but fundamentally what they wanted was a damn good, quick espresso. Put another way, the espresso machine makers prioritized capability over usability and ignored real customer needs.
As MSI.org wrote in a study of the feature fatigue problem over a decade ago: “Because consumers give more weight to capability and less weight to usability when they evaluate products prior to use than they do when they evaluate products after use, consumers tend to choose overly complex products that do not maximize their satisfaction, resulting in ‘feature fatigue.’”
Echoes Rian Van Der Merwe in his more recent article How to Avoid Building Products That Fail: “…more isn’t necessarily better.” Touché.
While loading up features in the beginning may buy you some early users, the high cost of alienated, churning customers, the expense of accruing and paying down additional technical/engineering debt, the potential confusion regarding your product and brand identity, and frustration from engineering and product teams (complete with a loss of organizational trust in your decisions) can lead to catastrophe.
Of course, the espresso machine is a simplified example. In reality, your product-bloating features may initially seem essential but turn out in time to be unnecessary — at which point it may be too late. Your challenge, then, is to decide which features your product and customers actually need and which you can realistically afford and to avoid the others like the plague.
So how to avoid falling into the tempting trap of feature overload? With the laser-focused ammo of a four-tiered process: be informed, mindful, selective, and cutthroat with your feature decisions.
1. Make More Informed Decisions by Validating Feature Requests
Considering all customer feedback does not mean taking all customer feedback. This means you must separate the signals — the worthwhile feedback — from the noise. You can do so by asking validating questions about the quality and significance of customer feedback before acting on it. Primary indicators of “valid” feedback include volume, frequency, request source, and intent.
Is a feature request high-volume or limited to a few customers? Does it come up with some frequency? If you say “no” to one or both of these questions, it may be a sign that the request is noise.
Additionally, the source of the feature request matters: you should know how long the person behind a request has been a customer, their use case, account plan/level/type, their industry, and — depending on your company — how satisfied they are with your product overall (NPS). This will give you a greater measure of the request’s relevance.
If the feature seems actionable, then dig a little deeper to ask what the intent of the request is: What is the underlying pain behind the request? Is there an underlying pain that justifies the feature request? It is your job to use the product management resources at your disposal — from usability tests to field studies to surveys — to uncover your customers’ true needs. Ensure that you only build things that solve actual, real problems, or you may find yourself sagging under the weight of unnecessary features.
2. Make More Mindful Decisions By Considering Complexity Costs and Technical Debt
You know the old saying, “There’s no such thing as a free lunch?” That adage applies to features, too.
Development and support costs are just the beginning of a feature’s expense. But woe to the product manager who does not consider the complexity costs and technical debt a given feature adds to their product.
As Kris Gale, VP of Engineering of Yammer put it to First Round Review: “Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer.” What may take two weeks of coding to develop, for instance, may take much more work and time to maintain down the road.
You must decide whether or not a feature’s complexity cost is necessary or unduly burdensome. A potent mix of common sense, intel from engineering, and data testing that evaluates the feature’s usability and usage can help drive this interrogation. If you do decide to move forward, make sure to continuously check that customers are using and getting value from the feature (see: that it’s meeting your customers’ needs). Have you accidentally made their experience unnecessarily complex? If so, take stock, pivot, and be more mindful moving forward.
3. Make More Selective Decisions By Considering What Matters and Saying NO
“Yes” sounds good, doesn’t it? We tend to equate “yes” with positive, happy things, and “no,” with negative, bad things. But it isn’t that simple.
Oftentimes a “no” to a feature request can actually mean a yes — a yes to remaining aligned with your product vision, your overall product strategy, and other business goals. These are the things that really matter and can be forgotten when in the weeds of product and feature development.
Feature doesn’t solve an actual problem? No. Doesn’t align with your company’s core purpose? No. Not enough demand for a feature (as you’ve discovered when validating it)? No way, José.
If you’re doing your job, “no” should be the answer to the majority of your feature requests. That way, the features that get a “yes” are the ones you, your team, and your customers know have real value. Being more selective also has the added, crucial effect of making you a more trustworthy product manager, which means you can more effectively make decisions that combat the feature bloat that make your team and customers feel, well, sick.
4. Make More Cutthroat Decisions by Removing Bad Features
Saying no to proposed features is often not enough. Sometimes you’ll need to be even more brutal by doing away with poor product features entirely. These are vampire features — learn to recognize them, and then kill them before they kill your product.
If a feature’s complexity cost outweighs its benefits, if it doesn’t meet real customer needs, if only a handful of customers use it, if it’s outdated or irrelevant, etc. etc. — take a deep breath and cut it.
Yes — you (and your engineers… and others) have given this feature life, nurtured it, and even made sure it’s easy on the eyes. But what has it done in return? It’s harmed your business and the integrity of your product. Make like a mob boss and whack it.
In Sum
Feature bloat can cost you precious resources, weigh down your team, and harm the integrity of your product. By making informed, mindful, selective, and cutthroat feature decisions, you can ensure that you’re building a focused, manageable product that meets a true customer need.
About the Guest Author:
Sara Aboulafia is a member of the marketing team at UserVoice. Outside of work, Sara writes and performs music, binge-watches comedy, and spends an unhealthy amount of time futzing with technology before happily retreating to the woods.
