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:
The natural progression of the 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 is not big enough to warrant company focus becoming a distraction to core business.
Strategic portfolio fit
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 available 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 of these options has its own pros and cons both for the company and 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 in 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 / 2003w). 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 or negative impact to stakeholders.
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 made. The debate was over, and execution had started. At this stage, I was the customer.
The product had several moving parts to it (perpetual components and 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 coordinated together with the support organisation to guide customers who will surely be seeking further clarity. Finance and operations would need to be synchronized to ensure partners do not continue selling a product 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 were now being re-allocated to another project. This situation is prime land for all emotions linked to fear, uncertainty, and doubt, no matter the condition.
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 its size, 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 the path the company took to get to that stage, in the end, it’s a business decision. To that effect, once the decision is made, 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 the 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 or decision to EOL a product, and there 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. It 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, to make the transition as painless as possible (of course, I assume 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 and economic level. We need to ensure that your EOL plan addresses these issues and helps and guides them accordingly.
Because of this, start by building a demographic view of your base:
How many customers are using the product today? Determine the 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 that would need to be handled by any department, and take note of everyone's actions due and by when. Where concerns are raised, give space to the relevant team to think about it, involve other team members of their choice to determine best the course of action their team will do to support this.
An extended list of questions and guidances relevant to this section is available from here.
Based on replies from the above and others added by the CFT, establish the plan and get an execution plan agreement.
Phase 5: Get executive leadership team sign-off
Summarise the execution plan properly and who will be in charge of what and by when. Once the plan is agreed, ensure you have a plan sign-off from the company's executive team. Please explain how you built the plan in collaboration with their team representatives, and always tie it back to the purpose of this exercise and its motivations.
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 agrees with 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 exercise.
Through 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. You have 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. Always remember empathy while balancing staying the course will be key!
Phase 8: Check in with the CFT for status updates.
Periodically check in with the CFT team to gauge execution state. Should there be any last-minute hiccups / unexpected queries, handle them on the fly.
When done, provide periodic updates to the executive team on how things are going by measuring how successful the execution was, covering what went to plan v.s. what needed some adjustments.
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:
Able to be executed without surprises
In the end, the key takeaways are:
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.
#product #process #peopletech #peopleintech #leadership #business #success #management #agilesoftwaredevelopment #strategy #projectmanagement #prodmgmt #productmanagement #productmanager #productpeople #stakeholders #communication