The four stages of the product lifecycle

3 minute read

All product engineering is not the same.

That may seem like a simple statement, but software engineering is often equated to churning out lines of code, and if that’s the case why does it matter whether that code is for a mature product like SQL Monitor or our latest innovation like Spawn — it’s all just development isn’t it? Well, as you might expect the answer is that it’s not that simple. Back in the 90’s Geoffrey Moore wrote a game changing for the software industry called Crossing the Chasm in which he describes how products, and categories of products, grow from early stage innovations through to mass market adoption (and onwards through decline to end of life!). As an example, here’s a mapping I did in 2019 about where Redgate’s product groups lie on Moore’s lifecycle:

The technology adoption lifecycle.png

Redgate’s 2019 product groups on the technology lifecycle

In Moore’s later book Dealing with Darwin, he talks about how in different stages of the lifecycle different approaches to innovation are needed. Innovation is often associated with the kind of work we do in our Foundry team on very early stage product ideas, but the reality is that software engineering itself is almost always innovation, whenever we add new features and capabilities to our products we’re innovating, and Moore called out these different types of innovation with names like ‘line extension innovation’, ‘platform innovation’, ‘renewal innovation’ and so on (19 different types in all!).

Geoffrey Moore innovation types.png

As a company striving for ingenious simplicity, 19 types of innovation whilst academically interesting is hardly a practical day-to-day model. Back in 2016 Ken Beck, one of the original founders of the whole agile movement, published a blog post talking about a 3x model he’d been applying to his work at Facebook. His model was drawn on a post-it note which puts it firmly in our ballpark:

Kent Beck postit.png

In this model he describes how a product moves from exploration where you’re learning through experimentation, through to expansion where you’re experiencing high growth, and then extract where it’s time to focus on a good return on investment. We used this model to map out our own version which adds in a retire phase to cover products in our portfolio that are in declining markets…

Explore exploit sustain retire.png

The primary business goal for a product typically varies by which lifecycle stage it’s in:

  • Explore — Find product-market fit (PMF) — Discover a customer segment which has a valuable problem and prototype a solution which satisfies that segment and is desirable, feasible, and viable.
  • Exploit — Increase serviceable addressable market (SAM) — The product is in a period of growth, fit has been found, focus is on commercial scaling. Focus on improving conversion of the existing market and broadening applicability to wider customer segments.
  • Sustain — Return on investment (ROI) — Mature products with linear growth and an established customer base. Focus is on sustaining growth, improving stickiness, reducing risk, improving maintainability, reducing cost, simplification. Development decisions are based on a strong understanding of ROI informed by an established user base.
  • Retire — Maximise profitability — Products in this category are no longer part of Redgate’s strategy or are in decline. We aim to maximise the profitability of these products through appropriate development work to slow the decline (platform support, maintenance issues).

So what does this practically mean for you if you work in engineering? When we go through our dynamic re-teaming exercise at the start of the year, we ask the teams to put together a charter which makes it clear what products a team will be working on and importantly where the products sit in this model and hence the style work that you might be doing as a member of the team. As we stated at the start of this post; all engineering is not the same, but perhaps more importantly we recognise that all engineers are not the same. By being clear on the software lifecycle and allowing fluidity between teams, we hope that people can gravitate towards the work that best suits them where they can make the biggest contribution.