Who created the BCG growth-share matrix?

Bruce Henderson, founder of Boston Consulting Group, developed it around 1970 as a capital allocation tool for diversified industrial portfolios.

Does the BCG matrix work for SaaS companies?

Partially. The quadrant logic is useful, but it assumes relative market share drives cost advantage through an experience curve — a mechanism built for manufacturing that doesn't transfer cleanly to near-zero marginal cost software.

What is the experience curve the BCG matrix is built on?

The observation that unit costs fall a fairly consistent percentage every time cumulative production volume doubles, which Henderson used to explain why higher market share predicts higher margin and cash generation.

What can replace market growth rate on the vertical axis for software?

Nothing official, but many software teams weight raw market growth by net revenue retention, since a slower-growing but highly sticky market can generate more durable cash than a fast-growing market with high churn.

What should you do with a 'dog' product in the matrix?

Henderson's original advice was divest or minimize investment, but check first whether it's strategically load-bearing — some low-share, low-growth products hold a platform story or a key account together.

The BCG growth-share matrix for product portfolios

Guide · frameworks · 5 min read · last verified 2026-07-21

Reviewed before publication Editorial board Independent commercial review

In shortThe BCG matrix assumes market share drives cash generation through an experience curve built for manufacturing — a mechanism software often doesn't share. Here's the honest version.

The BCG growth-share matrix is probably the most recognizable two-by-two in business strategy, and one of the most casually misapplied to software. Boston Consulting Group's founder Bruce Henderson developed it around 1970 as a tool for allocating capital across a diversified industrial portfolio — think appliances, chemicals, heavy manufacturing. It's a genuinely useful piece of logic. It's also built on an assumption that a lot of software businesses quietly don't satisfy, and the honest version of this framework says so out loud instead of pretending the quadrants transfer cleanly.

What the matrix actually says

Two axes: market growth rate on the vertical, relative market share on the horizontal (your share divided by your largest competitor's share, so 1.0 means you're tied for the lead). Four quadrants fall out:

Stars — high growth, high relative share. Worth continued investment; they'll become cash cows as growth slows.
Cash cows — low growth, high relative share. Throw off more cash than they need; use that cash to fund stars and question marks.
Question marks — high growth, low relative share. Could become stars with investment, or could burn cash without ever gaining share. The genuinely hard call.
Dogs — low growth, low relative share. Henderson's original advice: divest or minimize investment.

The point of the exercise isn't the four labels — it's the capital allocation logic underneath them: fund growth with cash harvested from maturity, and don't spread investment evenly across a portfolio just because every product manager wants a bigger budget.

The assumption baked into every quadrant

Here's the part most write-ups skip: why does relative market share predict cash generation? Henderson's answer was the experience curve — the observation that unit costs fall by a fairly consistent percentage every time cumulative production doubles, because of learning effects, process improvement, and scale in purchasing and manufacturing. Under that logic, the company with the highest cumulative volume has the lowest unit cost, which means the highest margin at any given price, which means the most cash to reinvest or extract. Market share isn't valuable in itself in this model — it's a proxy for accumulated experience, which is a proxy for cost advantage.

That's a specific, falsifiable claim about how the business you're analyzing makes money. It was true, to a meaningful degree, for the industrial manufacturers BCG was advising in 1970. It is not automatically true for a SaaS company today.

Where software breaks the model

A few ways the experience-curve mechanism doesn't transfer cleanly:

Marginal cost is already near zero. Serving customer 10,001 doesn't cost meaningfully less per unit than customer 1,001 the way stamping out the ten-thousandth appliance does. Multi-tenant infrastructure means most of the cost curve flattened long before you had real market share.
R&D is amortized across the whole base, not driven by cumulative volume in the classic sense. A feature built once serves every customer identically; there's no per-unit learning curve inside the product the way there is on a factory floor.
Share often comes from network effects, distribution, and switching costs — not accumulated production experience. A category leader's advantage might be integration lock-in or a marketplace network effect, which behaves nothing like a manufacturing cost curve, even though it still shows up as "high relative share" on the chart.
Growth rate alone ignores retention economics. A market growing 5% a year with 95% net revenue retention can generate more durable cash than a market growing 25% a year with 70% gross retention and constant re-acquisition cost. The vertical axis, taken literally, treats both as equally attractive or unattractive based on growth alone.

None of this means the matrix is useless for software. It means the reason high share correlates with cash generation is different, and if you don't know your own reason, you're borrowing a conclusion without the argument that supports it.

Worked example (hypothetical)

Say you run a four-product portfolio. These numbers are illustrative, built to show the method, not researched:

Product A: market growing 4%/yr, your share is 2.1x the next competitor's → high share, low growth → cash cow.
Product B: market growing 22%/yr, your share is 1.8x the next competitor's → high share, high growth → star.
Product C: market growing 19%/yr, your share is 0.3x the leader's → low share, high growth → question mark.
Product D: market growing 3%/yr, your share is 0.4x the leader's → low share, low growth → dog.

Now the capital question, done honestly: assume Product A (the cow) runs at 80% gross margin on $2M ARR — $1.6M of gross profit available to redeploy. Product C (the question mark) needs an estimated $900K in incremental sales and product investment over the next year to have a real shot at doubling share. The cow alone can fund that bet with room left over — the arithmetic, not the quadrant label, is what justifies the reallocation. If Product A only threw off $600K of gross profit, the same "obviously fund the question mark" story wouldn't hold, no matter what quadrant it's sitting in.

Running it honestly in a SaaS portfolio

If you use this matrix, say what you're actually measuring on each axis, out loud, in the document. If "market share" for you really means "logo count in a market where switching cost is the moat," write that down — don't let the word "share" quietly import the experience-curve story. Consider weighting the growth axis by net revenue retention instead of using raw market growth alone; a slowing-growth market with 120% NRR behaves more like a cash cow than the raw chart would suggest.

What it can't tell you

The matrix won't tell you whether a "dog" is strategically load-bearing — sometimes a low-share, low-growth product is the reason your platform story holds together, or the reason a key enterprise account signed at all. It won't tell you the difference between a question mark that's about to inflect and one that's structurally capped. And it's not a substitute for a real unit-economics review of each product — it's a capital-allocation heuristic for people who've already done that review, not a replacement for doing it.