End-of-life
Your software product may have arrived here coming from three different paths:
1. Your product growth has slowed, and you have done all the analysis and testing described in the previous article to make sure that it has indeed reached the stage of maturity.
2. Or, you have launched your product and are unable to bridge the chasm that lies at the end of the innovation phase, the first phase of the life cycle of your digital product.
3. Or, you have opted for a scheduled maturity by planning the end-of-life of the current version of your software product against a new one that has been developed and released.
Regardless of the path you take — unscheduled maturity, not crossing the chasm or programmed maturity — you have eventually reached what is known as the product’s end of life. Sometimes product managers use a more elegant term for this phase, the sunset of the product.
As with all previous phases, this phase also has to be managed. It is a mistake for a product manager to believe that when a product reaches the end of its life, the work of product management ends. On the contrary, this phase requires as much attention as the previous ones.
The first step is to recognize that you have reached the end of life, and a great indicator is to assess whether the cost of maintaining the product is greater than the return it gives. If this happens, there is a strong indication that it is entering this phase.
The decision to end a product’s life is not scientific. The numbers help a lot in this decision; however, as explained in the Thoughts on metrics article, in addition to metrics, you need to use other information such as experience, intuition, judgment, and qualitative information to make the end-of-life decision for the product.
Each of the three possible pathways your product may have taken to the end-of-life phase will bring with it specific facts and considerations for making your making decisions about your product. Typically, this is committee decision-making with product people and company executives.
If your product has indeed entered the end of life, the product manager will need to manage this phase. The decision and its management depend on the path it takes to reach it, and this is what we will see in the following sections.
End of life by unscheduled maturity
This is the worst case because besides being unplanned — as is the case with end-of-life after programmed maturity — this is a difficult situation to identify. Before you decree that it is the end of life of your digital product, you need to make sure that it is not only temporary. The most common in these cases is to numb the product for a while.
What does numb mean? It means not investing in its development and marketing, and watching how it behaves. Has it stopped growing? Or does it grow very slowly? Does it make sense to stop selling it? Or can the product be left in the market for a while? After some numb time, you should re-evaluate whether it is worth investing again in it.
This was the case with Locaweb’s Virtual PBX product, which we decided to lay dormant for about 3 years, without any marketing and development investment so that we could invest in other products. Even without any investment, the number of customers did not decrease. Even at times there was even a growth. This growth, when it happened, was quite small, but it was nonetheless a growth. For this reason, we decided to invest in the product again.
Another example, already commented in the previous chapter, was the case of Locaweb’s Web Hosting product which, because we focused too much on metrics and disregarded our empirical knowledge, ended up in a non-growth situation that, fortunately, could be corrected. It was not web hosting end-of-life. It was a growth deceleration we caused to the product.
By that, I mean again to be very careful not to make a hasty decision because the end of life by unscheduled maturity is extremely difficult to identify.
If you are really sure your product has reached the end of its life, you will need to manage this phase. The first decision you should make, along with the committee I mentioned — made up of people who work with the product and company executives — is whether you will discontinue the product or make it dormant. This decision will be based on the return it is giving to the company and the cost of maintaining it.
If the product still yields a considerable return, you are likely to decide to maintain it and make efforts to reduce the cost of maintenance. The product manager will be responsible for coordinating maintenance cost reduction efforts and assessing whether these costs are lower than the return that the product gives.
On the other hand, if the return on this product is small, or your operating costs are too large and not reducible, you are likely to discontinue it. In this case, the manager should coordinate all necessary steps to discontinue the product, including:
1. Set the sales end date and execute it;
2. Check for a replacement in the company’s product portfolio or in the marketplace;
3. If there is a substitute, define how a client can migrate to this one;
4. Prepare communication with customers by setting deadlines for the end of the product;
5. Test this communication with a small group of customers to assess the impact and make the necessary adjustments;
6. Perform communication with the entire customer base;
7. Follow up and act on time when necessary.
End of life by not crossing the chasm
If your product enters the end of life because it does not cross the chasm, although this is not a desired situation for the development team, it is an important situation that needs to be identified quickly, and the product manager plays a key role in detecting this.
This situation is easier to detect because the product does not grow. He wins a few clients, the *early adopters*, and then stops growing. At this point, you should assess with your marketing manager whether the product communication strategy is being effective and is reaching people who have the problem your product is intended to solve.
It is also important to understand with potential customers whether the product not only solves the problem but how they are willing to compensate you for that product. You can always make adjustments to the product and your marketing model to suit your customers.
However, if even after evaluating these issues and trying to make adjustments to the product and / or your marketing model, you are unable to make it grow, it is time to decree its end of life. The sooner you reach this decision, the better, so as not to waste time and investment on a product that will not work.
In this case, as the product has a small customer base, the options of keeping it dormant based on having a sizable revenue make no sense. Therefore, the only viable decision is to discontinue the product. As in the case of unplanned end-of-life, here too the product manager must coordinate all the steps necessary to discontinue it, which are the same as those described earlier in the *Unplanned End of Life* section.
End of life by scheduled maturity
This is the best of the three options for the software owner, but it will give the product manager a hard time. In the case of installed software, this happens when new versions are released. For online software, this occurs when the development team chooses to rewrite the product for some reason and decides to release a new version. This decision to rewrite an online product should be very thoughtful because the time spent rewriting your product is unused time in its evolution from the point of view of those who use it.
It may happen that your product was not properly planned from a technical point of view and now you are at a point where: either rewrite it, or the product can no longer evolve. However, falling into such a situation should be the exception rather than a normal part of a digital product’s life cycle.
In a nutshell
For installed software, end-of-life by scheduled maturity is intrinsic to the model, while for online software, end-of-life by scheduled maturity should always be the exception.
Because this kind of end-of-life can be programmed, the product manager must, in conjunction with UX and product engineering, design what this phase will look like, always aiming for minimal impact to customers. At Locaweb, in our email marketing product, we got to the point where we had to change the database. We used MongoDB which, due to design problems, was not being able to withstand product growth; that’s why we decided to change the database to PostgreSQL.
We designed this rewrite of the product in such a way that the customer would not be negatively impacted when the new version with PostgreSQL was implemented. Nothing has changed in the way customers use the product. The only impact they noticed was that the product was performing better, which was expected.
This is the most important point to think about at the end of life: what will happen to customers who are in the current version, which will become the “old” version when we launch the new one? This has to be carefully thought out, and the focus must always be on minimal impact to the customer.
Of course, when the new version has a different interface and interaction than the old version, the customer will be impacted. It is very important to test some of them to measure impact before forcing change for the entire customer base. In some situations, you may even decide to keep the old version for a while, given the difficulty of getting customers to the new version. But don’t forget, the focus is always to make your customers suffer as little as possible.
Concluding
We saw in detail in previous chapters the entire life cycle of a software product, going through all its phases: innovation, growth, maturity — whether it can be programmed or not — and the end of life — that can come after maturity or when the product does not cross the chasm that separates the innovation phase from the growth phase.
To conclude this life cycle theme, let’s talk now about the difference between startup and digital product management. This difference has a lot to do with the life cycle of a software product.
Digital Product Management Book
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my book Product Management: How to increase the chances of success of your digital product, based on my almost 30 years of experience in creating and managing digital products.
