Product Life Cycle and Software Engineering Management
By: Andrei Gridnev
Tags: Leadership, Software Development, Startup, Engineering Mangement, Product Management

Engineering Management

Product Life Cycle and Software Engineering Management

How to staying on top of delivery, people management, and system ownership at each stage of the product life cycle

Photo by Annie Spratt on Unsplash

From a software engineering perspective the product life cycle can be split into six stages: Development, Introduction, Growth, Maturity, Decline, and Abandonment. Each stage has different goals and challenges, so engineering managers have to shift their focus accordingly to keep providing best results for their organisation:

At the Development stage , the goal is to build and deliver the product prototype into the hands of customers.

, the goal is to build and deliver the product prototype into the hands of customers. At the Introduction stage — to find product/market fit.

— to find product/market fit. At the Growth stage — to improve the product offering and accelerate growth.

— to improve the product offering and accelerate growth. At the Maturity stage — optimise operating costs and keep on improving the product to defend its position in the market.

— optimise operating costs and keep on improving the product to defend its position in the market. At the Decline stage — to minimise operating costs.

— to minimise operating costs. At the Abandonment stage — to sunset the product efficiently.

Not only the organisation goals, but also the size of the engineering team and the complexity of the product technical systems change from stage to stage, making the engineering managers’ job more difficult.

This article explores how software engineering managers can stay on top of delivery, people management, and technical systems ownership at each stage of the product life cycle.

Development Stage

For an organisation, the goal of this stage is to build a product prototype and get it into the hands of customers. Hence delivery leadership should be the main focus for the engineering managers at the Development stage. Managers should use every opportunity to ship the prototype sooner, so that the Product could get feedback from real customers

At this stage the product isn’t bringing any revenue. Instead, the organisation is spending its resources on building it. The sooner the prototype is built, the less this stage is going to cost to founders or investors.

Technical system ownership responsibilities need little attention at this stage. There would be few systems to own and maintain. Technical debt wouldn’t matter for a product that hasn’t been shipped yet.

Every technical aspect of the product that can be outsourced to save development time, should be outsourced. For example, if a product needs search capabilities, Engineering may choose to use a service like Algolia or use a managed Elastic instance, rather than setting up their own Elastic installation. If the product needs user login, then Engineering may choose a service like Auth0, instead of building their own login and user management functionality.

People management responsibilities don’t take much time at this stage either. The engineering team would be small and the stage would last between several weeks and several months. That means, there won’t be a need to do much hiring, promotion, and training. The key thing is to ensure that engineers are staying motivated and focused on delivery.

Introduction Stage

The goal of the Introduction Stage is to find the product/market fit before the organisation runs out of budget, so delivery leadership remains the priority for engineering managers. However, people management and technical system ownership responsibilities are becoming more important compared to the previous stage.

The product may pivot several times during this stage. To support that, engineering managers should optimise delivery process for agility. In other words, every system that the developers build should be flexible enough to be replaced, or repurposed, or thrown away. That would allow product managers to test their hypotheses quicker, find the product/market fit sooner, and move to the Growth stage.

Because of frequent pivoting and failing experiments, engineers may start losing their confidence in the organisation’s ability to succeed and the team morale may decline. To prevent that, engineering managers need to ensure that the team members understand the challenges of this stage, have realistic expectations, and are working towards the organisation goal.

Growth Stage

This is the most challenging stage in the product life cycle for engineering managers as they have to scale delivery, system ownership, and people management processes and practices to keep supporting their organisations efficiently. What is more, each of those aspects starts competing with each other for attention.

Engineering teams typically reach the Growth stage running an overgrown product prototype with plenty of technical debt accrued at the previous two stages. As a result, engineers have to deal with scalability, reliability, maintainability, and performance issues at the same time. One approach is to start paying off relevant technical debt at the very beginning of the Growth stage by dedicating 10–20% of overall engineering capacity to that. In other words, if the engineering team is 10 people, then at any time 1–2 developers should be working on paying out the tech debt. If the team is 30 engineers, that would be 4–6 people.

Typical product users also change during this stage. They no longer are “innovators” and “early adopters” who tolerate minor glitches in the product. They start to come from the “early majority” cohort who value product reliability in addition to its “newness”. That means bug-fixing and minor improvements start competing with strategic initiatives in terms of delivery. As a result, to progress strategic initiatives and at the same time promptly respond to bug reports and random requests from Design, Product, and Marketing, engineering managers may choose to reserve some capacity for that type of work too. For example, 20–30% for bug-fixing and minor improvements, and 50–70% for initiatives.

During the growth stage, the number of developers in the team increases as well. For bigger products, the engineering team eventually splits into smaller teams with narrow focus. Each team needs a lead, so the management structure in the Engineering has to become more complicated with two and sometimes three levels of management.

