Don’t mess up the installation and upgrade processes for your software products. They have the opportunity to negatively impact customer satisfaction, revenue, and profit. Like dusting, nobody notices when you do it right, but it is obvious when you don’t. These two aspects are actually different sides of the same problem: getting your software product into production for a customer and allowing you to get paid.
Don’t miss the opportunity to make a great first impression. That first time your new customer really sees your product is when he tries to install it. We have all had the experience of installing something that was really difficult, with lots of manual steps, poor installation documentation, and lots of “I wonder what I should do next” stop points. Or you call the help desk and get someone as confused as you are. Even if the help desk people are competent and help you on the first call, the product now is branded in your mind as complicated and hard to use. Bad first impressions are hard to overcome.
When a new version for your product comes out, how painless is it to get it installed? How much disruption to your customer’s business does it cause, and how much effort is required to get it right? If your customer perceives that it is harder to install your upgrade than to move to your competitor, what do you think he will do? It is much better to never make the customer even ask the question.
One place I worked had a fairly common CRM (customer-relationship management) package from a major vendor. In order to get some problems fixed and take advantages of some new features, we needed to upgrade from version n to version n+1. The vendor said it would take two days, so it was scheduled over a weekend. It took more than seven days and involved a lot of work from both the vendor and us. That was a week where we couldn’t take orders, send invoices, or even properly handle support calls without a lot of manual effort. That vendor doesn’t supply the CRM system there anymore.
Over the years I have been thrown into situations with existing product sets that had serious customer satisfaction problems. It is nice in one way: it wasn’t my fault things were the way they were, and since I was the new kid on the block I could always ask the stupid questions like “why is that so hard?” However, the issues were usually engrained as much in the culture as the technology, and culture can be interesting to fix.
In one case I started by looking at the support call log for the past six months. Almost 80% of the calls were about installation or upgrades. Some of the calls were open for weeks until they were resolved. The support team was top notch, but the software was just very complicated to install, and it had to be manually installed at lots of places. These calls had several suboptimal results: support calls cost real dollars to respond to, the customer is not going to pay his invoice until the product actually works which delays revenue, and the customer isn’t real happy with your product. The latter persists and gives your competition an easy way to throw FUD (fear, uncertainty, and doubt) the next time the customer needs more product. I took a small set of the best engineers and made it their problem. They started by sitting at the support desk taking calls, calling customers who had reported serious installation or upgrade issues, and listening to what the customer wanted. Now, as is often the case, what the customer wanted was that all you had to do was get the installation CD close to the system and everything would happen automatically.
The team came up with a totally different way of looking at the problem. A couple of months later they had an installation process that we could use across the product line that asked all of the necessary questions up front, then automatically did everything everywhere. If it was an upgrade installation, then it didn’t even ask the questions, it figured the answers out from the existing environment. The net result was that six months later our support calls for installations and upgrades were only about 10% of our calls, and were almost always resolved in the first call. I and the CEO started get emails from customers who wanted to tell us how great our software was. Even better, we entirely replaced our biggest competitor at a large account simply because we could get a new project up and running in one day instead of the three days the incumbent vendor claimed was required.
In another case we had a product that was fairly critical to a customer’s operation. The primary engineer on the product was much more interested in adding neat new features than in making the upgrade painless. I sent the engineer to visit the customer for a few days and see how the customer was actually using the product, and to directly see how lost time for an upgrade impacted the customer. When he got back, the engineer disappeared into his office for a couple of weeks, then demoed his new upgrade mechanism to us. I sent him back to the customer’s site to show the customer and get his feedback. The customer was ecstatic – his upgrade downtime went from many hours to less than a minute, and the manual input required went to virtually nothing, eliminating the human error that had sometimes forced the customer to re-install the upgrade several times to get it right.
The best part of both of these examples is that there was very little change to the product – it was almost all in the installation.
In most software development organizations, the developers view installation as unimportant and uninteresting. No one wants to work on it. It is often the last thing done, and is done quickly without much thought and without much testing. The first thing that needs to happen is to change that culture. Engineers usually take great pride in their work. I have found that if you actually talk to them about the importance of installation and upgrades to their customers and the company’s revenue, you can usually get them to change their view.
When should you start worrying about these issues? You can maybe get by a couple of early adopters with a labor-intensive installation process, and maybe you can get that first customer to the first real production release by going in yourself and doing all of the work involved. But after that, the product must be easy to install and upgrades must be trivial to do and have the absolute minimum impact on the customer.
While every situation is a different, there are a few guidelines to consider:
- Only ask a question once.
- Ask all of the questions up front, especially if the installation / upgrade process will take more than a few seconds.
- Verify, to the extent possible, all installation parameters at the time they are provided to the process.
- If something goes wrong during the installation process, make sure you give the customer enough information to determine the exact nature of the problem and to give your help desk folk a good chance of solving the problem on that important first call.
- Allow the user or administrator to make a reasonable change to any configuration item at any time without a re-install, and “remember” the change.
- For upgrades, pick up the current installation parameters. In general, there should be no need to ask questions during an upgrade.
- When replacing a competitor’s product, give the customer the opportunity to pick up configuration information from your competitor’s product. Even better, have your installation look for your competitor’s product and give the customer a single click option to configure your product the same way.
Talk to your customers about their issues with upgrades and installs. Make sure your qualification tests include significant testing of the process, especially upgrades.
Make sure your customer doesn’t have to upgrade everything at the same time. If you have different components that may be scattered in the customer’s environment, make sure that different versions can interoperate to some degree, and publish those rules. If components at version n+2 can operate with components at version n and n+1, that’s great. If you are limited the compatibility to only version n+ 1 and version n, then publish that. Of course, some features may not be enabled when all components aren’t at the same level that supports those features case.
The most critical place to have an effortless install is for your demo or trial package. If that doesn’t install obviously and quickly with no problems, you don’t even have a chance for a sale..
The last word:
Where do the most experienced aircraft engineers work? On the landing gear. It’s hard to get right and you have to get it right. Bad things happen when they fail, and there is no opportunity to try it again. Who should design and develop your installation and upgrade processes? Your most experienced designers and developers. If you don’t have top notch installation experts on staff, go rent some. Once you get it right, it is fairly easy to keep it that way.
Keep your sense of humor.