The Operating Model Is Where Transformation Actually Happens

Most transformation stories are told at the level of vision. A new strategy, a bold goal, a big technology bet. Those make for good announcements, but they are not where transformation succeeds or fails. It succeeds or fails one level down, in something almost nobody puts on a slide: the operating model. How the organization is actually built to deliver value. Change the vision without changing the operating model, and you get a louder version of the same results, which is the most common transformation outcome there is.

I find this is the least glamorous and most decisive part of the work, and I've spent enough time inside it to be convinced that the operating model is where the real leverage lives.

What an operating model is, and why they differ

An operating model is the arrangement of people, structure, funding, and process that turns intent into delivered value. Every organization has one, whether or not it ever named it. The question is only whether it was designed or merely inherited.

They differ in real ways, and the differences have consequences. A project-based model funds a defined scope, assembles a team to deliver it, and disbands when it ships; it's good at one-time delivery and bad at sustaining anything afterward. A functional or siloed model organizes people by department and passes work across the walls between them; it builds deep specialization and deep handoff problems in equal measure. A service or matrixed model shares people across competing demands; it's flexible and perpetually contested. And a product operating model organizes durable teams around products and the outcomes they produce, funding them to sustain and improve those products over time rather than to complete a scope and leave.

None of these is universally right. Each optimizes for something and pays for it somewhere else. But the choice is not cosmetic, because the operating model quietly determines what the organization is capable of, regardless of what its strategy says it wants.

The shift I know best

The transformation I know most intimately was a move from the project-and-silo world to a product operating model, and living through it taught me more about why this matters than any framework could.

The old model was project-based, with work organized in departmental silos. It functioned the way that world usually does: initiatives were chartered, funded as projects, handed across functional boundaries, delivered, and then orphaned, because no durable team owned what happened next. It wasn't incompetence. It was the predictable behavior of a particular operating model, and the people in it were doing exactly what the structure rewarded.

The shift to a product operating model changed the unit of everything. Funding moved from projects to products. Teams became durable rather than temporary. Ownership shifted from "deliver this scope and disband" to "sustain and improve this product and the outcomes it drives." Accountability moved from output to outcome. I'm describing the structural shape of that change rather than the internal machinery, but the shape alone tells you why it's hard: you are not adding a process, you are changing what the organization is built to do.

Why so many familiar ideas actually start here

Something worth noticing, because it reframes a lot of the current conversation: many of the concepts people treat as standalone initiatives are actually consequences of the operating model.

Take products versus projects, or outcomes versus outputs. These get taught as mindsets, as if a team could simply choose to think in outcomes. But the reason a project-based organization fixates on outputs is that its operating model funds and measures projects by delivery, so output is what the structure can see. Tell those teams to care about outcomes while leaving the operating model untouched, and you've asked them to fight their own incentives. The outcome orientation isn't a mindset you install on top of the model. It's a property that emerges when you change the model underneath. That's why I think of the operating model as the source of these distinctions rather than another item beside them: change how the organization is built to deliver, and the products-not-projects and outcomes-not-outputs shifts follow as consequences instead of slogans.

The same is true of ways of working. Agile, Scrum, scaling frameworks: these are how a product operating model expresses itself at the team level. Adopt the ceremonies without the model and you get the appearance of agility riding on a project-based skeleton, which is exactly the hollow version so many organizations end up with. The operating model is what makes the ways of working coherent rather than performed.

Where the enterprise value leaks out

The clearest way to see what a project-and-silo model costs is to follow the money. When initiatives are chartered separately inside departments, each one builds its own business case, and those cases routinely claim overlapping benefit. Three projects each promise to lift the same revenue, reduce the same cost, or win back the same customer, and nobody is positioned to notice that the enterprise has now booked the same dollar three times. If you actually tried to measure the realized impact against the sum of the promises, the gap would be enormous, because the benefits were double-counted at the point of approval. This isn't dishonesty. It's the predictable result of a model where no one is required to reconcile value claims across silos. The structure permits the double-dip, so the double-dip happens.

The mirror image is just as costly. When a single department pushes an initiative on its own, it forfeits the synergy of the whole enterprise standing behind it. The initiative that needed sales, operations, and marketing aligned behind one outcome instead gets one function pushing and the others indifferent, and it underdelivers for reasons that have nothing to do with the idea and everything to do with the isolation.

A cross-functional, enterprise-wide product approach is what closes both leaks. It aligns departments, strategies, and business cases around shared outcomes rather than competing claims. And at its best it goes a step further, to a portfolio view: when a corporate strategic priority lands, the question stops being "what can this one product do for it" and becomes "how does our whole ecosystem of products deliver this together." That shift, from the contribution of a single product to the coordinated contribution of the portfolio, is where enterprise value and return on invested capital actually compound, because the enterprise finally stops working at cross-purposes with itself.

The AI parallel, in both directions

This connects directly to the harder problem of the moment. Digital and AI initiatives benefit enormously from a product operating model, for the same reason any sustained value does: durable teams that own outcomes will keep improving an AI system long after the launch, where a project team would have delivered it and dispersed. If you want AI that compounds rather than stalls, the operating model is part of the answer.

And the influence runs the other way too. AI is becoming infrastructure rather than a feature, and that's beginning to pressure the operating model itself, changing how teams are shaped, how work flows, and what "done" even means when the product keeps learning. The operating model is not a thing you set once. It's a living arrangement that the next wave of technology will keep forcing you to revisit.

Product is not the summit, but it's the right base camp

It's worth being honest that the product operating model is not the end state. The most advanced organizations organize at a higher level still, around capabilities rather than individual products, coordinating what the whole enterprise can do rather than what each product team ships. That's the frontier, and I don't want to pretend product is the final word.

But you get there by climbing, not by leaping. An organization mired in project-and-silo work that tries to vault straight to a capabilities model will fail, because it hasn't built the muscles the higher model assumes. The path runs project to product to capability, in that order, and the reason is the same discipline that underwrites good delivery: change is better tackled in small chunks than all at once. Make the smallest move that delivers real value, measure what happened, learn, adapt, and grow from there. That's an Agile tenet applied to the organization itself, and it's how you mitigate the risk of a large change, by making it a sequence of smaller ones. Perfect is the enemy of good here as everywhere. The organizations that get to the frontier are the ones that started somewhere honest and kept moving, not the ones that waited to design the perfect model before taking the first step.

The part companies underestimate

Here is what I'd most want a leader contemplating this to hear: changing an operating model is harder than almost anyone expects, because it is fundamentally a change to how people work, relate, and are measured, and people do not reorganize their professional lives on a project timeline.

Most transformations budget for the technology and the process and quietly assume the human change is free. It isn't. It's the most expensive part, and the one most likely to be underfunded. Durable teams have to form real identity. People whose worth was defined by their function have to find it in a product instead. Managers have to give up control they're used to holding. Incentives have to be rebuilt so that outcome ownership is actually rewarded rather than merely encouraged. None of that happens because a new model was announced. It happens slowly, through sustained leadership attention, and it stalls the moment that attention wanders.

Change is hard in the specific way that matters here: the structure can be redrawn in a quarter, but the human reality of the new model takes far longer to become real, and an organization that declares victory at the reorg has usually mistaken the easy half for the whole. The operating model is where transformation actually happens, and it happens at the speed people change, which is slower than any of us would like and exactly as slow as it has always been.