Why People Are Reluctant to Upgrade
This article might be of interest to anyone in software product development. It’s about upgrades, the major ones, in particular. How existing users/customers feel about upgrades? Are they enthusiastic, or hesitant? How likely are they to skip on an upgrade altogether?
The behavioral dynamics that influences the “to upgrade or not to upgrade” decisions is diverse, and taking a deeper look at this dynamics is crucial if you want your old users to stay. Note that I’m not talking about prospective users. Ironically, it’s easier to on-board them. They haven’t been through the process of adapting to the older version of your app/product, and in that sense they’re like a clean slate. The newcomers evaluate your latest upgrade with no anchoring to how your product looked in the past.
As always, devil is in the details. Namely, in the attitudes that software makers attribute to their users/customers. At times — and this observation is based on the “soapiness” factor described in my Why People Don’t Understand How to Use Your Software article — software makers believe that if they come up with a new slick design, or with a couple killer features, or with a really cool and ground-breaking new product concept, 99% of the old customers upgrade instantly. I wouldn’t say that. How do you make sure that the customers need this upgrade? The rhetoric of “now you can do your stuff in this slick design and with all those new features” might not get the point across to them. So, I want to explore people’s thinking and see what can be done to win over the old customers, making them love the new version of your software product truly-madly-deeply.
Natural Inertia: It’s Fine the Way It Is, and I Don’t Need Anything Else
Do you act on every upgrade alert that you get from your smartphone? I don’t. I’m mostly fine with what the phone does, and I want to keep its “functional homeostasis”, so to say, as unretarded as possible. With all those years that I’ve spent somewhere near software development, I’m very cautious about upgrades. They might spell some unexpected breakdowns or weird new interfaces. So, as far as it goes about my smartphone, I wouldn’t do an upgrade unless there’s some really compelling reason. This is a typical behavior of a conservative user, and something makes me think there are legions of them.
Compelling Reasons to Upgrade: Finally.. ! Here’s This New Feature!
This scenario is a piece of cake. It’s about the customers who want you to release this or that new feature. The feature is very important to them, because it is supposed to let them do their work — or whatever it is that they do with your product or app — easier and better. They might be looking sideways at other products unless you give them what they want. If these customers are happy with new releases, they keep staying with you.
Upgrade to Whatever
Some users have the unshakable faith in the power of upgrades. They’d upgrade instantly whenever notified of a new release, regardless of whether they need the upgrade or not, and it looks like such a behavior would be an easy-to-handle case for software makers. However, instant upgrades may come with some issues, e.g. if users discover that the upgraded version misses some previously available functionality.
For all of the above scenarios, you — as a software maker — will still want to make sure that people can transit easily from the older to the newer version. I wrote about that previously in my Help People Understand How to Use Your Software article.
Software Makers + Users = Learn From Each Other
Usually, software makers allow some time for users to learn more about an upgrade until they no longer support the old version. However, many users rarely take this time to learn what the new version will allow them to do, or which functionality will be gone. Here’s what they might be thinking to themselves: “It all looks totally new. I can’t figure out where my stuff is. No matter which great things they promise, I’d better stick with the old version that I know how to use as long as I can.” In their turn, software makers tend to focus their efforts on new customers, as they believe that the old customers would move along somehow.
Eventually, it all depends on how well the software makers know what their current customers need. Of course, this involves following up with the customers, finding out how they work with the old version, checking if the new version will help them do their work better, and educating them. Again, this is about the dichotomy of “how painful the current pain is” vs. “I’d better follow my natural inertia and stick around with the old version as long as I can”. As for the customers, they might want to make a step towards software makers, too, and check how exactly this new version helps them do things better.
This mutual learning approach, as far as I can see, stands a better chance of facilitating a smoother — and a non-reluctant :) — upgrade experience for users.
Related:
This story is based on an earlier article.
