No matter what our job is, everything we do in our industry is a part of the Product Life Cycle. From the first early researcher to the last salesman of the finished goods we all have to adhere to the current state of the product life cycle. But what is that state? How, as Technical Leads, do we adapt to each state?
First and foremost, the Product Life Cycle is the life cycle of, well, the Product. This post details how the stages in the Product disciplines (Product, Marketing, Sales etc.) translate and even rhyme with those of the technical disciplines (R&D and System Engineering in particular, Support, Manufacturing etc.). I will often give two (or more) very common terms that will include the same activities of the team performed over the same period in time.
Quick Definition of a Product
Claude.ai’s definition of a product is as follows:
“
A product is a good, service, or item created to satisfy a specific customer need or want. It can be a physical object, a digital solution, a service, or a combination of these.
Examples range from everyday items like smartphones and shoes to complex services like cloud computing platforms or financial advisory services. A product is essentially anything that can be offered to a market to satisfy a customer's desire or need.
”
And in smaller and simpler words, for the context of this post, a product may be anything – a little screw, a feature, a service, SW application or a full multi-disciplinary system. Anything, as long as it has potential clients and there is someone around the world who is willing and is capable of providing that product to the potential clients.
The Product Life Cycle
The Product Life Cycle refers to the different phases the product goes through from its inception until we shut down the product line and turn off the machines that are used to manufacture that product.
There are a few main models for the product life cycle; I have even given one detailed flow of a model in one of my previous posts; but all the models are based on the following 4 stages in the product evolution:
Introduction
In product terms the Introduction stage is when we examine whether we have something in our future pipeline for which we may find clients – a market. This is the wild stage of the Product Life Cycle in which we sometimes make drastic changes, even on a weekly basis, so as to accommodate a potential market’s immediate whim.
In R&D terms this is the stage of Research and Early Development, Product Launch and Client Alphas. In fact, in a lot of life cycle models the introduction stage is divided into two different stages: Discover & Development and Introduction. In these cases, the Research and Early Development would be the major activities in the former and the Product Launch and Client Alphas would be the major activities in the latter.
In this context, Research refers to the process of finding a solution for a problem or for a problem in an existing discovery or technology.
Early Development refers to the process of turning the solution into features that the end client may use.
Product Launch and Client Alphas are the stage where we have something that works with a lot of limitations that may be used to assess where the Product should be headed.
For example, in the epic TV series Silicon Valley, the technology developed in the research stages of Pied Piper was the inside-out compression algorithm but in the final product that they launched, after a lot of struggles, was “new internet”. In each stage of the series, they went ahead with a different product, the very first was a music application – the alpha that got everything started – all to assist the innovating technology to become the final product it turned into.
Note that the decision to cease a non-successful product should occur sometime within this stage and, of course, the sooner the better. Had we gone ahead to the Growth stage then we’d have already missed our properly timed opportunity and the costs, both monetary and reputation-wise, would be significantly higher. The best, of course, is to identify a non-fit product in the pure research stage however, in most cases, it is very difficult to assess whether there is a market for a completely new technology which forces companies to move forward to alphas and even betas in order to accurately estimate market.
Growth
After we’ve established what our product is and even have a few working prototypes, Growth is when we have to have the product working flawlessly in the client’s place as well as making sure its mass production flows are intact. This is also when we must have proper requirements for our product, for which our manufacturing and installation processes must comply.
In the product level, that is when we build the product’s reputation, every little thing can build the reputation higher or crash it down completely.
In R&D terms that’s when Development, Ramp-up and Manufacturing happen, whereby Development would be the finalization of the features for the clients, and Ramp-up and Manufacturing is the process of Transfer from R&D to Production and the establishing of a stable Supply Chain, a process to which I will dedicate a future post. In a nutshell, it is the processes where we identify what in the product’s manufacturing flow is different when we build the product in high volume as opposed to building only several units. We could use our home-model 3D printer to manufacture 5 units of our plastic covers however that wouldn’t be viable when building 5,000 units.
Growth is when we discover all the peculiar behaviors of the product that we did not know existed – and of course have to solve them.
This is already the phase where we do customization of our product for some clients so we could manufacture and ramp up manufacturing to their needs.
The Growth stage is also when the support processes are being developed to the point where activities such as product installation, maintenance and repair are finalized to allow the product’s seamless operation.
Maturity
The Maturity stage is when the product is already manufactured in full capacity. Hurrah!
Our production line works and our main job is to keep it running. EVERYTHING at this stage is to spec, with close pulse checks of Quality department. In R&D terms this is very often referred to as Production and Sustain, although the concept of Material Review Board (MRB) also requires involvement of R&D personnel.
When the product is already mature, we have to optimize manufacturing, installation and support for maximum profit\minimum effort and costs.
This is when, in accordance to our client’s requests, we add features to our product however we still have the luxury to select which features to implement and which not. Obviously, the features that will keep us on the optimization path of profit/costs ratio will be implemented first. In SW based products, this is when we will have a long list of bugs in our backlog.
In an ideal world, sometime between the time when Growth stage ends and the time when Maturity starts, it is when we start introducing the next gen product so as to keep our footprint in the market, be it in the list of features we have decided not to include in our current gen product or completely new concepts. The funny thing is that there is no “right timing” for the next gen introduction however, there are so many wrong timings e.g.; it would definitely be too late to start researching our next gen after our main competitor has released their next gen product which exceeds our current gen; as would be in the cases where our product relies on an element from a third party manufacturer that has already stopped manufacturing that element (the next gen should start long before – when he announces the end-of-life of their product); as would be when technology changes to the point where our current product is no longer relevant (did someone mention Nokia?); and so on.
Having said all that, did anyone could foresee how right the timing was for the first iPhone to be developed?
Decline
Every good thing must come to an end. Let’s differentiate between a happy end and an unhappy one. In the case of a bad ending where the company or the department shuts down, there’s not much to talk about. We take our stuff and go find our next adventure. In the case of a happy end where the product was successful, we have already launched the next gen, the clients are smiling and the board of directors’ smile is even wider 🙂 there is an orderly manner to conduct the decline and end of life of a product.
In R&D terms it is referred to Production and sustain towards End of life, so in other words it would be the bit in the product life-cycle where there is no research and no development and as such the R&D team, led by the System Engineering, mainly deal with putting out fires when they come up.
In terms of the product it is, in the case when we decrease the manufacturing capacity slowly (or not so slowly) to a full stop and in the case where the production line may be transformed into the next gen products, we make that shift and in the case when this transition is not possible we either scrap or sell the remaining tools. The same goes for servicing centers, although in a lot of cases the service continues a few months\years after manufacturing has ended. When it comes to SW based features and products, the different companies may keep the relevant servers a little bit longer, but it is only a matter of the company’s good will from that point on. It is also when people shift positions at work – get promoted, switch roles or in the sadder side of things get sacked.
Optimally, the clients should be informed well in advance when the end date of the product is and when the support ends for their product. In a less-than-optimal situation the clients are being informed a week before and then all hell breaks loose.
The expectation is that the clients stop using the product once it has ended and continue to the next get however, there are exceptions – I know personally a print shop owner that kept his Windows 3.11 old PC (unsupported since 2001) until the year 2015 (!!!) only because his super-duper scanner was not supported in later Windows OS drivers and he could not find a comparable product. If we take it a step further there are quite a few products out there that refuse to die to a point that there are companies that take over the original manufacturer’s place and have their own service, repair and even have their own spare parts production lines.
In a healthy product life-cycle during the decline of version N of a product version N+1 should already be somewhere between final growth and maturity otherwise with no replacement it would mean that the whole product line is dying.
An interesting caveat – when there is a change of technology between the generations there is that fun part for us lab-rats to clear the laboratory and prep it to the next gen. I say fun, because it is indeed a lot of fun to clear a laboratory when of course it’s not shut down because of cuts. You get to dig into the history of the research and development, see prototypes you never knew existed – yes, fun!
How the technical team fits into the Life-Cycle?
Like everything in the technical world, there should be a match between the technical skills and qualities of the team and the state where the product is in the life-cycle.
Introduction phase requires the R&D team to be as innovative as can be and for the System Engineer to be able to manage that innovative atmosphere. The team has to be limited only by the speed of light and even that limit is questionable at this stage.
Growth stage requires that the team to be knowledgeable of the already mature technologies out there in the industry.
Maturity requires a team that knows how to be creative while handling a stress of an axe raised over their necks. The team should come up with solutions “yesterday” as any problem in the field is a problem that already impacts a mass of clients. Usually, this is not the time to be innovative.
And finally in decline stage there should be a team knowledgeable enough to handle any problems that may occur quickly but also have them already know what their next role is and even have them start their onboarding process.
A common mistake, which I have also referred to in a previous post, is to continue with the exact same R&D team all the way through the life-cycle without realizing that the requirements from team are not the same as they were when the initial product research began. A highly innovative team would be the most frustrated team in the world if his current job is working on a declining product and a production-oriented team would be a bit lost in the introduction phase of a product. My meaning is not to sack the entire team any time the product shifts phase, but there would be room to re-think who to keep in this product and who we should reassign to another project.
That’s it for now. In this post we have covered the different phases a product goes through and what happens R&D-wise in each phase. However, I think the biggest take-away from this post is to make sure that the R&D team is a good fit in for the tasks at hand in each stage.