The 5 Whys Of Feature Bloat

It seems that just about everyone knows that a product that is a large heap of stinkin’ features is a Not Great Thing. There are hundreds of articles written on the topic of good product management and why it’s so important to fight the good fight against feature bloat. 

You probably have a great product team comprised of smart, well-intentioned people who care about the customer and are thoughtful about the classic trade-offs in product management. Perhaps you're on that team.

So, why do so many products become feature bloated over time — and how do we go about reducing the likelihood that ours will fall into that trap?

As a thought exercise, I thought I’d do a simple 5 Whys Analysis of Feature Bloat and see what road it would lead me down.

1. Why do we have feature bloat?

Because we regularly add new features but rarely take features out. The net result, over time, is that products accrue more and more features. It’s just simple arithmetic. We add more than we subtract.

2. Why do we regularly add features but rarely take them out?

Because adding features is easy. As product leaders, our job is to build great products and create many happy users. Improving the product with new features is a common way to do that. Most of us have a long list of ideas for improvement submitted by customers, prospective customers, our sales team, marketing team, customer team, founders, etc. Most of our time is spent figuring out which of these features to add based on potential impact and available resources — and then adding those features. As product leaders, we may get criticized every now and then for which ideas we picked, but not for picking some ideas. We’re expected to improve the product and add features our users are asking for. 

I don’t think I’ve ever seen a product team criticized for shipping too many new features.

So, at a relatively regular rate, we keep adding features.

But, more interesting is: Why do we rarely take features out?

Because taking features out is exponentially harder than adding features in. 

3. Why is taking a feature out so hard?

Because it’s hard to justify taking a feature out. Usually, nobody is asking us to take things out. With ideas, there are some people pushing for those particular features. They’re advocating, they’re lobbying, they’re sending you cupcakes and cookies.

But, I’ll bet you a dollar that nobody is sending you baked goods to entice you to prune a particular feature. Chances are, if you are fighting to kill a feature whose time has come, you are fighting that noble fight as a lone hero, and like many lone heros, you are unlikely to get fame, glory or cupcakes for your valiant effort. In fact, there’s a decent chance that you will be battling some folks inside the company (like your sales team) that don’t want you to remove things for fear of impact on likelihood of closing deals.

4. Why is it hard to justify taking a feature out?

Because it’s hard to tell whether removing a feature is worth it. 

Some user(s) somewhere probably uses that feature. Some may even love that feature. Some may have bought the product because of that feature. Some may threaten to cancel if you don’t keep that feature.

And that is why product management is so hard. You’re trying to balance different needs for different constituents across different time horizons. Some things make absolute sense in the long-term, but are hard to explain in the short-term.

5. Why is it hard to tell whether removing a feature is worth it?

Because the payback for removing a feature happens over time but the pain from removing it happens right now. 

Also, it’s unlikely that the feature is bad. The idea underlying that feature was on the backlog for a while. It was chosen from a long list of other possible ideas. If a feature got added, it was added for a reason, and is doing some good for somebody, somewhere. 

In order to be implemented, ideas must survive the brutal battle for resources. Hundreds enter, few survive.

And also…

Because we think that the resources spent adding that feature are a sunk cost. And we learned somewhere along the way that sunk costs are sunk and we shouldn’t let them cloud our thinking.

So, now that we have a theory of what’s going on, how do we address the issue?

A few thoughts on this:

As product leaders, we have a limited set of data that we work with. We do our best to pick the ideas with the greatest “wow to work ratio” (the most amount of customer impact and delight for the least amount of calories spent). We make our choices with the data we have and the resources we have at that time. But our choices are not always right — nor should they be expected to be.

So, the first thing to do is accept that…

We are all fallible and some of the features we add will turn out to be flops.

And, since we can’t always know for sure a priori which features will be flops, how do we figure it out a posteriori? (Don’t be impressed with my Latin — I had to look it up).

Answer: Use the data! We live in an age where most of us have tons of data on what our users are actually doing with the products we build. We should instrument the features we add (particularly new ones) and analyze what the actual usage is.

Let me give you an example. You know about Settings. We all know about Settings.

A setting gets added to a product when a debate was had as to whether it should work this way or that way, then everybody got tired of arguing, and just made it a setting. Let the user decide.

I’m going to resist going on a rant as to why most settings are uninspired compromises. But let’s say you add a new setting to your product that lets the user configure [x]. The setting will likely have a “default” and then some possible set of overrides for the default.

Here’s the thing you should measure: On a cohort basis (after the setting is added), how many users ever change the setting from the default to something else? Let’s be generous and say it’s 10%. It’s not 10%, but let’s say that it is. Like I said, we’re being generous. That means for every one user that thought they needed to override that setting in the hopes of getting some value, we complicated life just a little for 9 other users. Not to mention all the people on your team that will have to document, support and troubleshoot that setting. 

In the long-term, was it worth it? Chances are, probably not.

But, we leave it alone because we think “hey, sunk cost…we’re moving on with our lives…”

But that’s a big, BIG fallacy.

Most of the cost for a feature is not in the initial development but in the long-tail of time after it is launched. 

Here’s what I think you should do.

Decide a “minimum bar of usage/value” that every feature must pass in order for it to remain a feature. If a new feature doesn’t hit that bar in some set period of time, prune it. 

Support those efforts to prune where pruning makes sense. Acknowledge that there will be some short-term pain, but that the long-term value is worth it.

Create a culture that rewards the heroic efforts of those that fight as hard to take features out as they do to add features in. 

CELEBRATE THE SUCCESSES!

Thanks to the HubSpot product team for a) being awesome b) helping make this article better.