end of life /ɛ́nd ə́v lájf/ v. To discontinue, drop, put out of misery, send to sleep with the fishes, take round the back and shoot, go the way of the Norwegian Blue
Product managers are full of contradictions: if we’re not busting a gut to launch something, we’re trying to kill our older products off.
The problem is that software companies have an annoying habit of accumulating cruft. ‘Cruft’ is one of those delightful words that I urge you to use in Board presentations to confuse the audience. Cruft is that unpleasant mixture of dust, fluff and other detritus that accumulates in the corner of your sofa.
Cruft is also is a fairly accurate description of all those legacy versions of your products that accumulate over time and are equally troublesome to get rid of.
How pristine is your product portfolio? #
It is important to have a regular cleaning schedule to prevent the unexpected build-up of cruft. In product terms, this means having a defined, published end-of-life process.
But aside from an unpleasant analogy with poor domestic cleanliness, why is it necessary to worry about the accumulation of legacy products? A few reasons:
- Eventually the operating system version your product runs on will go away
- It may become prohibitively costly or risky to have customers on a broad spread of version, all of whom are expecting future bugfixes
- The knowledge about older products may leave your company through employee turnover, again increasing your risk
What is not a legitimate reason is that it would appeal to product managers’ mild obsessive-compulsive tendencies (just me then?) to have all customers neatly on the most recent version of a product. That may be immensely pleasing, but is generally unrealistic. Your products should serve the needs of the customer, not the other way around.
What’s in the way of your customers’ upgrades? #
There are often perfectly sensible reasons why a customer may not want or be able to move up to the latest version every time you release, such as:
- Cost of upgrade
- Expensive change controls
- Integrated to specific version of API
- No perceived value for them in the upgrade
- Upgrade process is complex, time-consuming or risky
Running your end-of-life programme #
The key to a successful end-of-life programme is transparency. If there are no unexpected surprises, it is more likely that everyone will accept that there will be progress and change, and simply plan for it.
There are many things that you can do in addition to run your end-of-life programme well. A few examples are:
- Consider what you can end-of-life every time you launch something new
- Always have a current and well-communicated rolling schedule
- Communicate often, clearly, consistently internally and externally
- Ensure you know exactly how much you’re making from each supported product version, and how much each costs to maintain
- Ensure that the cost, complexity and effort of the upgrade process for your customers is appropriate to the frequency with which you want them to upgrade
Policy and planning #
You need to define an end-of-life policy and share it with your customers. You may want to consider referring to it in your standard terms and conditions or from your technical support policy. The end-of-life policy itself does not need to be particularly complex; it just needs to set out clearly the mechanics of how you will retire products.
Typically you need to define:
- What triggers the end-of-life process for a product version. This could be at your discretion or tied to the release of newer versions.
- How much notice is given before a product is completely withdrawn and how notice will be given.
- Whether there is a ‘phase-out’ period between initial notification and actual end-of-life and how long it lasts.
- What support and maintenance you will provide during the phase-out period, if any.
- Whether any premium service exists to extend the service life of a product beyond end-of-life.
Ad hoc versus rolling schedules #
If you have a few products that release new versions on a regular, periodic basis, it might work well for you to define your end-of-life policy such that you only actively support and maintain a small number of the most recent versions. This kind of rolling schedule could look something like this:
This particular policy defines that when a new version is released, the version two releases ago ceases to receive bug fixes (engineering support) but continues to receive technical support for a further six months. At the end of the six months, technical support ceases also. The advantage of this method is that your customers know that new releases automatically trigger old versions to move into the end-of-life process.
Alternatively, if you plan to release a relatively small and manageable number of products, and update them infrequently, then you may want to decommission them as you need to. If you adopt this model, it is much more important to ensure that your customers receive adequate warning to allow them to start planning their upgrade.
Over to you… #
What does your end-of-life programme look like?
What do you find tricky?
I’d be really interested to hear from you in the comments or on Twitter.