Product operating model

A product operating model is how a company arranges itself to build products: which teams are funded, who decides what, and what each team is held to. It funds durable teams rather than projects, and it names who owns the roadmap.

Operating model design is the parent exercise and covers the whole business. This page is the narrow case inside it: how product work specifically is funded, staffed and decided.

It is not an org chart and it is not an agile method. Structure says who reports to whom and a method says how a team works; an operating model says who may choose what the team works on at all.

Key takeaways

• A product operating model answers three questions: who is funded, who decides, and what the team is held to.
• Durable teams funded as standing capacity behave differently from squads built and disbanded per project.
• Decision rights are the part everyone skips — and the part that actually changes behaviour.
• Judge the model by outcomes moved, not by features delivered on a date.

How it works

A product operating model sets four things: how product work is funded, how teams are formed and kept, who holds the roadmap, and which measure counts as success. Change any one and the other three move with it.

Funding is the lever with the longest reach. Fund teams rather than projects and the annual argument shifts from which proposals get money to which teams deserve more of it, which is a far shorter conversation.

Measures follow the money. A model that funds teams but still reports progress as features delivered has changed its budget lines and nothing else, because people optimise for whatever the monthly review asks about.

Decision rights deserve writing down: who proposes, who approves, and who can say no without escalating it to a committee that meets next month.

The product manager role only works where the model grants it real authority. Hand someone the title but keep the roadmap in a steering committee — and you have a project coordinator with a new business card.

An agile transformation changes how teams work week to week. It will not survive a funding model that still pays for scoped projects, which is why so many of them quietly revert.

Scaling brings its own shapes. An agile release train coordinates many teams around one cadence, and it is a delivery mechanism rather than an operating model, though the two are regularly mistaken for each other.

The model carries the strategy or buries it. A digital product strategy names which products matter and where the company is betting — the operating model decides whether anyone is funded to act on it.

Public administration writes the accountability down. Title 44 of the US Code makes each agency program official responsible and accountable for the information resources supporting their programs, defining needs alongside the chief information officer.

The same instinct runs through the United States government’s Digital Services Playbook, whose sixth play is to assign one leader and hold that person accountable for the service being built.

Examples

The shift shows up the same way in very different places. Watch the funding line rather than the team names, because the funding line is the part that is hard to fake.

Retail banks move money before they move people. A bank that funds standing teams for payments, onboarding and servicing stops writing a business case for every release, and its investment committee argues about outcomes instead of scope.

Public bodies run the same play. A digital service with one named leader, a budget that lasts beyond the build and a small permanent team tends to outlive the minister who announced it, which is rather the point.

Retailers feel it at the edges. A chain funding a standing team for checkout and another for fulfilment stops shipping a seasonal project nobody owns, and starts holding two named teams to conversion and delivery times.

Outsourced delivery can fit the model or fight it. A provider in Manila or Krakow staffing a durable squad against a standing scope behaves like part of the team — the same people billed per project revert to taking tickets.

Related terms

• Digital operating model: the whole business version of the same idea, covering channels, data and process.
• Continuous delivery strategy: the release practice a product model depends on to ship small and often.
• Operating model design: the method for producing any operating model; this page is its product chapter.
• Product manager: the role that holds the roadmap once the model gives it authority.
• Agile transformation: the way of working that a project funding model will quietly defeat.

FAQ

What is a product operating model?

It is the arrangement a company uses to build products: how teams are funded and formed, who holds the roadmap, and what counts as success. It describes decision rights, not reporting lines.

How does it differ from organisational design?

Organisational design sets the structure, including units, reporting lines and spans of control. A product operating model sits inside that structure and governs how product work is funded, decided and judged.

What changes first when you adopt one?

Funding. Move from paying for projects to paying for teams and almost everything else follows, because the old approval ritual stops making sense.

Does this require agile?

No, though most models that work use short cycles and frequent release. The important shift is from scoped output to measured outcome, and a team can reach that from several ways of working.

How do outsourced teams fit a product operating model?

They fit well where a provider staffs a durable squad against a standing scope. Billing the same people against a project keeps the old behaviour in place, whatever the contract calls them.

See how providers staff durable product teams across Outsource Accelerator.