How to launch software changes without pissing people off

Software designers and developers are all about NEW. We like to experiment with far-out ideas and make shiny things. Our livelihood depends on it.

We’re so addicted to NEW that sometimes it clouds our judgment. We love NEW and everyone else should too, so we force heavy-handed product changes onto our customers without much explanation.

And if they didn’t want that? Or if they got needlessly interrupted by it?…Shhh…we’re not so interested in those problems.

Dislike Facebook’s redesign? Deal with it! Confused by the newest Windows updates? Oh well! Missing some features in the new Final Cut? Too bad, they’re gone forever!

It’s no surprise that these sorts of changes are comically unpopular:

Developers get away with this anyway because we wield all the power. We can push a button and instantly transform an experience for millions of people in one shot.

Imagine if that kind of thing happened in the real world. Let’s say this was your living room:

And one day it suddenly became like this:

You wouldn’t be cool with that at all. You’d be totally freaked out!

What!? Where are all my books? What is all this creepy stuff? Whose head is that? Are those antlers?

That’s exactly what we do to our customers all the time. No wonder they’re always ranting on Twitter.

Why do we make disruptive changes?

There are a few reasons developers decide to steamroll NEW stuff.

• It’s hard for us to keep legacy tech around. It’s easier to put everyone on the newest iteration and maintain only that.
• It’s hard for us to make transitions elegant. A redesigned screen or feature might be jarring, but it takes extra care to ease people into the change.
• It’s hard for us to balance business interests and our users’ needs. Sometimes we need to make a big move to stay relevant in the market or help the bottom line, so we drop a bombshell update on the world — continuity be damned.

Notice a theme there? It’s hard for us. Our laziness or time constraints take over, so we pass the buck.

How we can do better

Not all changes are massively disruptive, so we just need a strategy for identifying the ones that are, and then handle them properly.

Here’s how we do it at Basecamp.

Make only additive updates and improvements.

Taking away a feature is a surefire way to upset your customers. Even if it’s something small or innocuous, you can guarantee someone depended heavily on that one thing you took away.

The solution? Don’t take things away (if you can possibly avoid it.)

Thoughtfully adding stuff is great. Who wouldn’t want more for their money?

It’s also fine to improve rough spots. Make the same features look better, work better, or get the job done faster. Nobody’s going to be bothered by that.

The don’t-remove-stuff philosophy has a strategic upside, too. If you can’t take anything away, you’ll be more conscientious about what you put in.

Take extra care when making a disruptive change.

Sometimes you have a big idea that makes your product better, but switching over will be bumpy for your existing users. In that case it’s worth the additional effort to smooth things out, even if it means extending your development budget to build transition-related features.

We did this last year when we launched some big changes in Basecamp 3. We spent a few extra weeks making a settings screen for the new features we were introducing, so we wouldn’t be shoving them down our customers’ throats. The new stuff was turned off by default, so people could opt in if they wanted to, rather than having to opt out of something they didn’t want.

Whatever extra time you spend doing this is a drop in the bucket compared to the exponentially greater time your customers might have wasted out of confusion or frustration.

Don’t bother pre-announcing changes.

You might think it’d be helpful to warn everyone before a big launch, like…

In three weeks, this website will be totally unrecognizable. You’ll have to figure everything out from scratch, but we think the new one is nicer. Enjoy!

…but what good does that do? Maybe the advance notice dulls the shock, but the customer can’t act on this information. They have to wait to be interrupted again later by the actual change.

This only prolongs the anxiety, with very little upside. It’s better to focus energy on the transition instead—make it so smooth that there’s no need for a pre-announcement.

Explain what’s different.

It’s bad enough to be forced into an update you didn’t agree to, but it’s even worse if you have no idea what happened or why things changed.

Make sure you have a way to introduce and explain what’s new when you launch, either via in-app announcements, a mailing list, a blog, or whatever method you have to communicate with customers.

People may not like the changes, but at least they won’t be blindsided. It’s the courteous thing to do.

Split distinct major versions and keep them around forever.

When we’ve collected enough new ideas to constitute a major rethink of Basecamp (this usually takes years), we create a whole new version from scratch. The previous versions live on in perpetuity in maintenance mode.

That means even there’s no disruption for people who are happily using a previous version. We incur the maintenance time and costs to keep it all running, and they keep paying us like they always did.

This might not work for some products, but it’s worked well for ours. Our customers get to keep using the version they like for as long as they want, with no pressure to do anything else. They can migrate to the newer version on their own timeline. Or not.

You’ll be glad you did

Working through these issues might not be the most fun and exciting part of your job, but it makes a big difference in how people perceive your product, your service, and your company as a whole.

A few people will always complain about any change you make. That’s life. But these approaches will help keep your support load lower and your customers happier.

This was originally posted on Signal vs. Noise.