Product launches are one of the most highly anticipated events in a company and as the launch date nears the entire organization gets in line to support the launch. Sales and Marketing works to make sure a timely advertising campaign is ready to inform the public of the new product with all it’s great features to create industry buzz driving demand. Engineering teams are working tirelessly to make sure the product with all its key features will be ready and performs flawlessly. Operations and those responsible for support (technicians and agents) are gearing up with training, scripting and escalations making sure they are ready at time of launch. All of this preparation is building excitement or anxiety as the launch date approaches.
If you’ve been around product launches long enough you’ve seen successful product launches and others that weren’t so successful. The difference is subjective and sometimes unexpected. I wanted to take a moment and give some insight into these differences and helpful hints to insure your next product launch is a success.
The following are two real world examples of a product launches.
Product A took five years to develop and introduced a new consumer product line. The marketing engine energized the public and generated the demand. Engineering said they were ready, there were some issues but determined they were not high risks because the issues could not easily be reproduced. Operations had all the technicians and agents trained and ready to support customers if they called. The launch date came, customers ordered the new product, technicians did the installations and guess what…the customers started calling because the product didn’t work all the time. That hard to reproduce issue seemed to not be that hard to reproduce once in the customer’s home. Since there was no way to easily reproduce the issue we had a very difficult time root causing the issue which hurt the brand, customer satisfaction and the engineering and operations teams.
Product B took two years to develop and again revolutionized a consumer product. All the company departments were ready again and demand was high. Prior to this launch the technicians were given extra hands-on training as well as more guidance on how to report details if they met failures with the new technology. The new technology also periodically reported diagnostics data to the cloud giving more insight into real-time operating information. When customers started reporting issues engineering and operations were well equipped to:
· Instruct the technicians what to be on the lookout for, what other information to give for our investigation and suggestions on resolving. The turnaround time was short giving confidence to the technicians and helping engineering with the investigation.
· The periodic diagnostics data provided key insights into systemic type failures but also pointed out when everything was working perfectly fine.
There are significant differences between each of these products but several key differences are worth focusing on:
· Data collection:
Product A did have logs that could be uploaded but the upload needed to occur within 24 hours of the event. These logs were not very useful without a good description of the event which proved very difficult to collect.
Product B was continually uploading diagnostics data twice a day to create a more accurate view of the operating environment and user experience. Technician reports added field relevant details to help correlate the collected data.
· KPI Definition – Key Performance Indicators (KPI’s) are predefined sets of data used to find high value information associated with environment, user, security, use and performance. These KPIs are usually identified during a more formal risk assessment to identify potential risks. Risks are then ranked based on probability of occurrence and impact if they occur.
Product A used the logfile to support development and test activities. No KPIs had been defined for that product.
Product B had KPIs defined and reported issues were much more quickly found and resolved.
· Organizational Preparedness
Product A used a traditional launch strategy where some people in engineering used the product before the formal launch and reported any issues they may have experienced. Training programs used standard training slides, limited to no hands on experience for technicians and agents and somewhat generic scripting and troubleshooting guidance.
Product B used a much more engaging preproduction strategy incorporating a tightly controlled beta program consisting of employees across the company. The participants signed a participation agreement that they would use and report at scheduled intervals during the beta period. They had weekly assignments and simple reports to give for feedback. If they did experience issues a formal reporting process collected all issues for a more formal review and resolution. This created an engaged organization and allowed technicians and agents to use the technology before the formal launch. In addition, training included more hands on content allowing technicians and agents the ability to use the product first-hand before having to support a customer call.
As you can probably tell Product B had a very successful product launch and did not negatively impact net promoter scores. Product A had significant issues but the real challenge was the inability to quickly isolate cause or understand how the issues were occurring. The three areas identified to focus on I believe are achievable for all product launches: data collection, KPI definition and organizational preparedness. I can go on for days about the value of each of these areas so contact me if you would like more details.
There have been many successful product launches across many different industries. This example gives some suggestions to consider if you are looking to improve launch of your products. I hope this has been helpful.
A brief note about risk analysis. Risk Analysis is an often overlooked activity that has the ability to identify the real risks to your product and allows you to rank them based on probability of occurrence (how likely is the issue to occur) and impact (if the issues occurs what is the impact to the customer…nuisance to loss of service). This does not have to be an exhaustive process and covering the primary categories gives you confidence of knowing what could occur and ability to develop mitigation plans.
Thanks for reading and as always, comments, suggestions, likes and shares are always appreciated.
Bruce Winsatt, Winmoore, Inc