Nobody Cares About Your Software Updates

A plea to developers to improve the experience of releasing new software updates.

Look, I get it. You practice agile development, iterate weekly, run tests automatically, and deploy continuously. You pride yourself on shipping changes quickly and how could that be a bad thing, right? You ship new features whenever they’re ready. The bugs you find today are squashed tomorrow. You and your software team are an optimized, streamlined, value-creating machine.

But guess what? Nobody cares.

You and your team are the only ones celebrating new releases. For your customers, new releases are just a nuisance and an interruption. Updates actually interfere with whatever it is that they’re trying to do. Minor bug fixes are a nag. And major versions, while beneficial in the long run, are initially disruptive.

Non-technical people don’t even understand why software would even need to be updated—just as you don’t think about how the asphalt you walk on daily needs to be maintained. Your customers are thinking, “I found this app to do x; it does x; so why would anything ever need to change?”

Here’s a quick sanity check. How frequently do your customers use your product? And how frequently do you release updates? If you’re shipping updates more frequently than someone uses your product, there’s a good chance that you’ve pissed them off. For example, I use Adobe Photoshop CC about once every 2–3 weeks and Adobe pushes updates 1–2 times per week. It’s pretty frustrating to boot up my machine after taking a few days off only to be punched in the face with a litany of updates.

But let’s be realistic. You have to fix bugs and you have to ship new features. And while I don’t claim to have all the answers, I think it’s worth being mindful of a few things…

Release fewer updates. Seriously, just being mindful of the changes you’re shipping can make all the difference. If something isn’t working the way it’s intended to, of course, fix it. But avoid frivolous changes. Don’t change colors, icons, or design patterns unless you absolutely have to. Those areas can always be improved. So unless your customer thinks like you do just leave them be. That ugly green icon in the lower left that you and your team have come to despise is what your customers have become accustomed to and there’s value in that. In other words, don’t fix what ain’t broke.

Do updates automatically. On the web, this happens by default. Even the iOS App Store now automatically updates your apps to the latest and greatest versions. That could still be jarring if the whole product gets a face lift but for all those small bug fixes and incremental improvements it’s great! Remember, nobody cares that you were up all night finding and squashing a bug (aka doing your job). Take pride in being the unsung hero.

Never interrupt your customers. Figure out a way to get your latest and greatest build into their hands without ever stopping their workflow. Where possible, provide both versions simultaneously and allow customers to opt-in or out of whichever version they like. Of course supporting two versions concurrently is expensive so you’ll have to weigh the cost and benefit.

Create a smooth upgrade path. It’s hard enough to build software that accounts for all the edges cases that exist just in the “happy path.” But you should consider all the in-between states too. Hopefully this level of obsession with every aspect of your customer’s experience inspires you to downsize your ambitions. Fight within your weight class—minimize your overall product footprint to reduce the number of special cases.

Sell the value to your customers. Communicate in advance of big releases and outline major improvements. Get out of your own head and focus on how it makes their life better, not yours. It’s very hard to turn a feature-story into a succinct message that your customers appreciate. I actually find it very helpful to start here. Forcing yourself to communicate the value of a feature can sometimes make you realize there actually isn’t any. It helps to figure that out before doing any work. Find a voice that you, your team, and your customers enjoy — keep it light, succinct, and heartfelt. Slack does an amazing job and their release notes are always an inspiration for me.

Internalize the fact that software updates are a nuisance for your customers. Minimize the downside by releasing mindfully, considering all the implications of a release, communicating well, and never interrupting your customer’s workflow.

For me building software is just a means to an end. So my perspective is always of that of the end-user, regardless of how agonizing it may be to achieve from a process, engineering, or design perspective. So take this article with a few grains of salt. At the end of the day, we have to move forward and it may simply not be worth the effort to accommodate everyone all the time. But I think it’s worth trying. If you have any criticism, email me. I’m all ears.