At the Development and Introduction stages, the organisation mostly needs experienced developers who can quickly build the prototype and then rapidly iterate on it. From the Growth, stage hiring juniors starts making a lot of sense. There would be lots of tasks requiring little experience. New hires, regardless of their experience, would need on-boarding, upskilling, mentoring, more or less clear paths for career growth and promotion framework. All aspects of people management would become important in a growing engineering team.

During the Growth stage the entire organisation radically changes. As a result, the original members of the engineering team may want to leave because the new environment would require skills that are different from those that were useful at early stages. If such people leave, the team may lose crucial technical knowledge and expertise. Managers must support such people through the change and help them find their place in the new reality to keep them with the organisation for longer.

Maturity Stage

At the Maturity stage the product growth starts slowing down. Strategic product development continues, however, optimising operating costs and increasing overall efficiency becomes increasingly important.

Delivery leadership is still important at this stage. However, the engineering team would experience less pressure from the Product and less urgency to ship new functionality. Product quality is getting more important because new customers now represent the “late majority” cohort who value quality and stability of proven technology and products, rather than newness. Because of that, the engineering team has to allocate more time for various minor improvements and bug fixes. One way to deal with such tasks is to forward them to a dedicated team of developers. Some developers enjoy working on small well-defined tasks, especially when those tasks benefit the customers and the product.

Less pressure from Product allows engineers to pay more attention to system maintenance. The engineering team may have an opportunity to run large maintenance initiatives, like migrations to new architectures and platforms, paying out lots of technical debt without the risk of dropping the ball on delivering product initiatives.

Availability and reliability get increasingly important. Forming a Site Reliability team might be a way of dealing with it in bigger products.

Engineering team growth slows down at the Maturity stage. As a result, the environment and culture become more stable. Engineers get fewer opportunities in people management but lots of opportunities in technical leadership as this is finally the time to do lots of things right from an engineering perspective. Engineers and teams within the Engineering department continue to specialise.

Developers start spending lots of time in meetings to align efforts with other teams and non-technical departments. That impacts their productivity. Engineering managers have to be mindful of that and ensure developers have enough uninterrupted time to spend on writing code to remain productive.

The Maturity stage can be the “golden age” for the engineering team. Its members get an opportunity to solve complex problems in a successful and still growing product, try new tools and technologies, new ways of working, there is time to invest into training and mentoring as well.

Decline Stage

A product reaches the Decline stage when its customer base and revenue start to shrink despite the Product team efforts to restart growth. At a certain point there would be no product initiatives and most work coming from Product or Support teams would be requests for minor improvements or bug reports. That means that delivery leadership would no longer be among the top priorities.

Technical system ownership responsibilities are taking more time as the organisation optimises operating costs of the declining product, including the costs of running its technical systems.

Security, performance, availability, and reliability remain as important as before. If the Site Reliability team does not exist by this stage, it may be worth creating it. Or, if the entire engineering team is too small for forming a dedicated team, most developers should get familiar with SRE responsibilities as keeping the product running smoothly and preventing incidents would be crucial for the organisation.

At the Decline stage, the Engineering team typically needs fewer engineers than at previous stages. There would be little to no hiring and some people may transfer to other departments or leave the organisation. Before people leave the team, it is crucial to document their knowledge about the product in system diagrams, readmes, developer documentation, incident playbooks, etc. A declining product may stay at this stage and generate revenue for years and remaining engineers would need that knowledge to maintain the product during that time.

It is important for engineering managers to set expectations for their teams regarding the type of work during that stage. For example, that there would be fewer opportunities to use the latest technologies. One consequence of that is that developers may feel that they are lagging behind the industry. To deal with it, managers may have to create opportunities for their teams to try new tools and tech.

Staff retention would probably be the top people management priority. To motivate developers to stay longer with the team, engineering managers may want to keep improving the work environment and negotiating more perks for their team members. For example, extra annual leave, great equipment, conference tickets, generous training budget, etc. Awesome environment, flexibility, and supportive management can be extra reasons for some engineers to stay with the team and the organisation for longer.

Abandonment Stage

Products eventually reach their end of life. Their markets may disappear, customers may go to competitors, the organisation may decide to focus on more profitable products or may launch a more advanced product that would provide a way better experience.

There is not much delivery and system ownership work at this stage. If the product gets shut down, the only goal for engineering managers is to find a cost-effective way to do that and archive the data and source code.

If the product gets merged into another, then engineering managers need to propose an efficient (in terms of time, money, customer disruption, etc) technical strategy for that and execute it.

As for the people management responsibilities at this stage, they can be boiled down to helping engineers find a new place within the organisation if that is possible, or outside, if the entire organisation gets shut down.