← All Blog Articles

Product Life Cycle Stages: What Your Roadmap Should Look Like at Each Stage

Product Life Cycle Stages: What Your Roadmap Should Look Like at Each Stage

The product life cycle is the single most taught framework in product management. Every MBA textbook, every marketing 101 course, every PM primer walks you through the same four stages: introduction, growth, maturity, decline. You’ve seen the curve a hundred times.

The problem is that the textbook version tells you what the stages are. It almost never tells you what your roadmap should actually look like at each stage. It doesn’t tell you how many engineers to allocate. It doesn’t tell you what objectives the team should be on. It doesn’t tell you which stages deserve Transform investment and which should be harvested. And it was written in 1966 — before SaaS, before platforms, and long before AI collapsed the cost of building a product to near zero.

This article fixes that.

The product life cycle has four stages: introduction, growth, maturity, and decline. Each stage represents a distinct phase in a product’s commercial trajectory, with different customer behaviour, margin profile, competitive dynamics, and strategic priorities. Product leaders use the framework to allocate roadmap capacity, team shape, and business objectives appropriately — and to manage a portfolio of products that sit at different stages simultaneously.

My Personal Experience

TL;DR: In PE and NED work I see companies constantly misallocate capacity because they don’t think about their products as a portfolio at different life-cycle stages. They over-invest in maturity (because maturity customers shout loudest), under-invest in introduction (because new products stay side-of-desk), and refuse to acknowledge decline (because nobody wants to kill their own product). The four life-cycle stages aren’t just descriptive — they’re prescriptive. They tell you where your roadmap capacity should go.

The Classic Four Stages (The Bit Every Article Has)

Raymond Vernon coined the modern product life cycle in 1966. The core insight is that products have a finite commercial life following a predictable S-shaped curve:

  1. Introduction — Low sales, high per-unit cost, negative profit. You’re investing ahead of revenue.
  2. Growth — Sales accelerate, margins improve, competitors start entering. This is the “hockey stick” everyone wants.
  3. Maturity — Sales plateau, competition is intense, margins stabilise or start to compress. Revenue is highest but growth is gone.
  4. Decline — Sales fall, substitute products take share, margins erode. Harvest, reposition, or retire.

Some sources add a fifth stage (“development” before introduction) or a sixth (splitting maturity into “saturation” and “maturity” proper). The distinctions matter at the margin but the four-stage model is load-bearing. Every product you own is somewhere on that curve — which is the first thing most product leaders forget.

The Operational Reframe: Products, Not Companies

Here’s where the textbook treatment breaks down.

The life cycle curve was drawn for a single product. Vernon was thinking about the Ford Model T, the Boeing 707, the transistor radio. When you read a modern article telling you “your company needs to innovate through the maturity stage,” it’s making a category error — smearing the single-product frame across an entire company.

A real company has a portfolio of products at different life-cycle stages simultaneously. A cash-cow product in late maturity. A growth-stage product scaling into its market. A new introduction-stage product trying to find visionaries. And — if the company is healthy — a speculative bet that isn’t yet a shipping product. See the BCG Growth-Share Matrix for the classic portfolio lens, and the Ansoff Matrix for how the risk profile of each product-market bet differs across the mix.

The roadmap question is not “what stage is our company at?” It is:

Given the mix of products we have, are we allocating the right amount of resource to the right problems at the right time?

That question — not the shape of the S-curve — is what the product life cycle is for. Everything that follows in this article is about answering it.

Stage-by-Stage: What Your Roadmap Should Actually Look Like

Here’s the operating-model view. For each stage: the dominant roadmap question, the team shape, the objective type, and the most common mistake.

Stage Roadmap question Team shape Dominant objective Biggest mistake
Introduction Does someone care enough to pay? 2 engineers + 1 PM (minimum viable team) Discovery outcomes — problem-solution fit Side-of-desk allocation; no dedicated team
Growth How do we win the segment before competitors catch up? Small dedicated squad + GTM resource Revenue growth in target segment; retention Premature platform generalisation
Maturity How do we defend margin and extract adjacent value? Multiple squads; strong KTLO; adjacency pods Margin, Rule of 40 , expansion revenue Mistaking customer requests for growth strategy
Decline Harvest, reposition, or retire? Skeleton team; redirect capacity to new bets Cost, cash extraction, migration plan Continuing to feed features to a dying product

Notice that the roadmap isn’t just “what features ship when.” It’s what shape of team is working on what kind of objective. Capacity-based planning is the tool that makes these trade-offs visible to the board.

Introduction Stage: Is There a Problem Worth Solving?

The introduction stage is where almost every company I look at in PE or NED work is underinvested. The pattern is depressingly consistent: the CEO has a good idea, nobody does a proper business case , the work gets sprinkled across an existing team’s already-full backlog, six months later nothing has shipped, and the idea is quietly abandoned.

The fix is the minimum viable new-product team: 2 engineers and 1 product person, dedicated, full-time, with nothing else on their plate. Most companies can afford this. What they can’t afford is the priority whiplash of pulling those people back onto the Run product every time something breaks.

At introduction stage, the roadmap should be almost entirely about discovery — is there a problem worth solving, for whom, and will they pay? Very little of the work at this stage is “ship more features.” If you’re counting feature releases, you’re measuring the wrong thing. You should be counting reference customers and revenue-backed commitments. See product discovery in roadmaps for the detail, and — if the product hasn’t yet cleared problem validation — the early-stage validation cluster covers the specific thinking tools: Proof of Usefulness as a board-level scorecard, and MVP vs MLP vs MVA for deciding what shape the first shipped version should take.

Growth Stage: Win the Segment Before Someone Else Does

Once you have clear problem-solution fit and a beachhead segment, the game shifts. The introduction-stage team scales. You add engineering capacity, yes, but you also add GTM capacity — this is the point where distribution starts to matter more than product.

The dominant roadmap question becomes: can we win one pragmatist segment as the obvious choice, then expand? This is where Geoffrey Moore’s chasm sits — between early adopters (who buy vision) and the early majority (who buy references). See Crossing the Chasm in the AI era for the detail on what’s actually changed about this transition.

Growth-stage roadmap mistakes:

  • Premature platform generalisation. You try to build something for everybody before you’ve won somebody. Every engineering hour spent on generic extensibility is an hour not spent deepening your position in the beachhead.
  • Feature-factory sales. Salespeople bring prospect-specific features into the roadmap because it’s easier than selling what you have. A feature factory looks like growth-stage activity but produces growth-stage bloat.
  • Unclear target segment. If the pipeline is scattered across six industries, you haven’t picked a beachhead — you’re still in introduction-stage behaviour with growth-stage cost.

Maturity Stage: Defend Margin, Attack Adjacencies

Maturity is where most revenue in most companies lives. It is also where most capacity is quietly wasted.

The temptation is to keep adding features to the mature product because existing customers shout the loudest and your CSMs are the squeaky wheel. The reality is that most of those feature requests are marginal — the customer is asking for them but wouldn’t churn over their absence. Meanwhile, the Transform side of the portfolio — the next product, the adjacent pool of value — gets starved.

The PE lens on a mature product: what adjacent pools of value can we attack through our existing channel before a competitor attacks us? A company that sells accounting software to small business has a distribution asset (the customer relationship, the sales motion, the trust) that could be used to sell payroll, banking, tax filing, insurance, or any number of adjacent products. Every one of those is a roadmap bet that’s dramatically cheaper than starting from zero, because you’ve already solved the hard part: distribution.

This is where the Run / Grow / Transform and Three Horizons lenses become essential. If your maturity-stage product is 95% of revenue but 99% of capacity, you’re not allocating to Transform at all — you’re just calling it “innovation projects” on a slide.

Decline Stage: The Grown-Up Conversation Nobody Wants to Have

The hardest conversation in product management is “this product is dying; we should stop feeding it.”

Decline-stage products still generate revenue. They still have vocal customers. They still have engineers emotionally attached to them. The default behaviour at almost every company is to keep investing — not because the returns justify it, but because the organisational cost of ending the product is higher than the financial cost of continuing.

A board-level roadmap conversation should regularly address: which of our products are in decline, and what is our plan? The options are roughly:

  • Harvest — minimal investment, maximum cash extraction, migrate customers over time
  • Reposition — find a new segment or use case that restarts the curve (rare but possible)
  • Retire — sunset gracefully, redirect capacity and customers to a successor product

The worst option — and the most common — is to quietly keep allocating capacity at growth-stage levels while revenue stagnates or declines. Capacity planning that makes this visible at a board level is the single highest-leverage change most portfolio companies can make.

The 2026 Reframe: AI Didn’t Change the Shape of the Curve. It Changed the Economics of Every Stage.

Every article about the product life cycle written before 2023 assumes that building the product is the hard part. Most of the “strategies per stage” advice you see — heavy R&D in introduction, scaling production in growth, cost reduction in maturity, and so on — is fundamentally about managing build cost across the curve.

Here’s what’s changed:

The cost of producing a new solution has collapsed to near zero. The cost of convincing a customer to buy it has not changed at all.

This asymmetry changes the economics of every stage, even though the shape of the curve looks the same:

  • Introduction stage is now dramatically cheaper to enter — but correspondingly more crowded. The bottleneck has moved from “can you build it?” to “can anyone tell you apart from the twenty other AI-built products addressing the same problem?” Discovery and distinctiveness matter more than ever.
  • Growth stage is now where the real investment lives. Distribution, trust, reference customers, brand — the things AI hasn’t made cheap — are now the dominant cost. Most founders underestimate this and end up under-capitalising growth.
  • Maturity stage has higher stakes. If you stop investing in your mature product, an AI-era entrant with near-zero build cost can undercut you on price or overtake you on features within months. Defence has got harder.
  • Decline stage happens faster. Substitutes arrive sooner; the long tail of a declining product is shorter than it used to be. Being honest about decline sooner is more valuable.

The textbook advice — “invest heavily in R&D during introduction” — is now partially wrong. You don’t need heavy R&D; you can probably prototype the introduction-stage version with two engineers in a fortnight. What you need is heavy discovery and heavy distribution readiness. Different skills, different team shape, different objectives.

The Board / CFO Lens on Product Life Cycle

When I look at a portfolio company’s roadmap, the first thing I want to see is capacity split by life-cycle stage. Not by team. Not by squad. Not by quarter. By stage.

A healthy mix for a mid-stage SaaS company roughly looks like:

  • 60–70% on growth and maturity products (protecting the revenue base)
  • 20–25% on introduction products (the Transform bets)
  • 5–10% on decline management (migrations, sunsets, harvest)
  • ~5% reserve for discovery / horizon 3

An unhealthy mix — which I see constantly — is 95% on maturity, 3% on decline (spent pretending to revive dying products), 2% on “innovation” that is actually a rebrand of feature work on the maturity product, and zero on introduction. That company is optically growing but is organically declining. It just hasn’t shown up in the revenue numbers yet.

The board’s job is to make sure the grown-up conversation happens: what are we spending on each stage, and is that consistent with our strategy? If you claim to be a growth company and you’re spending 95% on Run/maturity work, something has to change.

The Side-of-Desk Anti-Pattern (Again — Because It Matters)

The single most common failure I see is the introduction-stage product that never got dedicated capacity. The pattern:

  1. CEO has a good idea
  2. Nobody does a proper business case with targets
  3. The work is allocated to an existing team who already has a day job
  4. It gets deprioritised every time the maturity product has a fire
  5. Six months later it’s half-done and nobody owns it

The fix is not complicated:

  1. Proper business case — revenue and customer targets someone will stand behind personally
  2. Dedicated team — 2 engineers and 1 PM, nothing else
  3. Protected capacity — same discipline as WIP limits
  4. Outcome-led objectives — reference customers acquired, not features shipped. See outcome-based roadmaps and objective tagging methodologies .

Most companies can afford this. What they can’t afford is the opportunity cost of never taking an introduction-stage bet seriously.

Extending Maturity: Adjacent Pools of Value

