Product Release

I have been building and releasing commercial software for or 30 years now.  I have seen some really good releases and some really bad releases.  

By release, I am not talking about clicking the check-in button and having to push to production.  I am talking about releasing a brand new product or a major release of an existing one.  These types of releases require a cross-functional team that is empowered to execute the tasks that are needed to make the publishing a new product or a major release a success.

The first 20 years of releasing products were more of an art than science.  Luckily in the last 10 years launching products has developed into a logical process with built-in checks and balances.

In the early years, I can remember sitting in a room the day of the release and being asked    

"How do you feel about the release?"
"How many teams can we have work non-stop to get this done on time?" 

And my all-time favorite

           "How did we get so far behind?"

By the way, the answer to the last question is "one day at a time"

How do you turn your release into a successful release?

First, you have to define what is meant by a "successful" release?

This is an excellent question.  The answer is the normal "depends".   The business doing the releasee needs to be able to answer that question.

The are several common processes I like to follow.  I have listed here:

• Define your success criteria
• Build a Quality product
• Have a reasonable Marketing plan
• Train your Sales staff
• Train your support staff
• Have a launch / Triage Plan

Define Success Creteria

Not only do you need to know why you are releasing the product, whether it is to help customers, make more money, provide better UX, all of which are equal and valid release reasons.  You must ensure that the entire team is not only aware of the criteria but are excited about it as well.  Everyone involved must be excited.  The whole company and even your customers will pick up on your excitement and they will feed on it.  This will help in the long run, excited customers have a higher tolerance for issues and hiccups.

If you can not get excited about the release or understand why you are releasing something, maybe you should not be releasing it.

Quality Product

This one trait might seem like a "no brainer", but you would be surprised how many teams overlook this step or simply take it for granted.

By quality I am referring to a couple of different aspects of the product:

• The features that are being released, work and work well
• The feature being release are the features that the customers want

Features work well

Each feature needs to have testing built-in.  Developers and customers are not your QA system.  I am talking about more than unit tests.  You must have fully automated test suites:

1. Unit test
2. Integration test
3. Build "Smoke" test
4. Acceptance test
5. Regression test

If you notice, "guerrilla testing" was not on the list.  When you stick a 100 people in a room a week before the release and test it, this does not accomplish anything but make a 100 people not very excited about the release or even worst, they see all the issues reported and then think the product is bad.

Features Are What Customers Want

The logical path for the release is simple:

• The feature works well -> release it
• The feature does not work well -> turn the feature off. 
• Can not ship with the out this feature, or delay the release. 

• The feature works well -> but the customer does not want the feature.   The first priority would be to turn it off.  And build the right one.  Your customer may get very upset if you send out a release with new bells and whistles when they have been asking for different features.
• If the release date can not be moved to include the new feature, leave the feature out and put a marketing spin on why it is not there.

By this time I am sure many of you reading this are thinking this only happens in a utopian world.  I can tell you from experience, this is not only possible but rather easy to do.  It is a top-down approach, having support from the company leadership, but it also takes trust between the leadership and the teams.  These processes save money and time so why would not the leadership want to save money and build trust within the company.

 

 Marketing Plan

With a new product or a major release, you want to be mindful of your marketing requirements and how fast and how much traffic you want to drive to the new release.  At the same time, you need to generate excitement about the new release.

You need to make sure the user's first impressions of the new application is very positive. With that, you have to ensure if you plan on generating more than expected traffic, that the system is prepared to scale.  

On new applications, I like to do a slow rollout to new customers first.  New customers have a lower expectation of new features or applications.  New users will also allow you to validate new UX and other usability items. As opposed to an exciting customer that has set UI path established and workarounds for items you might have resolved.

Current customers have the "who moved my cheese" syndrome.  They expect things to be where they were and to work like they used to even when you provide much better solutions. 

Sales Training

The next important step to make sure is that the sales team is trained and is ready to sell the new product.  The Sales team needs to be trained on the new feature sets, the benefits of each feature, and how the new features solve customer problems.  There is a timing part of sales training.  You don't want to show off the new features to soon because Sales could stop selling the old product and try to pre-selling the new stuff.  Or even worst they may show or promise features that may not make it into the final release.  When that happens most times it backfires and causes a negative customer experience.  

The key output from the training is to get the Sales team excited and prepare them with the information that they will need to help within the sales cycle.

Support Team

While the support team training is similar to sales training, it has a different objective.  With the support team, you want to emphasize the features and how to troubleshoot different issue types that come up.

Just like the sales team, you want to have the support team to be excited about the release.  With any release, there will be customer issues and you have to have your front line trained and excited.  

For major releases and new product releases, I have given written tests and have had QA call the support center as a customer to validate they are ready to provide the support the new product will need.  

Once a new product release launch, the development team was scheduled to "pair support" with the support team for the first 2 weeks.  The results provided valuable insight into not only the issues, but the system, monitoring, customers' pain, and how the product was being received, both internal and external.  Best part it shows the company that we all are in the release together.

Launch and Triage Plan

The launch plan contains the objective, teams involved with their responsibility, milestones, Stakeholders, and the release schedule.  Stakeholders and all the team members need access to this plan and to be able to see the status of the release at any time.

Not only does the launch plan contain pre-launch and launch plans, but it also needs a post-launch plan as well.  This includes a triage plan.  This will allow you to manage risk to the release.  The team will need to review the result of the testing results and test coverage and forecast each level and number of issues within the first 7, 30, and 60 days.  This will allow each team to prepare to able to provide support after the release.

You need to have a worst-case plan.  You hope for the best but you need to plan for the worst.  For each what if case each team can think of there needs to be a plan on how to mitigate the issue and risk.  It should also include any possible customer communication that may need to be provided.  It is better to be over-prepared and have a nice quiet launch then disappoint customers, burn out employees, and lose money.  

Summary

Like any good plan, it needs to be thoughtful, flexible, updateable, and executable.  Releasing a product is not something you simply do when your done coding.  It needs to be a thought out process with checks and balances.

Hopefully, I have provided you with some insights to make your next product launch more successful, no matter how you measure it.