Playbook for running a product end of life (EOL) project
Life happens. Software solutions / products are sunset, discontinued, retired, put into End of Service (EOS) or in End Of Life (EOL) state for a variety of reasons including:
Companies have options on how to address the EOL state including:
Each one of these options have their own pros and cons. The type of EOL method chosen is a business decision which needs to be made with care. For example, a sudden and complete product retirement can have a massive impact on customer experience, when compared with a long term announced product retirement where customers can plan for replacement with a reasonable heads up notice. It really is a matter of the business objectives.
- 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 of the above
Each one of these options have their own pros and cons. The type of EOL method chosen is a business decision which needs to be made with care. For example, a sudden and complete product retirement can have a massive impact on customer experience, when compared with a long term announced product retirement where customers can plan for replacement with a reasonable heads up notice. It really is a matter of the business objectives.
Referencing past EOL projects
I always admired the way Microsoft sunset their Microsoft Money product. It had nothing to do with the actual usefulness or function of the product. I loved the product, but for some business reason, Microsoft felt the need to retire. The decision was done. Debate was over, and execution had started. At this stage I was the customer.
Same thing happened when Microsoft retired ISA Server, Windows XP or when Google retired Google Reader.
The Microsoft Money product had several moving parts to it (perpetual components as well as subscription components) and all needed to be tackled as part of the EOL plan. 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.
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. Development 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.
Same thing happened when Microsoft retired ISA Server, Windows XP or when Google retired Google Reader.
The Microsoft Money product had several moving parts to it (perpetual components as well as subscription components) and all needed to be tackled as part of the EOL plan. 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.
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. Development 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.
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 – its ok. You are human. Learn to manage them…FAST
Yes, if you are emotionally attached to a project 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.
It is imperative not to underestimate the personal emotional experience to have to EOL a product worked on and grown by yourself or others, but you will also need to remember quick that it is your responsibility to manage the business and other team needs be they strategic, operational, communicational, executional or other.
In the case when you are an external, who was brought in to run the EOL, my biggest recommendation would be to get a sense of how this project impacted the teams, their sense of worth as well as the service it provided to customers as part of this process. Identifying the needs that this project delivered to people enables you to better manage the situation.
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.
It is imperative not to underestimate the personal emotional experience to have to EOL a product worked on and grown by yourself or others, but you will also need to remember quick that it is your responsibility to manage the business and other team needs be they strategic, operational, communicational, executional or other.
In the case when you are an external, who was brought in to run the EOL, my biggest recommendation would be to get a sense of how this project impacted the teams, their sense of worth as well as the service it provided to customers as part of this process. Identifying the needs that this project delivered to people enables you to better manage the situation.
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.
Phase 2: Clearly articulate WHY the 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, its time to start focusing on the HOW.
Highly recommended: Create a set of Critical Success Factors (CSF) against which you would measure a successful execution. You will want to share these with the team when being questioned.
Now that you are clear on the WHAT you need to do, and WHY, and have a sense of direction and impact, its time to start focusing on the HOW.
Highly recommended: Create a set of Critical Success Factors (CSF) against which you would measure a successful execution. You will want to share these with the team when being questioned.
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...).
Remember that an EOL is very problematic, as it can impact them both on a technical, business time disruption as well as economic levels. 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:
Remember that an EOL is very problematic, as it can impact them both on a technical, business time disruption as well as economic levels. 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
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 (CFT) to share any initial thoughts, stats collected, communication directions etc. as to bounce off your present thoughts on how best to run this.
The action item here 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, and pencil in an owner for you to reference in the future. 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.
The action item here 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, and pencil in an owner for you to reference in the future. 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.
Make sure that you have a representative from core departments such as:
Sales
|
Marketing
|
Channel / Distribution
|
Finance
|
Operations
|
Technical Support
|
IT & Systems
|
Legal
|
When preparing to talk to the CFT, I would recommend to have a sense of what your replies would look like to the following questions as to enable the discussion to happen:
Generic
|
|
Timings
|
|
Based on replies from the above and others added by the CFT, establish the plan and get execution plan agreement.
Note: You may need 2 to 3 iterations before you have an agreed to plan across the CFT with all elements having a reply and ownership status identified.
Note: You may need 2 to 3 iterations before you have an agreed to plan across the CFT with all elements having a reply and ownership status identified.
Phase 5: Get executive leadership to all sign-off project
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.
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. By this point there should be no doubt in anyone's mind on what is going to happen, and who is going to do what and by when.
The business made the decision. You led the plan building which will lead to the execution of the process to put the product officially into EOL. Now just make sure you re-check that you are have done all you could to determine as many facets of the process as possible. Here is a tentative check list to go through:
Through the periodic reviews evaluate the readiness of the teams to execute from a process perspective. By this point there should be no doubt in anyone's mind on what is going to happen, and who is going to do what and by when.
The business made the decision. You led the plan building which will lead to the execution of the process to put the product officially into EOL. Now just make sure you re-check that you are have done all you could to determine as many facets of the process as possible. Here is a tentative check list to go through:
Marketing Readiness
|
|
Sales readiness
|
|
Support readiness
|
|
Administrative readiness
|
|
IT & Operations readiness
|
|
Finance readiness
|
|
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.
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:
In the end the key takeaways are:
Good luck in this process. I do not personally envy anyone who has to do this. As we said, life happens. Its not fun. Its hard, and generally grossly unpopular.
Products come and go, and as product manager it is up to you to live with this and guide teams towards the next big thing.
...Andre
- 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
- Remember its 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. Its not fun. Its hard, and generally grossly unpopular.
Products come and go, and as product manager it is up to you to live with this and guide teams towards the next big thing.
...Andre