After the innovation phase, assuming your product made it through the abyss, it came to growth. But there will come a time when your product will enter the maturity phase. This is inevitable, we just need to review the S curve of technology adoption in several practical cases:

This chart was created and published by Peter Brimelow in the article “The Silent Boom” in Forbes, July 7, 1997 issue. I did a quick search but couldn’t find an updated version. Most likely Internet, PC, and mobile have already reached 100%. Perhaps what is growing now is Artificial Intelligence and I believe that what is in the initial phase is NFT and metaverse, which seem not to have crossed the abyss yet.

Why does it happen?

There are three reasons for a product to reach the maturity stage of its lifecycle:

• Market exhaustion: This is the case for the TV in the previous figure. The TV market matured some 30 years after television was invented, that is, 100% of the addressable market that could buy a TV already had one. What was the solution that your manufacturers found to get out of maturity? In fact, they didn’t get out of maturity and eventually entered the last phase: the end of life. The solution they found was to create new TV products that could go through the entire lifecycle again. Today, television technology lifecycles are much faster, and the next technology starts its growth phase even before the previous technology leaves the same phase. Currently, TV manufacturers no longer wait for market exhaustion to create a new TV. They already use innovation as a way to force the current product to maturity and enjoy the growth phase of the new product.

• Disruptive innovation: It is an innovation that helps create a new market and a new perception of value, and that eventually completely changes an existing market and its perception of value (over a few years or decades), rendering old technology obsolete ( https://en.wikipedia.org/wiki/Disruptive_innovation). This is the basis of the book The Innovator’s Dilemma, mandatory for all people who work with technology, by Prof. Clayton Christensen, Harvard professor and innovation consultant. Disruptive innovation is what happened to film cameras, with the arrival of the digital camera; or with cell phones that only made voice calls, with the arrival of smartphones; with traditional encyclopedias, with the creation of Wikipedia; and with CDs and DVDs with the launch of audio and video download and streaming services. Sometimes, disruptive innovation can be created by the same industry, as a strategy to defend against the maturing market. This is the case of the TV industry, which is launching SmartTVs, and the cell phone industry, with the launch of smartphones.

• Programmed maturity: There is also a situation where the product owner, instead of waiting for maturity to happen, actively manages it. This is the case of TV manufacturers who barely launched plasma TVs, soon launched LCD TVs and then LED TVs, not allowing time for the market to saturate and anticipating maturity with the new version. This also happens in software product, mainly in installed software like Windows, MySQL, Nginx, Asterisk and several others. Anticipating the obsolescence of your product, your manager is already planning the release of new versions and the end-of-life process of previous versions. This process is usually very slow and, in many cases, traumatic. This is the recent case of Windows Server 2003, released in April 2003. It entered a state of programmed maturity as soon as the next version of Windows Server, Windows Server 2008, was released in 2008. As of 2008, it has lived in the of maturity; in 2010, it stopped being sold; July 14, 2015 was the date set by Microsoft to no longer support the product, that is, it decreed the product’s end of life. For online software products, scheduled maturity doesn’t make much sense, as the product is updated frequently and the user usually doesn’t suffer from updates. Of course there are exceptions, even for online products. There are cases where the product development team chooses to rewrite the product, for some reason, and decides to release a new version. In this case, it is important to understand that you will be putting the current product in a state of scheduled maturity and you must manage it as such. That is, you must plan the entire maturity and end-of-life cycle of that version, including thinking about what to do with existing customers of the version that will enter scheduled maturity and how to migrate them to the newest version of your product. This is something that should be discussed as one of the factors that can influence the product development team’s decision whether or not to go and develop a new version of their software product.

When does it happen?

It’s not too hard to tell when you’re coming to the maturity phase. If it is a programmed maturity, you will define when it will happen. If it is not programmed, just look at the growth of your product and notice that it is growing more slowly. Another point that happens is that growth; when there is, it will always be organic, that is, there is no point in investing in advertising and marketing as you will not have new sales no matter how much you invest.

It’s a little unsettling to enter the product maturity phase, especially if it’s not a scheduled maturity. At that time, nostalgic phrases like “in the good times…” begin, but the important thing is not to get discouraged. First of all, you need to make sure that your product has really reached maturity, or if there is some other reason for the slowdown in growth. To make sure your product has reached maturity, you should ask yourself a few questions:

• Are we still focusing on the problem? As we saw in the Innovation: Focus on the Problem chapter, every product exists to solve a problem, and it is essential that the product manager never lose sight of this. When a product enters the growth phase, the focus often shifts from the problem to be solved to how to accelerate that growth. When this happens, the main tool that can help accelerate growth, which is the focus on the problem, is lost. When the product manager and product development team lose this focus, the chances of product growth starting to slow are very high, giving the impression that it has reached maturity. For years, we have had strong growth in Locaweb’s Website Hosting product. As I told you in the previous chapter, in 2012 we brought in a consultancy specializing in pricing, which after a lot of research and analysis, suggested changes to our hosting plans to optimize and increase our revenue and profit. The changes were in the limits of the plans and in the services included. Their suggestion was to reduce the number of sites per plan (there were already rare cases of customers who hosted more than one site per plan) and, to compensate, to offer included services such as WebChat, for chat service. As I said before, these changes ended up having no effect on revenue and profit at all, and we ended up wasting a lot of time and money on analysis to make these innocuous changes. But that wasn’t the worst. With the changes made, our Web Hosting product has gone further from addressing our customers’ problem. They came to feel that the product had less of the core feature and that we put in the additional services that made the product more expensive. Our customers ended up finding better solutions on the market. This affected our product, which slowed down considerably in 2013. As a result, we decided, more empirically, to do what we call a repackaging of the Website Hosting product, changing the limits based not only on data but also on our knowledge of customers. and your problems, and on all of our 15 years of experience with the product. With the change we made, which cost us much less time and money in its planning phase, it grew back at its old pace. Therefore, it is important for the product manager and his development team to never lose focus on the problem he solves, and to ensure that he is solving it in the best possible way. This example illustrates well what I said in the previous chapter when I said that in addition to metrics, you need to use other information, such as experience, intuition, judgment, and qualitative information, to make product-related decisions. The consultancy made us look exclusively at metrics, making us disregard all our empirical knowledge of the product.

• Is the market slowing down? This is a second very important point to be analyzed when one observes a slowdown in growth. How are your competitors doing, are they also slowing down? And is the market as a whole slowing down? Are there any economic issues in your country or state that may be impacting your market? All of these issues should be evaluated when you start to notice a slowdown in your product’s growth.

As can be seen in the domain registration curve, from mid-2013 onwards, there seems to be a slowdown in the number of .br domains registered per year. At that moment it was a little early to be sure that there was a slowdown happening, but this information already gave indications. This overshadowed us a bit when we analyzed the slowdown of Locaweb’s Web Hosting product. So even if you evaluate the market and come to the conclusion that it is slowing down, you and the product development team can never lose focus on the problem it solves and on ensuring that it is solving it in the best way possible. Even with the market slowing down, it is possible to have growth if your product is an excellent solution to the problem of a group of people.

Between 2016 and 2017 the deceleration seems to have become very clear, doesn’t it? What in mid-2013 seemed just a possibility is clearly confirmed. However, care must be taken not to confuse circumstantial deceleration with deceleration due to maturity. As you can see in the real-life S-curve image, some technologies such as the telephone, the automobile, and electricity have had circumstantial slowdowns before reaching maturity. Economic crisis scenarios can impose a circumstantial slowdown or a circumstantial acceleration. See below what happened during the pandemic crisis, when several businesses had to digitize:

• Is there a disruptive substitute? This is the third point to consider when a product begins to show signs of slowing growth. Is there a different product category on the market that replaces yours? In the case that I mentioned about the slowdown in the growth of Locaweb’s Web Hosting, there was also a product category with strong potential to replace ours; were the website builders like Weebly, Wix, and SitePX. Since the first website building services, we have always been aware of this potential, which is why we launched our website building product to compete directly with Website Hosting as a solution to the problem of people who wanted to have one. There is also another problem that Web Hosting solves, which is the need to host and run web applications with a database. To solve this, there are application hosting solutions on the market today, such as Heroku and Google App Engine. With that in mind, we also launched our application hosting solution, called Jelastic Cloud. It is worth noting that disruption does not only exist in the technology used by the product. Business model is also a form of disruption. Locaweb launched its first Cloud version in 2008. We chose to maintain the same business model as Web Hosting, including disk space and transfer in the price and charging a monthly fee for the package. In 2009, AWS (Amazon Web Services) started to become well known for its Cloud Computing services, which were very similar to the technology that Locaweb offered. The big innovation came in the business model. Amazon chose to charge the services by the hour and to charge for disk space and transfer separately. Despite being a more complex way of charging, it had the attraction of charging only for what was used. When we launched Locaweb’s Jelastic Cloud, we also opted for this business model.

In short, before accepting that your product has really reached the maturity stage, it is very important to be sure of this. In the example I gave of Locaweb, it is clear that there was still room for growth if we focused on the customer’s problem.

Assuming that it is not a programmed maturity, that you have carried out the analysis shown, and that, even turning the focus of the product manager and the development team to the problem that your product solves, you have not managed to resume growth: this is the time to accept the situation and begin to reduce the investment in development and marketing of your product.

You may also decide to move your development and marketing efforts to another product in your portfolio. We’ll see more about product portfolio management and how to allocate investments to different products in that portfolio in Part IV – Product Portfolio Management of this book.

Another important point is the need to reduce operating costs. You can’t have a mature software product that costs a lot to operate. The operating cost typically comes in the form of human labor, i.e. cost to fix problems and customer service costs. Ideally, from the growth stage, your product has a very low operating cost, with low rates of problems and service costs.

To make such a product, the product development team must ensure the quality of the product being put into operation, both from the point of view of technical quality and concern of the engineering team and from the point of view of ease of use and concern. from the UX team.

Once you make these divestments in development and marketing, probably by allocating them to another product in your portfolio and lowering operating costs, your product can still have a long life in maturity. It all depends on whether the software product still gives back to its owner while continuing to solve the problem for existing customers.

This situation can be sustained for months or years. Even if there is no more investment in development, it is necessary to maintain a minimum investment in maintenance, which should make sense within the analysis of the return of your product. This minimum investment in maintenance must be coordinated by the product manager. He should assess his situation and decide to invest effort only when bug fixes and updates are needed.

It is worth remembering that by maintaining the product in this way, you will be periodically shifting the focus of the development team, which is now focused on another product. Therefore, such maintenance should be kept to a minimum. The need for maintenance is likely to increase over time due to the aging of the code that makes up the software, and over time this can make the cost of maintaining that product greater than the return.

Next phase

If you eventually get to the point where the cost of maintaining the product no longer outweighs the return it gives, it’s most likely time to prepare for your next phase: the end of life, the subject of our next chapter.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

Digital Product Management Books

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.