If you ask any long-time fan of a popular app or software product that’s been around for a while, they’ll have some gripes about how “it’s changed” and “it used to be better” and exhibit some nostalgic longing for the older, simpler times. It’s pretty much a universal trend.
But there seems to be some truth to this reaction. I’m sure you’ve noticed how certain apps on your phone, over time, have gotten so complicated and have so many features that you never use. Take Facebook, or Yelp, or even iOS itself with all its latest bells and whistles that seem to make it more complicated.
Why do all these products become more and more bloated? What does bloat even mean? And is it bad, or are users just overly sensitive to change? I cover these questions in this week’s post.
Defining product bloat
It’d probably help to start by defining the word bloat as I use it.
When it comes to software development, there are two broadly agreed-upon definitions of bloat. The first is bloat in the app size (or bundle size, installation size, etc.). Essentially, “how much space does it take up on the user’s device?” For websites, app size bloat can be the size of the website that needs to be downloaded from the web server.
App size is usually measured in megabytes (MB) or gigabytes (GB). It’s easy to see why this matters. People’s time is limited, and if something takes too long to load or download, then you’ll lose people before they even see your product. Sometimes, there are even platform restrictions – until recently, Apple used to restrict cellular app downloads to a maximum of 200 MB. Anything greater than that limit would require WiFi to download. App size bloat impacts new user acquisition – if it takes too long, I won’t wait for it to finish loading.
The second kind of bloat is the user experience (UX) bloat. This is harder to measure, and the topic of debate among product, design, and engineering teams everywhere. UX bloat can be experienced as a cluttered interface or lots of information being presented at once. But it comes in many other flavors. The impact here is also more subtle, but quite sinister. If your product’s UX is bloated, newer users can get overwhelmed and not know how to do what they want in your product. And more experienced users can get confused by the unfamiliarity if you continue adding bloat – finally when you try to fix it, those users will stop using your app because now everything is different than what they remember. UX bloat impacts the retention of users – if I can’t easily use your product, I’ll stop using it.
Why does bloat happen?
Hopefully by now you understand what bloat is and how it negatively impacts users. But how do we end up in a situation where almost every successful product slowly becomes more and more bloated? Surely the most talented, intelligent people are working on these apps – are we all just doing something wrong?
Like most things in life, it comes down to tradeoffs and incentives. Bloat happens because product development incentivizes shipping new features and functionality and doesn’t explicitly disincentivize bloat. Let’s consider some examples.
Example 1: A team is faced with a decision of whether to ship a new feature that adds 10 MB to an app’s download size. Optimizing the app size would take an additional month of work. But shipping the feature quickly reflects positively on their performance. They’re more incentivized to ship it without optimizations, so they do. The end result is the app size goes up by 10 MB, increasing the app size bloat. User installation rates drop by 0.1%.
Example 2: A team wants to ship a new feature that they’ve been working really hard on. They want to ensure lots of users use that feature because it’ll reflect positively on their performance. But putting the feature’s button on the homepage could make it feel cluttered, since most users on the homepage probably don’t care about this feature. They’re more incentivized to put the button on the homepage, so they do. The end result is that the app’s homepage gets slightly more cluttered, causing UX bloat. User retention drops by 0.1%.
In both of those situations, product development teams aren’t sufficiently incentivized to minimize bloat. Tragedy of the commons says bloat will inherently go up.
But why is this bad? Notice that there’s a pretty sinister impact of this bloat. In both of those examples, bloat’s downstream impact on the business metrics (installation rates and user retention) is so subtle that it might not be detected, even if they were monitoring that metric. Unless there are millions of data points per day, a 0.1% drop in any metric might require months of data collection, and most teams are moving too quickly to measure every new feature for that long.
Over time, bloat causes death by a thousand cuts to critical business metrics. But any one bloat-increasing change may not be noticed on its own.
What can teams do to avoid bloat?
The reality is that some bloat is inevitable. Most of the time, bloat is a negative externality of shipping features. But now that you’ve seen some of the pitfalls of bloat and how it can sneakily impact the business, let’s discuss some strategies to minimize it.
The best way to combat bloat is to think about it as carbon emissions that require a carbon tax. A bloat tax. Again, it all comes down to incentives. Teams and leaders need to disincentivize bloat enough to allow teams to weigh the tradeoffs of shipping features against the increase in bloat.
Here are some steps you can follow.
First, define ways to measure bloat as objectively as possible. With app size, this is easy – just use the actual size increase. With UX this is more challenging, and you’ll have to get creative. One way to do this is with t-shirt sizes: S/M/L/XL, with the design team voting on how much UX bloat a particular feature adds. Another way is to have a point system with voting. Try out different versions to see what works best for your org.
Second, assign a maximum bloat tolerance that you’re willing to incur for a feature before you start working on it. Align on this with the leadership team and all relevant stakeholders. For example, for a very large, important new feature or initiative, you may be willing to tolerate a large increase in the bloat. If Uber is shipping Uber Pool, they’re willing to incur more size and UX bloat since it’s strategic and has high revenue potential. However, Uber may only assign a small bloat tolerance for scheduled rides, as it’s not core to their business or strategy.
Lastly, and most importantly, encourage teams to stay within bloat guidelines, and help them adjust on a case-by-case basis. It’s important to treat a bloat tax as a guideline rather than a hard-and-fast rule, especially in the beginning. Never stifle creativity at the expense of process. Eventually, teams should feel ownership over their bloat tax similar to how they feel ownership over their deadlines. If the tax is being used as a punishment or to evaluate performance, there are bigger underlying problems around expectations and ownership.
Overall, bloat is a systemic and slowly eroding problem that eats away at business metrics and causes users to become frustrated or eventually churn. But hopefully by bringing attention to bloat and starting to create a bloat tax, you can tip the incentives in such a way that teams actively seek out ways to minimize and mitigate bloat.