How to end-of-life a product with minimal disruption

Andre Muscat -

A hard truth of product life cycles...life happens. Software solutions / products are sunset, discontinued, retired, put into End of Service (EOS), End of Availability (EOA) or in End Of Life (EOL) state for a variety of reasons including:

  • Natural progression of product life cycle leading to new versions being released
  • Revision of strategic positioning / product direction
  • Revenue generation not to expected levels
  • Profitability not to expected or required levels
  • Growth not to expected levels, or in line with market opportunity
  • Cost controls, resource simplification, resource optimization e.g. development resources, OEM costs, marketing efforts and promotions, cost per lead, sales processes, training, follow up, finance and back office accounting, costs of support, reporting & auditing, complexity in price books and other factors needed to keep it going.
  • Quality and maintainability efforts superseding value generation to portfolio
  • Revenue generation not big enough to warrant company focus becoming a distraction to core business
  • Strategic portfolio fit
  • Market evolution
  • Satisfaction ratings causing damage beyond conventional control.
  • Revenue & Transactional trends (New Business v.s. Add-on Business v.s. Renewal Business) – which is the line sustaining this product
  • Change of company focus on more profitable products or opportunities (resource re-configuration).
  • Technical sustainability – development teams availability to maintain and grow and support.

Companies have options on how to address the EOL state including:

  • complete product retirement
  • product sale to someone else or
  • product freezing with maintenance continued
  • a condition known as “run for cash”
  • variants / hybrids of the above

Each one of these options have their own pros and cons both on the company as well as customers. Experiences are made easier when companies actually have established lifecycle and policy communications pre-established.

A complete product retirement is generally welcome when an appropriate or better replacement is made available (such as a new version of the product). These situations would include predictable events where processes can be properly built in and communicated advance e.g. Microsoft releasing new operating systems eventually seeing its older versions reaching EOL (e.g. Windows 10 over their latest Windows 8 / 7 / Vista / XP / 2003 etc). Furthermore it enables customers to plan for replacement with a reasonable heads up notice.

The same smoothness does not really apply when there is a sudden and complete product retirement which tends to have a massive impact on customer experience.

Here I deal more with the aspects of a complete product retirement from the market with minimal disruption!.

Living it from the outside...

I always admired the way Microsoft sunset their Microsoft Money product. It had nothing to do with the product usefulness or function. I loved the product, but for reasons which do not matter, Microsoft felt the need to retire. The decision was done. Debate was over, and execution had started. At this stage I was the customer.

The product had several moving parts to it (perpetual components as well as subscription components) and all needed to be tackled. There was ample announcement, as well as information on what would happen, how and by when. It also included guidance on what ‘next step’ options were available to customers.

Living it from the inside...

This example only presented the public facing part of the picture.

There is a lot that happens internally before such an announcement can be made. Marketing and PR surely need to be co-ordinated together with support, so as to provide guidance as customers seek further clarity. Finance and operations would need to be synchronized too as to ensure partners do not continue selling a product which is in EOL etc. Development, QA, UX and IT operation teams would also need lots of communication for a product they worked on themselves or had friends who worked on where now being re-allocated to another project. No matter the condition, this situation is prime land for all emotions linked to fear, uncertainty and doubt.

Getting to go! go! go!

Putting a product in EOL is one of the most difficult processes a product manager can manage. It’s complex, hard, lengthy, emotional and requires nerves of steel. In addition, it requires exceptional effort to ensure clear unambiguous communication with an impressive number of stakeholders who may or may not agree with the decision.

Unfortunately, we have all been guilty of, or seen companies place products in EOL state in an impressively messy manner. No one sets out to do it this way, but if you are not prepared, and underestimate the size of it, you will stumble and become an example of how not to do things.

No matter the business reason of how the project came to EOL, or path the company took to get to that stage, in the end it’s a business decision and to that effect, once the decision is done, the product manager owns the buck to get the business decision implemented as smoothly as possible.

Phase 1:  Emotions – it's ok. You are human. Learn to manage them…FAST

Yes, if you are emotionally attached to a project (like one you came up with, grew, implemented etc…) you can expect to go through the 5 stages of loss and grief i.e. Denial > Anger > Bargaining > Preparation of separation > Acceptance. You do not have much time, as people will start looking towards you for guidance very fast.

