By Richard Faint · 16 August 2026 · 4 min read

TL;DR

Product frameworks are useful because they simplify problems, expose assumptions and give people a common way to think. The danger starts when the model is mistaken for reality or it is turned into organisational dogma.

This series will look at frameworks through the actual work of product management

Discovery → Definition → Prioritisation → Delivery → Measurement → Strategy

Each article explores what a framework helps us see, what it hides, where it breaks, and how it behaves inside a complex system, using simulations and more than a occasional pop-culture reference.

The Framework Is Not the Product

Product management has no shortage of frameworks. RICE, Jobs to Be Done etc. Most are useful, none are reality. That distinction is what this series is about, I am not writing another set of articles that explains what each acronym means, and finishes with a diagram. What interests me is why these models work, what they help us see, what they hide, and what happens when they are applied to the complicated systems that real products inhabit.

That means starting with a defence of frameworks, because dismissing them in favour of judgement misses the point. Judgement is just another mental model, it is just an individuals collection of assumptions. Frameworks make some of these assumptions visible so they can be challenged. For those new to the role, that matters more. Frameworks are like stabilisers on a childs bike, they help new users do their job by assisting the analysis of ambiguous problems, identifying the important variables and learn how to structure their thinking. Over time, judgement improves and the rules become more malluable, but intuition is usually built on repeated exposure to models rather than appearing fully formed in a moment of enlightenment.

Models Matter Because Reality Is Too Complicated

A good model removes detail. The London Underground map is useful because it ignores everything happening above ground. Product frameworks work in the same way e.g. RICE strips prioritisation down to reach, impact, confidence and effort.

That reduction is valuable, but trouble begins when we mistake the map for the territory. Frameworks make complicated decisions easier to discuss and, in larger organisations, easier to compare across teams. That consistency is attractive to leadership because product work suddenly becomes legible: priorities have scores, objectives have measures and decisions fit neatly into common templates. The risk is that a useful model gradually becomes a security blanket, providing reassurance that complexity is under control simply because it has been converted into a standard format. At that point, the framework is no longer helping us understand reality; we are judging reality by how it fits the framework.

Why We Are Not Using Introduction, Growth, Maturity, Decline

The obvious way to organise this series is around the product lifecycle:

Introduction → Growth → Maturity → Decline.

Whilst useful it describes the position of a product in its market, not the work a product manager is doing. It is also linear, giving products a human arc: they are born, grow up, reach middle age and eventually shuffle off this the mortal coil. Real products are less cooperative.

A mature product can enter a new market and behave like a growth product again. A declining capability can receive investment and acquire another decade of useful life. One module can be mature while another is effectively a start-up living inside the same application. Technical platforms everyone expected to disappear can remain mission-critical for decades e.g. the USA benfits system is still running on Cobol.

For this series, I want to organise the frameworks around the work of product management

Discovery → Definition → Prioritisation → Delivery → Measurement → Strategy.

This is more useful for discussing practice, although it is a simplification because product work is not linear

The Framework Is Not the Decision

This series is not going to be an attack on frameworks they are invaluable when treated as models rather than recipes. They help us ask better questions, structure conversations and make assumptions visible. What they cannot do is absorb system variety on our behalf, nor should they relieve us of the burden of judgement.

The skill is not knowing the largest number of frameworks. It is recognising what sort of problem you are facing, choosing an appropriate model, and noticing when reality starts disagreeing with it.

That is what the rest of this series will explore - what each framework helps us see, what it hides, what assumptions it makes, where it breaks, and what happens when we put it back into the wider system it was designed to simplify. It will do this via simulations and pop culture referencs

Back to Articles