by Gary Worthington More Than Monkeys

Why this term matters

I recently attended a panel discussion on transitioning to a product operating model, with Matt Skelton among the speakers. Hearing him talk about the challenges of moving from project to product inspired me to write down what I think on the subject. This article is the first in a short series where I’ll explain what the term means, why organisations are adopting it, and how it can be applied in practice, particularly for SMEs. A lot of it will sound familiar, but its always good to put some meat on the bones.

Over the last decade many organisations have been moving away from project-centric structures and towards what is often called a Product Operating Model. The phrase is used a lot in consulting slide decks, but often without clarity. At its core, it means building your organisation around enduring products, not short-lived projects.

In a project world, work is funded, staffed, and delivered in time-boxed chunks. Teams are spun up and disbanded. Success is judged on budget, scope, and timelines. In a product world, teams are long-lived, aligned to a product or product line, and measured on outcomes that matter to customers and the business.

This isn’t a new fad. Marty Cagan has been writing for years about the need for empowered product teams that continuously discover and deliver value. His book INSPIRED set the tone by contrasting mercenary feature teams with missionary product teams that are accountable for outcomes. In TRANSFORMED he goes further, describing what it takes for an organisation to move from project to product at scale.

Matt Skelton and Manuel Pais contributed a different piece of the puzzle with Team Topologies. They provide a vocabulary for shaping team boundaries and interaction modes so that product teams can work effectively without drowning in dependencies. Their work underpins many successful operating model transformations because it recognises that team design and cognitive load are just as important as funding models or governance.

A working definition

A Product Operating Model is a way of structuring your organisation so that value is delivered continuously through long-lived product teams. It redefines how teams are formed, how work is funded, how decisions are made, and how success is measured. The shift is from outputs to outcomes.

Put simply, projects deliver features where as products deliver value.

How it differs from the old way

How it differs from the old way

Team lifespan

• Project model: Short-lived, tied to a project
• Product operating model: Long-lived, aligned to a product

Funding

• Project model: Allocated per project
• Product operating model: Ongoing budgets per product line

Ownership

• Project model: Dispersed across functions with handovers
• Product operating model: Teams own discovery, delivery, and operation

Governance

• Project model: Heavy stage gates and steering committees
• Product operating model: Continuous, outcome-based checks

Metrics

• Project model: On-time, on-budget, feature count
• Product operating model: Customer and business outcomes

Product management

• Project model: Often squeezed between functions
• Product operating model: Central and empowered

Why project-centric models struggle

The pain points are familiar:

• Endless handoffs between functions.
• Incentives that reward delivery over value.
• Teams that disperse just as they become effective.
• Governance that slows decisions to a crawl.
• Products that stagnate after a project finishes because nobody is accountable for their ongoing success.

Cagan’s central point is that you cannot create successful products if you treat them as a series of projects. Teams need the mandate and continuity to solve real customer problems, not just to ship a requirements document.

Key elements of a Product Operating Model

A complete model usually contains several building blocks:

1. Product portfolio and strategy. Clear definitions of product lines, linked to business goals.
2. Long-lived product teams. Stream-aligned, cross-functional, and empowered.
3. Funding model. Budgets attached to products rather than projects.
4. Discovery and delivery practices. Continuous customer validation alongside incremental delivery.
5. Metrics. Outcomes such as retention, engagement, or cost efficiency rather than output measures.
6. Leadership and culture. Leaders set direction and guardrails while giving teams autonomy.
7. Supporting teams. Platform or enabling teams reduce cognitive load and let product teams focus on value, drawing directly on the Team Topologies model.

Common traps

Plenty of organisations claim to have adopted a Product Operating Model when they have only relabelled the old way of working. Watch out for:

• Simply renaming projects as products.
• Starving product teams of authority.
• Adding layers of governance rather than removing them.
• Treating discovery as optional.
• Measuring velocity instead of value.

The model is not about giving teams free rein. It is about creating the right balance of autonomy and alignment so that teams can deliver outcomes that matter.

Where this series goes next

This article sets out what a Product Operating Model is and why the term matters. In the next part we will look at why organisations are making the shift and what evidence exists that the model delivers real benefits.