by Gary Worthington More Than Monkeys

From projects to products

In the first article I explained what a Product Operating Model is and how it differs from the traditional project model. The natural next question is: why are so many organisations making the shift?

The short answer is that the old ways are creaking under the weight of modern demands. Customers expect continuous improvement, not yearly releases. Technology evolves too quickly for five-year project roadmaps. Competitors can spin up new offerings faster than ever. The project model was designed for a different era.

The problem with projects

Projects promise predictability: fixed scope, fixed cost, fixed timeline. That looks tidy on a PowerPoint slide but rarely survives contact with reality. What you actually get is late delivery, features nobody uses, and teams that scatter the moment the project ends.

Gene Kim, Jez Humble, Patrick Debois, and John Willis made this point forcefully in The DevOps Handbook. They showed how project-based structures lead to endless handoffs, brittle releases, and an inability to learn quickly from customers. Their argument was that you need long-lived teams who own outcomes, not temporary groups who just ship outputs.

Gary Gruver in Leading the Transformation: Applying Agile and Devops Principles at Scale highlights the same problem. He describes how project funding and functional silos prevent organisations from achieving the fast feedback loops required for modern digital products.

The pull of the product model

A product model addresses these weaknesses by putting value, not activity, at the centre. That means:

• Long-lived teams with real accountability.
• Funding that sustains products over their lifecycle rather than cutting off at the end of a project.
• A focus on customer and business outcomes instead of delivery milestones.
• Governance that is lighter, faster, and linked to results.

Marty Cagan has been clear about why this matters. In INSPIRED and later in TRANSFORMED he explains that the most successful tech companies operate through empowered product teams, not project delivery units. His phrase “missionary not mercenary” sums up the difference. Missionary teams care about the problem and the outcome. Mercenary teams are just there to tick off requirements.

Matt Skelton and Manuel Pais, in Team Topologies, add another layer: even if you fund products and empower teams, you will fail unless you design your team structures to avoid dependency bottlenecks. Their work shows why interaction modes and cognitive load are critical for fast flow, and why product models collapse if you ignore the organisational plumbing.

Evidence from transformations

Large enterprises have published credible accounts of the shift. ING’s transformation into product-centred squads and tribes is well documented by McKinsey and Harvard Business Review, and reflected in ING’s own materials. These reports describe improvements in time to market, engagement, and productivity when long-lived teams own outcomes.

The business case

At its simplest, the business case is this:

• Projects optimise for predictability, not learning.
• Products optimise for outcomes and adaptability.
• In today’s markets, adaptability beats predictability.

That does not mean predictability has no place. It means you have to get there through empowered teams, continuous feedback, and outcome-driven governance rather than by freezing requirements upfront.

Where this series goes next

We’ve covered what a Product Operating Model is and why organisations are embracing it. In the next article we’ll dig into the anatomy of the model: the structures, practices, and cultural elements that make it work in practice.