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 because 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 pervasive internet, if you turn out a bad release of your product (and you don’t correct the problems quickly – see the last newsletter on Rapid Response), 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 changing intelligently and carefully to a large community of users “gentle deployment.”

When I look at PRD’s and designs for new versions of software, it’s always surprising to me how many of the changes are either unnecessarily incompatible at best, or gratuitous at worst. Even if the user base is screaming for a new feature, it doesn’t mean they are looking forward to learning about the actual changes. In general, it is safe to assume that users do not like change, and anything you can do to minimize the impact of the changes on them will be greatly appreciated. So take a fresh look at the changes you’re planning to deploy, and ask yourself if there’s anything you can do to minimize the disruption your updates will make.

It’s also critical to realize that not every user operates on the same time table. Even assuming your community is looking forward to a change, they may not all be able to take the time out to learn the new version at the same time. For many products, especially Web-based services, you will need to provide a window of time where people can access both the new and the old versions.
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 like newsletters, onsite education, and tutorials. But remember that many people will not have the time or 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 there to try to ensure that you won’t have to rollback your updates, which compounds the community angst significantly.

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

You can do this by deploying a parallel version of your product, and inviting people to “opt-in” and try the new version out when they have the time. Allow those that try to 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 about when support for the old version will be discontinued. For a significant client or service with a large community, expect this process to take on the order of 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 – try the new version out in a limited area of the country or world, and then expand. Or you can deploy the changes incrementally – introduce 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.

Email to a friend

Sign up for the free newsletter here.

I’ve talked elsewhere about the pitfalls of confusing product launch with success, and how important it is to not lose focus after you ship your product or service. In this article I wanted to say a little more about what you should be doing during this critical phase of your project.

In too many organizations the resources that have been marshaled to build and launch the product very quickly evaporate after launch in order to jump on the next project coming along. This is especially unfortunate because this is the moment when your opportunity for learning and correcting is greatest. I consider this a project management and product development process failing that can be corrected simply by slightly extending the project to incorporate this critical phase. No phase of the process will provide a better ROI than this one, so this change is not a difficult pitch to management.

I strongly advocate that all project teams schedule a phase that begins at launch and lasts at least two weeks, and possibly more. I call this phase “Rapid Response” to emphasize that it is all about responding quickly to what you learn once the product has been launched.

Note that while this approach was borne out of consumer internet services where this is particularly critical and well-suited, I believe it is important for platform, infrastructure and enterprise products as well.

Even if you’ve done all of the early prototypes and validation testing prior to engineering that I advocate, and you have a great QA team so the product is reliable, you still need to expect that there will be issues that can only be discovered once you’re live. The typical approach of waiting to see what the response is and if any issues exist, and then trying to schedule follow-on point releases following the same general cycle takes far too long and costs too much.

The question is not whether there will be issues, but rather how quickly you will address them?

The three keys to success are: a) a clear picture of how you are measuring success; b) how quickly you can identify what’s going on; and c) how quickly you can respond.

As to measuring success, you need to have a clear, prioritized set of business metrics. Are you looking at page views? Registered users? Time on site? Conversion rates from visitor to member? Subscriptions? Advertising revenue? The right set of metrics will depend on your product and your business goals, but in any case you need to know what you care about and what you’ll be tracking. Further, you need to know what results you would consider a success and what you would consider a problem.

As to understanding how users are responding to you product, for consumer services it has never been easier to understand how people are using your product or service. It is easy to instrument and track activity. There are many products in this space, but I’ve been particularly impressed by Google’s recent acquisition of Urchin, now called “Google Analytics” (www.google.com/analytics). These services can quickly and easily tell you a great deal about how your users are using your service.

For enterprise software, I like to send members of the product team – product manager, engineers, designers – out to the customer site to be there with them when they install the software and work to get the software live and in use. It is amazing how much faster issues are identified and resolved when a team member understands he’s going to be at the customer site until the customer is live and referenceable.

Once the issues have been identified, the product team needs to meet (no less than daily), prioritize the issues, and discuss the best way to respond. The result might be a “hot fix” that is rushed to the site, or possibly additional content that explains problem areas. If the team is prepared for these changes, and understands how crucial it is to learn and respond quickly, then in a very short amount of time the team can make substantial improvements to the effectiveness of the product or service.

Web site analytics are certainly not the only tool you should use to understand your users and how they feel about your site. Surveys, e-mail discussions, boards, field testing, are other examples. But the data provides such near real-time insights that I look at the web site analytics for all of the sites that I am involved in nearly daily. I’m looking at where people are coming from, what their favorite pages and activities are, how long people are spending on the site, how many pages they are viewing, and how often they return.

Email to a friend

Sign up for the free newsletter here.