Creating Passionate Users

Why they don't upgrade (and what to do about it)

Why is it that--after we bust our ass to produce a shiny new version of our product--users are so slow to upgrade? WE know it's better. WE know it'll help them kick ass in new ways. WE know that if they stick with their current version, they'll never truly become passionate...because they'll never touch that high level of expertise where things get really really interesting. But there our users sit, apparently content to hang out in the "competent" zone, happy they no longer suck, but unmotivated to push forward.

That's a problem.

And I'm not talking about the financial side. Even if we make no money off our upgrades, we still want our users learning and growing and improving and reaching for new challenges and doing more complex, cool things. (Assuming you ultimately want passionate users, which if you're reading this blog...)

So why are users dragging their feet? Why aren't they desperate to get the latest and greatest spanky new release? Conventional wisdom says it's because of the expense, or that users fear change, or that users are simply too lazy. But there's a simpler explanation:

People don't upgrade because they don't want to move back into the "Suck Zone."

They worked too damn hard to reach a level of competence and the thought of sinking back down--however briefly--into that awful state they clawed their way out of--is too unpleasant. We've trained users to fear upgrades. Raise your hand if you've ever installed an upgrade only to find yourself back in that confused I-have-no-frickin'-clue-where-they-put-that-dialog-box state? Raise your hand if you felt the upgrade just wasn't worth it, even though you knew that the way you did things in the current version was pretty much an inefficient hack. Raise your hand if you felt intimidated and maybe even a bit humiliated that after upgrading you could no longer do some of the simplest things.

It's not usually the upgrade that sucks. It's that the upgrade makes the users suck. Or at least makes them feel that it's their fault for not instantly getting it.

Bottom line: nobody likes doing things they suck at. If there's a way to avoid it, we will.

Back in the late 90's, I attended a Macromedia conference, and one of the sessions was a panel of web pioneers discussing what were then the earliest days of web development, especially the whole browser incompatability problem (that we of course thought would be LONG gone by now... lol). The panel host asked one simple question of each of the panelists, "So, which browser do you have on your machine right now?" The response was shocking. Almost every panelist--and keep in mind that these were hard-core web developers/entrepreneurs--gave the same response, "Whatever was installed on my machine at the time I got it." One of those panelists was none other than Jerry Yang, co-founder of Yahoo! We were stunned. If even Jerry Yang doesn't bother with upgrades...
(Many of us later confessed that we would have answered the same way.)

How to inspire users to upgrade

Don't give in to featuritis

Make the upgrade worth it.

More importantly...

Make sure the users KNOW it's worth it.
Provide a compelling benefit, and do your best job of painting that compelling picture for the users.

Go over the top with documentation
Geez... I hate it when I get an upgrade and it comes with a whopping 1-page ReadMe. Make sure users know you're going to hold their hand and walk them through the new things in the friendliest, most accessible, most encouraging way.

Try not to break things that were previously important to them
Yeah, another "duh" thing, but so often ignored. Users should feel like the new upgrade simply adds capability, performance, etc. without sending them back to the "suck zone." In other words, they should feel like the upgrade is an extension not a radical modification. This isn't always possible for forward progress, of course, and you don't want to be locked in to your former design mistakes, etc. but at least think about ways to help a user transition gracefully from one version to another.

Don't tell me what cool things YOU did to the new version, tell me what cool things I can do with the new version.
Never, ever forget that it's all about me. For most products, and most users, they don't give a duck about your new specs. They care about what it means to them. Connect the dots for them in the most vivid, compelling, motivating way.

The pain of an upgrade begins with download and installation
Even if the new version itself is natural and easy to get used to, if the install and set-up is a pain in the ass, they'll remember that the next time (and tell their friends not to bother unless it's REALLY REALLY worth it).

Don't make me pay for YOUR bug fixes
The more users perceive your upgrade as simply correcting things you should have had working in the first place (bugs, performance problems, etc.), the more likely they are to start taking hostages if you expect them to pay for the privilege of having what they thought they were paying for with the previous rev. It's OK to make a performance/bug-fix release, but don't charge for it unless you've done something earth-shattering to the technology which gives you a huge increase in performance (as opposed to correcting poor performance).

Seed the community early
Get beta versions to your key community of users so that they can start evangelizing why the new version is worth it. (Of course, this assumes that the new version IS worth it.)

Set the tone for future upgrades
If you lie about the upgrade--either by downplaying the learning curve or overselling the benefits, you're screwed.

Users will remember the pain of THIS upgrade when it comes time for the NEXT one.
The better the first upgrade experience is for them, the more likely they'll be to ever do it again.

Try making more frequent, smaller/incremental upgrades
While this does't work for most non-software products, continuously "refreshing" and modifying the product in tiny ways adds up to big changes down the road without those huge jump-off-the-cliff slides back to the "suck zone". The ultra-fast release cycles of many of the Web 2.0 companies is an example (and of course ANY web app has a potential advantage here since the user doesn't need to choose to upgrade).

Entice, bribe, or potentially force them to upgrade
This is extremely dangerous, but if you are absolutely certain that your upgrade will be universally loved by users--and that the upgrade will be relatively bloodless--you could potentially hold them hostage, like the way Apple did recently with the new iTunes. If you want to download the new shows at the new hi-resolution, you have no choice but to upgrade/install the new version of iTunes. Again, very few of us will ever have Apple loyalty, but there are scenarios where you might just have to say, "Sorry, but there is no way we can--in good conscience--let you continue without this upgrade." This approach will likely backfire spectacularly if the upgrade is not free.

Start the buzz early (practice T-Shirt-First Development)
By the time Apple releases a new version of Mac OSX, the Faithful are so excited that they line up by the thousands outside Apple stores at midnight, braving the cold, just to get the new OS a full 24 hours ahead of their friends. How do I know? I've done it, twice. Once when it was snowing.

New releases can be a source of great enthusiasm and energy. Exploit that.
In the right situations, upgrades are like crack. (In a good way)

Remember, reducing guilt is the killer app. Nobody wants to go back to the "suck zone", so it's your job to make sure that:

A) The new upgrade must not send them back to the Suck Zone
and
B) You must convince users that they won't land back in the Suck Zone

In the ideal world, the curve looks like this: