DESCRIPCIÓN DE LAS INNOVACIONES DE PROCESO EN LA EMPRESA

User abuse is when you unnecessarily and (hopefully) unintentionally mistreat your users by releasing

changes to the user community that they don’t appreciate. I know it’s hard to believe that not every one of your users is waiting excitedly for all of your changes, but it’s true. There are several reasons why your users may feel this way:

They may not have received any notice of the changes, so they were caught by surprise—and they weren’t in the mood for a surprise.

They may not have time at the moment to learn the changes and you don’t have a way for them to continue to use the old version until they do.

The new change may not actually work.

The new change may be incompatible with early versions (such as for accessing data). The new change may work but it is perceived as gratuitous.

They may already be fatigued from all of the changes you have recently made.

They may have their own layer of process or behavior built around your previous version, and now that is broken and they have to update it.

So what causes user abuse?

Mainly change. As a general rule, users don’t like change. Sure they want the software to be great, and they clamor for new functionality, but most people aren’t excited about taking the time to learn a new way to do something they can already do.

Of course, that’s a problem, as most of us are in the business of change. We have product teams working relentlessly to add value and deliver new capabilities to our users and customers. Needs change, technologies change, markets change—and our software must change along with them.

The solution to user abuse isn’t to prevent change, it’s to be smart about deploying change.

One of the fun things about working on a 1.0 product is that you get to start fresh with your community of users. It’s true that your user base is still influenced by other products and services that they’ve been exposed to, but overall you don’t have to worry much about things like backwards compatibility or retraining your users. However, for most of us, we’re in the business of creating updates or new versions of existing products or services.

In the past, software companies could much more easily get away with sending out largely incompatible and disruptive updates. While users would gripe, they weren’t as able to influence other potential users around the world, or take their business elsewhere. Today, with the pervasiveness of

the Internet—and the free flow of user product reviews, both good and bad—if you turn out a bad release of your product, and you don’t correct the problems quickly, you’d better brace yourself for some serious community backlash.

For large-scale consumer Internet services, this is an even more serious concern. These sites need to consider community impact in everything they say and do, beginning with software updates. I call the process of deploying updates intelligently and carefully to a large community of users “gentle deployment.”

In the spirit of minimizing the disruption caused by change, there are several techniques that can be useful in deploying changes gently.

First, do everything you can to communicate the changes in advance, through vehicles such as newsletters, onsite education, and tutorials. But remember that many people will have neither the time nor the inclination to read what you write, so this technique can only take you so far.

Second, if there is any question about the new version of your product working properly—either due to reliability issues, or scale, or performance—then you need to redouble your QA efforts to ensure that you won’t have to rollback your updates, which compounds community angst significantly.

Third, if the change is significant, it may be important to contain the risk by pursuing some form of gentle deployment such as parallel, or incremental deployment.

You can do this by deploying a parallel version of your product and inviting people to opt-in and try out the new version when they have the time. Allow those who try to use the new version to make it their default if they like it. Once you are confident that the new version is working well—and the majority of your community has converted to using it—you can make it the default and allow customers to “opt-out” and continue to use the old version for a period of time if they don’t have the time to learn the changes immediately. Give these people sufficient notice of when support for the old version will be discontinued. For a significant client or service with a large community, expect this process to take months. Also expect some heat from your engineering and site operations organizations because it is not easy to support parallel versions.

Another gentle deployment approach is to deploy regionally—first trying out the new version in a limited area of the country or world, and then expanding. Or you can deploy the changes incrementally —introducing the changes in bite-size pieces over time.

However you choose to go about it, the key is to be as sensitive as possible to the disruption that your changes will cause. Give people the opportunity to learn the differences when they have the time, and try to minimize the impact of any problems or issues your changes may cause.

If your users like your product or service, you’ve got a reserve of goodwill to draw upon. But save it for when you really need it—don’t waste that goodwill through user abuse.

Chapter 25: