Three Product Teams
Source: https://cutlefish.substack.com/p/tbm-552-three-product-teams ↗
John Cutler's short piece distinguishing three kinds of product teams — delivery teams, product teams, and what he calls business-model / outcome teams — by the scope of what they are responsible for.
The distinction is useful because most organisations have one kind and assume they have another, and the resulting misalignment produces most of the friction around product teams.
For product direction it is a compact diagnostic.
Cutler's broader "Beautiful Mess" substack is one of the more consistently thoughtful places on the internet for product team design; read widely there.
Pair with Cagan's Empowered for the broader argument.
Central argument
Cutler argues that what organisations call 'product teams' are not all the same thing: he distinguishes delivery teams (responsible for output and execution), product teams (responsible for solving a defined problem or owning a capability), and business-model or outcome teams (responsible for a slice of the business including metrics and strategy). The central thesis is that most organisations operate delivery teams while believing — and claiming — they have empowered product teams, and that this gap in actual scope of ownership is the structural root cause of chronic friction between product, engineering, and the business.
Critique
The typology is compelling as a diagnostic frame but the essay does not adequately address how an organisation moves from one type to another — it describes the gap more than it closes it. A thoughtful reader might also push back on whether the three categories are sufficiently discrete in practice: many real teams sit in ambiguous intermediate states, and the framework's clean boundaries risk making a messy organisational reality look more tractable than it is. The essay also says little about what organisational conditions — budgeting cycles, governance, leadership maturity — need to change before a delivery team can credibly become an outcome team.
Why it matters for product
For a CPO, the immediate value of this piece is diagnostic: it gives a precise vocabulary to name why a team that nominally 'owns' a product area is still being treated as a feature factory — the team has the label but not the scope. This matters directly when designing team charters, negotiating OKRs, or deciding how to structure accountability conversations with the C-suite, because mismatches between declared and actual scope reliably produce the wrong incentives and the wrong metrics. Paired with Cagan's argument in Empowered, it sharpens the question from 'are our teams empowered?' to 'empowered to own what, exactly?'