How NOT to roll-out a major upgrade

Good Intentions

There is a moment in life of every company that has been developing software for any decent period of time. It′s a special moment. The Big Release moment. The moment you whole team has been working their asses off for the last 18 months. This release brings magical changes to your product. The changes that will turn any prospect into an evangelist, compared to which Guy Kawasaki would be a sad sceptic.

This moment happened to us this March with the release of Version 9, exactly nine years after the 1st version of Easy Projects has been shipped.
We′ve been working on this version for over a year and it had a lot big changes to both back-end architecture and UI. The interface changes were the major break-through for us. Our goal was to make the process of adding projects and tasks into the system as easy and intuitive as humanly possible.

We spent over 3 months just on prototypes before any actual coding has even started. The concept passed a series of usability tests with focus groups with flying colors.

Keep in mind, that we were not adding any new features, just changing the existing ones. We replaced 3 pages with a single one that was simpler and quicker to use, which we called Activity Center.

Every time we had to go back and review our old pages, we couldn′t understand how anyone can use them. Feedback from our beta-testing group was in line too. Everyone liked the new UI. So naturally, when it came to deciding how to roll-out the upgrade, we had no doubt about the right way: we′ll retire the old pages at once and replace them with the brand-new shiny Activity Center.

Of course, we′re reasonable people who care about our existing clients. Of course, we don′t want to just surprise them with the change. So we put together a number of educational video tutorials explaining all aspects of the new Activity Center page. A month before the roll-out we sent an email notice to all of our clients informing them about the upcoming upgrade. Another email was sent a week prior to the release.

Big Bang

On the day X we pulled the trigger. First batch of the accounts was upgraded to version 9. The first 30 minutes were pretty good – no problems or errors in the server logs, all systems are up and running.

And then the floodgates got opened. Emails and phone calls from our clients started pouring in.

“What the hell has just happened with my product?”, “Where is my Projects page?”, “I can′t do my work, please fix it. Now!”, “Just turn it off, I want my old Easy Projects back”. That′s pretty much the gist of what our support team has been subjected to for the next few hours.

You′d be surprised, but apparently people don′t read emails. Well, maybe some product administrators do read them, but they certainly don′t forward it to the rest of their team.
Humor aside, we had to do something and do it quickly. Luckily our dev team thanks to a spark of genius or most likely common sense, had built-in a compatibility mode that would allow showing the old pages along with the new one.

In the next several hours we frantically compiled a new build targeting existing clients with the compatibility mode turned on by default. The next day we added a message prompting them to try the new page.

Lessons Learned

Although the new version became a great success with the new clients, we definitely lost a lot of good faith with our existing user base, rightfully so due to our poorly conceived roll-out strategy. We allowed ourselves to get blindsided by the benefits of the new version without putting enough thinking into basic human psychology. We haven′t thought about how disruptive these changes can be to the unsuspecting clients who didn′t have time or opportunity to read our upgrade notices. We screwed up and created troubles for our clients, which is unacceptable.
So what lessons did we learn from this experience? Well, here are a few.

• No focus group testing can survive meeting the real users. Over the course of the next few months we discovered several scenarios we haven′t thought about, so having the old pages available was a must for certain clients.
• People are busy. They have other priorities. They have work to do. Don′t ever, ever disrupt their workflow. Let them be in control so they can choose the right time for the switch.
• Video tutorials are a great way to educate users about new features; however they only work when people are aware of them. Consider in-product announcement in addition to the email blasts for better effect.

Of course these lessons might not apply if you′re building a game or a social network, but we will definitely put them in action when releasing our next portion of revolutionary UI changes or new features.

Agree or disagree? Have a similar story to share? Can offer the client perspective on this? Please comment away!