Revulytics Blog

A painful End of Life: How and when to kill your software product

November 1, 2012

Subscribe

Version 1.0 has been a loyal fighter, it served your company for 3 years, it helped you recruit your first customers and got you tons (or grams?) of cash and improvement ideas. But now things have changed. The kid has grown. Version 2.0 has been out there for a few months and Version 3.0 is in the release pipeline. The engineering team don't afford supporting version 1.0 any longer. You feel it's time you asked your developers to stand up, sing the company's national Anthem and prepare for a burial. But is now the right time to move on? How can you not cause pain?

At some point in our life/career we all tend to face the pains of resource management; be it lack of time, budget, human resources, or all of these combined with a few more! When the time comes to stop support for a software product, it's not a simple matter of just pulling the plug. You have an important group of people called customers to worry about. OK, you might have a defined company policy on terminating support x years after release, but does this make it any less painful for your customers?

  • Who is still using it and how loyal are they to your product?
  • Why haven't they moved on to newer versions?
  • Is it about platform incompatibility?
  • Are they stuck to using that silly feature which has been removed from later versions?
  • Has your new version become an unattractive bloated monster compared to the simple elegant design you had back in Version 1.0?
  • Does the new version offer enough incentives to upgrade or will it make absolutely no difference in your customer's life?
  • Is it cost related or simply laziness to upgrade?

These are a few questions you need to iron out BEFORE deciding when or how to tell your Version 1 customers that their time is up.

Consumer vs. Business applications

Upgrades for consumer products tend to be simpler and faster cause it is usually a single person decision based solely on their personal time and budget. On the other hand, getting people to upgrade software used in a corporate environments might be a wee more complex since (depending on your software) it might involve planning, testing, possible downtime and in extreme cases risk assessment and contingency planning by multiple teams. This brings up a few important points:

How easy is it to upgrade your software?

If you don't support automated upgrades (or didn't do so in version 1.0), maybe you would want to write a quick script to help those few loyal or business customers port their data from your old version to the new version. You can't blame your customers for lagging behind, if you don't make it ultra-easy for them to move on.

How much revenue would you get by convincing this customer to upgrade? If the (direct) extra revenue you get from upgrading a Version 1 customer is not worth your hassle, could this customer's word of mouth recommendation be worth the extra work?

What is the customer's incentive to upgrade?

OK, so you might have added 5 new killer features and a fancy new UI, but maybe this guy is doing just fine with the features in your old version. Why should he upgrade? Give him an incentive. Screw your killer features and instead look into what this guy uses in your current product and focus on how THAT got better. If you cannot find an upgrade incentive, then don't blame your customer for it. In such cases if you really need them to dump your old version, then throw out a heavily discounted upgrade offer. That will make THEM feel good and relieve YOU from the support pain.

Are customers REALLY aware of your new versions?

NO, customers don't always follow your blog, and NO, they don't always read your newsletter, and NO, your priorities are not your customers' priorities! Simply sending out an Email notification about your new version will easily get lost in midst of a chaotic mailbox. People need to be constantly reminded and the best time to grab their attention is whilst they are using your software. A notification popup saying "New version available; This is what's new/cool with this version; Download from here" can be easily implemented inside your application startup, however don't let this become a nagging nuisance. Respect your customer's space and give them a 'remind me in x days' option since you don't know what hell they might be going through at that particular time. Keep in mind that a customer might have a very VALID REASON why they don't want to upgrade, so respect this user group.

Getting Feedback

If upgrading to your new version is so important to you, then why not provide users with a means to send you feedback whenever they refuse to upgrade? In your popup reminder window you can have the options:  [Upgrade Now] - [Remind me later] - [I dont want to upgrade - tell us why]. From the latter option you might collect some useful information regarding the most common reasons people remain running the old versions. This will also help you build better incentives to push them to upgrade.

Implementing a Check-for-Updates mechanism

There are a number of points to look out for when designing your own call-home and update mechanism and this includes how to handle a broken internet connection, getting past proxies, firewalls and web-filters on the client side, building a reliable client-server protocol as well as several security aspects related to your web service. We will cover a number of these points in an upcoming blog post. In the meantime, a more straight forward option would be to choose a ready-made or hosted solution (such as Revulytics Usage Intelligence) which will relieve you from the hassle of building your own check-for-updates protocol and maintaining your own updates server.

So the time has come to pull the plug - Quantifying and minimizing the pain!

In order to know how many customers will be effected by your decision, it is essential to have a means by which to track how many active users are still running each of your builds and how many of them can benefit from a free upgrade through their SLA.  To have this information at hand whenever required, you need to use some form of call-home mechanism which reports back to a server which versions/builds are still in use. If you haven't built such a system yet, it is usually possible and somewhat common practice to  include the version number in your check- for-updates call-home request, however this will only work reliably if your check-for-updates mechanism is automated and does not rely on the user's manual intervention. Of course once you identified the users you ideally need a channel by which you can communicate with them individually to notify them about your intention to pull the plug. Sending out mass emails is not really ideal since you don't need to bother 90% of your customers who are already on the new builds. Therefore you need some form of targeted message pushing mechanism by which your server can talk back to your software to inform the clients with outdated builds that it's time to move on.

Luckily, this mechanism is already implemented inside  Trackerbird and with a single API call (i.e. 1 line of code) you can check for product updates and deliver any notification messages directly to the desktop of affected users (i.e. those running your old builds). This will give you the advantage of having more elaborate reporting at your fingertips without having to worry about protocol design or server maintenance.

Keith Fenech

Post written by Keith Fenech

Keith is Revulytics’ VP, Software Analytics and was the co-founder and CEO of Trackerbird Software Analytics before the company was acquired by Revulytics in 2016. Following the acquisition, Keith joined the Revulytics team and is now responsible for the strategic direction and growth of the Usage Analytics business within the company. Prior to founding Trackerbird, Keith held senior product roles at GFI Software where he was responsible for the product roadmap and revenue growth for various security products in the company's portfolio. Keith also brings with him 10 years of IT consultancy experience in the SMB space. Keith has a Masters in Computer Science from the University of Malta, specializing in high performance computing.