You can please some of the people some of the time. But a poorly managed software release pisses everyone off every time. I recently witnessed such a train wreck. The company will remain nameless. Suffice it to say, there is still blood on the tracks.

Versioning your software is absolutely necessary. Versioning your website is equally as necessary. Sure, sure you’re always going to have complainers. I can’t wait to hear what people are saying about the new look of LinkedIn. What the hell is that all about? Versioning a website is one thing. Who cares really. But when you start monkeying with people’s native applications, the tools they rely on to make money every day, that’s when the long knives come out.

People have visceral reactions to their faith in the stability of something being shaken. Don’t get hoisted by your own pétard!

1. First of all, what you know about versioning you already learned in wood shop.  (yes one of my summer jobs was working in a shop that manufactured wooden crates. That was fun until I put a 2″ staple under 80 lbs of pressure in the back of my ankle. Hence my next job inside assembling computers. But where was I?)

Measure twice. Cut once.

Every aspect of a new release needs to be tested within the confines of your beta testers (let’s call them Betas). This includes all email messages, support messages, links to pages and how to’s. Betas need to experience your release like it were a live-fire roll out. “This is a drill.” That’s the only way to get a handle on the multitude of elements impacting whether or not a roll out is going to have a shot at success.

Don’t assume. People need to opt-in to be your beta testers. 

2. Don’t violate your user’s trust by making them unintentional testers. Subscribe key people to become part of the beta testing experience. This marks them, segments them, within your database so that they are the only people that receive your updates and patches prior to those bits going live. The way Betas receive the update will be identical to how the general populace will receive the updates–same messages, same timing, same everything– except Betas will be aware and be OK with the fact that that they are your guinea pigs.

Test the updates but don’t forget about the supporting messages & pages. 

3. Patches and Updates are generally preceded by and followed up with notification emails. So why aren’t these notification emails tested too? They should be. Every message that has anything to do with a release needs to be tested against your Betas. What’s the best language to use in an email that informs that your software is going to stop working the way it used to? What subject line are you going to use to make sure that people actually open your email? You won’t know unless you’re testing messages (constantly) and gathering open and click-through rates.  Emails sent to Betas should have the “BETA PROGRAM” masthead on it, but that will be the only discernible difference between an email going to the Beta, and the email going to your general audience.

Encourage feedback with links to surveys.

4. Provide your Betas with links to online surveys to help qualify and quantify their responses. Encourage feedback with links to surveys. Not controlling what you’re looking for in feedback loops (to a certain extent) makes no sense. Everyone is going to hit your software from a different place. That’s good. Serendipity is vital in testing. But so is getting 100 pairs of eyes focused on the same issue. Ask for structured responses, grading different aspects. Include comment text boxes to capture the organic flybys as well.

For instance when you join the Beta program at GotoMyPC, a company that I recently interacted with and was VERY pleased with the outcome, they send you feedback links like this: https://www.gotomypc.com/betaFeedback.tmpl. This is good. For me on the outside looking in, it seems like an obvious thing to do. They make it clear. If you want to be our guinea pig, opt-in. Take note.

Promote your beta program.  

5. People have to know and WANT to be your beta testers. Otherwise ALL your customers get co-opted into being your beta testers and that’s ugly! Promote your beta program. Let people subscribe. Manage them as you would any other segment of your database (you are segmenting your database right?). If you’re not subscribed, then you don’t get to test the new software that might hose your machine. Or you might be able to get a hold of some great updates that your neighbor won’t have for another 30 days. Either way, you enter the beta program with eyes wide open. You can’t beat in-situ for surfacing the junk, however; a User does not a Tester make!

Create a launch & support roadmap.

6. Create a Patches and Updates release roadmap. This is the recipe book that lines out exactly what messages and activities are going to precede the update and those that will follow it up. This cookbook also includes any supporting webpages, surveys, articles and posts that you’ll be using in support of the release. Get it up on a dry-erase board, build it all out BEFORE you launch that release.

Have a checklist to make sure all systems are a GO!

7. When an update is ready to go live it means it has been fully tested AND met with all of the checks and balances that govern what is deemed to be a proper roll out.  The devil isn’t in the details. The devil is in the assumptions!

Keep your wits about ya… 

No rollout is ever perfect. You’ll never have 100% control, peace and contentment. But adding some basic procedures to the plan does more than cover your ass. It supports your customer’s belief that you’re not going to pull the carpet out from under their feet the next time they aren’t looking.

The ideas here are more than just lists in books. They require technical solutions. Get with your systems people and work it out. Create a campaign that invites people into your beta program. Segment your database so that Betas are easy to message when the time comes.

The biggest mistake you can make is to be unplanned when you make the cut. Measure twice. Cut once. Your customers’ trust is fickle. Don’t screw with it. Prevent the disaster. Don’t be that wreck on the track.

What do you think? I’d love to hear from you about your opinions on how to improve software launches for your customers.

*Photo credit. I found it here: http://cs.wikipedia.org/wiki/Soubor:Train_wreck_at_Montparnasse_1895_2.jpg