One of the strongest differentiators of a well-run mature product is what happens at the top of the curve. The textbook advice — “defend market share and focus on cost” — is defensive and therefore limiting. The better lens is offensive:

What adjacent pools of value can we attack through our existing channel, before a competitor attacks us through theirs?

This is what the Ansoff Matrix’s market development and product development quadrants are for, and it’s the heart of the PE “attack adjacencies” play. A mature product is an asset, not just a cash flow. The asset is its distribution, its customer trust, its data, its integrations. Those are worth more in combination with an adjacent product than as a single-product cash cow.

This is also why platform business models matter so much in the AI era. Network effects are the one category of moat that AI cannot erode. A mature single-product business is vulnerable to AI-era entrants; a mature platform business benefits as the ecosystem around it grows.

Common Pitfalls in Life-Cycle Thinking

Even teams who use the life cycle conceptually trip over these:

  • “Life-cycle extension” as a euphemism for refusing to kill a product. Extending maturity is legitimate; milking a declining product whilst telling yourself it’s “mature” is not.
  • Treating the company as one product. If you’re a multi-product business, the question “what stage are we at?” is meaningless. Ask it per product.
  • Assuming the curve is inevitable. Some products jump to a new curve (an S-curve transition). Plan for it.
  • Measuring all stages with the same KPIs. Revenue growth is the wrong primary metric for introduction; reference-customer count is. OKRs per stage should look different.
  • Ignoring the Cagan operating model shift. Vision-led execution (which works in introduction) is the wrong model for maturity. Outcome-led, empowered teams are what maturity needs. See the product operating model for the detail.

How RoadmapOne Helps

RoadmapOne is built for exactly this problem. Tag each objective by life-cycle stage, Run/Grow/Transform, or Three Horizons. The capacity grid shows you — at board level — what percentage of your engineering and product capacity is actually going to each stage. Most leadership teams are surprised when they first see the real split. That’s the point.

Frequently Asked Questions

What are the four stages of the product life cycle?

Introduction, growth, maturity, and decline. Some frameworks add a development stage before introduction (making five) or split maturity into saturation and decline prep (making six). The four-stage model is the most widely used and captures the operationally distinct phases.

Which stage is most important for product managers?

All of them, but the most commonly under-managed stage is introduction. Products in introduction tend to get under-resourced because they don’t generate revenue yet, and the CEO’s attention is elsewhere. This is the failure mode most worth fixing.

How do you extend the maturity stage?

Three routes: (1) expand into adjacent segments using your existing distribution (market development); (2) launch adjacent products to existing customers (product development); (3) reposition the product to open a new sub-segment. All three are easier if you treat the mature product as a distribution asset rather than a feature set.

How long does each stage last?

Completely variable. Consumer fads cycle in months; enterprise infrastructure products can spend a decade in maturity. What matters is not the duration but the trajectory — is revenue growth accelerating, plateauing, or declining? Stage is defined by trajectory, not by time.

Is the product life cycle still relevant in the AI era?

More relevant, not less. What’s changed is the economics of each stage: build cost has collapsed, sell cost has not. The shape of the curve is unchanged but the right allocation of capacity has shifted — away from building, toward discovery (introduction) and distribution (growth).

How does the product life cycle relate to Run/Grow/Transform?

Run/Grow/Transform is the capacity-allocation view; the product life cycle is the product-trajectory view. A single company has Run (maturity/decline products), Grow (growth-stage products), and Transform (introduction-stage products) happening simultaneously. Tagging objectives by RGT on the roadmap is the operational instantiation of life-cycle thinking.

Conclusion

The product life cycle is the most taught and least applied framework in product management. Every PM can describe the four stages. Almost none can tell you what their current capacity split is across those stages, which of their products is where on the curve, or what the roadmap should look like at each point.

The practical work is straightforward but uncomfortable. For each product, be honest about its stage. For each stage, allocate the right team shape, the right objective type, and the right amount of capacity. Resist the temptation to over-feed maturity and under-feed introduction. Have the grown-up conversation about decline.

Most companies won’t do this. That’s the opportunity for the ones that will.