Rapid Response

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.