“We are doomed…we are losing money”
“The ship is sinking…”
“We are going down…”
These were the kind of emails a business manager at a former employer would send to the entire organization whenever there was an issue with a recent update to the organization’s core application. It could have been something as trivial as an unresponsive button, and straight away, he would shoot off such emails to the entire organization making sure to cc all the chief executives.
I was working as a Software Engineer back then and I remember that I would always say a prayer before we released any updates to the core application. Essentially, my prayer would be, ‘if it turns out there is an issue with this new release, please let it not be as a result of one of my modules’. Yes, I know this was totally selfish, but this was about job preservation
Anyone that has worked in technology long enough, would have at one time or the other experienced the after-launch chaos. The after-launch chaos happens when users find it difficult to adopt or learn a product after release and as such fight back. It can be quite a difficult period for managers as calls come in from angry customers and stakeholders. This type of chaos is not only as a result of bugs or errors in a new product release; It can also happen when users are instituted to abandon an old system for a supposedly better system. In other words, the after-launch chaos is the users pushing back against a new product or release.
It is natural for humans to try and avoid pain at all costs and as such managers hope and pray not to experience this after-launch chaos. However, this chaos is actually good. The after-launch chaos signifies that users are actually attempting to use the product no matter how unsuccessfully. In a world with so many competing products, it is actually a blessing in disguise to have some after-launch chaos.
The after-launch chaos is a necessary process in the product lifecycle and with proper preparation and planning, the disruption can be minimised. Technology teams should reorient themselves to anticipate and plan for the ensuing chaos after any new product release to better support their users. Technology teams need to change their mindset from expecting everything to work after product launch to expecting nothing to work after the product launch.
Causes of the After-Launch Chaos
To better manage the after-launch chaos, technology teams must first understand the root causes of this chaos.
Users hate nothing more than encountering problems while trying to use a product to achieve an objective. This causes the angry support calls, bad reviews and product abandonment
Humans hate change and when users are instituted to use a new system or product, they push back. People will rather stick with the status quo than try something new. The fundamental response to change is not logical and this is why techies are puzzled when users choose to stick with an old manual system over a newer system that seems better on paper. This emotional response to change usually causes users to devise ways to sabotage the new system by giving bad reviews to management or refusing to give the system a chance.
Asking users to abandon their old way of doing things for a new product, is the same as asking users to learn new skills. This can be really frustrating for users, as It means abandoning approaches they have long since mastered to become novices again. This dip in learning curve means that users may initially take longer to achieve the same objectives with the new system. Unfortunately, this learning curve is absolutely necessary and if not managed correctly, users may dump the new system go back to their old approaches and systems.
It is worth repeating that the after-launch chaos is an important stage in any new product launch or release. The introduction of a new system signifies a change in the users’ mind. Technology teams must therefore not only see themselves and system builders but also see themselves as change-setters. For products to be successful, technology teams must also learn to help the users manage the change process.
Managing After-Launch Chaos
Plan for the Chaos
It is important for managers to set time in the project plan for the post-launch support. Managers must also ensure that enough resources are on hand to support a product after the launch. Planning in this way ensures that technology teams are prepped and ready to handle any fallout from the after-launch chaos.
Hire a Change Manager
Depending on the size of the project, managers may need to budget for a change management specialist. Big organization deployments definitely need the expertise of change management specialist to help prepare and help users through the change. For smaller projects, the project manager may need to double up as the change manager.
Communicate the Chaos
While it seems obvious, it is extremely important to notify users of any upcoming product launches or releases. Beyond that, it is also important to prepare users for the potential disruptions that may ensue. It certainly is not advisable to explicitly tell users to expect major chaos after launch, however users should be prepped to expect some disruption as they learn to use a new system. The communication should also include contact details of the team that will be handling user issues after the product launch.
Establish Change Management Process
It is very important to establish a process to help manage the after-launch chaos. One idea could be to set up regular meetings with end users to discuss feedback and issues. Doing this makes the users feel like they are being heard and their concerns can be addressed in a structured manner.
Another idea is to also release a product in smaller bits. This is especially important for big software deployments. Rather than releasing the whole set of features to users in one swoop, it could be easier for users to digest if the software is release is smaller bits.
Whatever process is put in place, it must always be for the benefit of helping the end user embrace and adopt the new system.
Pull the Plug on the Old
For new product that will replace an older system, it is very important for management to be clear on the conditions under which the plug should be pulled on the old system. If the plug is not be pulled on the old systems, users will eventually find their way back to the old system if they experience enough frustration with the new system.
For internal product launches, it is also important to note that management have to be disciplined not to pull the plug on a new product before users have gone passed the learning curve. It is common for management to be put under pressure to pull the plug on a new internal software due to frustration for users learning to use the new system. Management must allow the chaos period to unfold as there is no shortcut.
New product launches or releases are changes that induce the after-launch chaos. This is because product launches are essentially changes. Technology teams must move from seeing themselves as system builders to change-setters. As such technology teams must learn to not just develop products, but also manage the softer aspects of change management to better help their users adopt their new products.