Remember that not everyone will agree or understand the need of EOL a product, and in here lies the very first step to take to get the process going. Understand the teams, and people behind the product. It will be essential in helping guide them forward. You can of course bulldozer your way through, though I tend to prefer to recommend guidance and acceptance. Always works out better in the long term.

Phase 2:  Clearly articulate WHY a product is being placed in EOL.

Properly and clearly summarize in one page the business reason(s) why the product is being put in EOL. Make sure that you fully recognize the driver behind the business decision, together with the upside of putting this product in EOL. Be clear on how the decision was built, and the foundations behind the driver.

Now that you are clear on the WHAT you need to do, and WHY, and have a sense of direction and impact, it's time to start focusing on the HOW.

Phase 3: Focus on customers

Customers are core here. It is imperative to understand the customer demographic, as to make the transition as painless as possible (of course I am assuming you want to retain the customers or see them come back in the future...). If not, well sensitivity aspects and needs go down :)

Remember that an EOL is very problematic, as it can impact them both on a technical as well as economic level. We need to ensure that your EOL plan addresses these issues as well as helps and guides them accordingly.

In view of this, start by building a demographic view of your base:

  • How many customers are using the product today? Determine total count of subscriptions / customers using the product.
  • How many are using for free?
  • How many are using in ‘Not For Resale’?
  • How many do not have active support contracts?
  • How may have active support contracts & when do they expire: within the next 12, 24, 36 months?
  • By when will all customers with active subscriptions / maintenance agreements expire?
  • How long have these companies been using this solution?
  • Determine count of customers & revenue per category.
  • Determine how many are on older versions.
  • Determine average count of units/nodes per customer of solution

Prepare initial replies towards main concerns. An expanded list of questions to reference and plan for is available from here.

Phase 4:  You are not on your own. Create a cross functional team (CFT)

Embrace the fact that you are not on your own and should not even attempt to do this on your own. Create and lead a cross functional team to share any initial thoughts, stats collected, communication directions etc. as to bounce off your present thoughts on how best to run this.

The plan is simple: Collectively review, refine, and improve your existing list. Draft up a list of concerns and areas which would need to be handled by any department, and take note of each and every one. Where concerns are raised give space to the relevant team to think about it, involve other team members of their choice as to best determine the course of action their team will do to support this.

An extended list of questions and guidances relevant to this section are available from here.

Based on replies from the above and others added by the CFT, establish the plan and get execution plan agreement.

Phase 5: Get executive leadership team sign-off

Once the plan is agreed, ensure you have plan sign-off from the executive team of the company. Make sure to properly summarise the execution plan, and who will be in charge of what and by when. Explain how the plan was built with their team representatives.

Should there be concerns, address them and return for sign-off. It is imperative not to execute the plan, unless all of the executive team responsible for the business are in agreement to the plan.

Phase 6: Determine readiness for execution

With a plan in place, fleshed out and in agreement, lead the process by a periodic visiting of the state of the agreed to action items which are bound to get identified through the course of the exercise.

Through the periodic reviews evaluate the readiness of the teams to execute from a process perspective.

Phase 7: Execution = go! go! go!

You have all you need to execute. A plan of execution covering who will do what and by when. You have dates of agreement. You have executive signoff to execute.

When the day comes. Wake up. Follow your morning routine. Take in a coffee and start the process.

Phase 8: Check in with the CFT for status updates.

Periodically check in with the CFT team as to gauge execution state. Should there be any last minute hiccups / unexpected queries just handle them on the fly.

When done, provide periodic updates to the executive team on how things are going by providing a measure of how successful the execution was covering what went to plan v.s. what needed some adjustments.

Final thoughts

With this blueprint you are equipped with the base of creating an action playbook through which to put a plan of action together which is:

  • Understood
  • Accepted
  • Able to be executed without surprises

In the end the key takeaways are:

  • Start early
  • Keep your emotions in check both whether you are vested into the project or not
  • Remind yourself that it's a business decision and why it is being done at all times
  • Build a plan
  • Communicate lots and lots
  • Listen, and listen more
  • Engage multiple teams to create the plan
  • Communicate status of plan building as well as execution results periodically

Good luck in this process. I do not personally envy anyone who has to do this. As we said, life happens. It's not fun. It's hard, and generally grossly unpopular.

Products come and go, and as a leader it is up to you to live with this and guide teams towards the next big thing.