From Projects to Products — The Operating Model Nobody Actually Changed
We are fluent in measuring the cost of an under-utilised person sitting in a team. We are almost entirely illiterate in measuring the cost of the context that walks out the door with the person who is moved.
The Rebrand
Walk into any large enterprise technology floor in 2017 and you will find squads, tribes, and product owners where there were once workstreams, programme boards, and business analysts. The vocabulary has shifted completely. The underlying machinery has not.
Over the past two years I have watched a pattern repeat itself across enough organisations to consider it a norm rather than an exception. A senior leadership team declares a shift to a product operating model. The org chart is redrawn. Teams are renamed. Roles are relabelled. Someone commissions a slide deck explaining that the organisation is now “product-led.” And within six months, every structural incentive that made those teams project-shaped reasserts itself — because nobody changed the structures.
The result is not a transitional state or a pragmatic hybrid. It is something considerably worse: an organisation that has lost the discipline of its old operating model without gaining the benefits of the new one.
What “Product” Actually Requires
The distinction between a project team and a product team is not cosmetic. It is structural, and the structures that differ are precisely the ones most organisations leave untouched when they make the switch.
A project team is temporary by design. It is assembled to deliver a defined scope, funded for that scope’s duration, and disbanded on completion. Its members return to a functional home — a resource pool, a centre of excellence, a line function — and are reassembled in different configurations for the next initiative. Accountability runs to the project board and, through it, to the portfolio. Success is measured against the baseline: on time, on budget, within scope.
A product team is persistent. It owns an outcome — a customer experience, a capability, a service — across its full lifecycle, not just its initial build. Its members are stable enough to accumulate deep context in the domain, the codebase, and the user behaviour. Accountability runs to the outcomes it produces: adoption, satisfaction, operational performance. Success is measured by whether the thing it owns is getting better.
These are not philosophical distinctions. They are operational ones, and they cascade through every layer of how work is organised, governed, and staffed.
The Structures That Did Not Move
The organisations I see attempting this shift have, almost without exception, changed the things that are easiest to change — team names, role titles, ceremony labels — while leaving intact the structures that would make the new model work. Four in particular stand out.
Governance remains project-shaped. The portfolio board still meets quarterly to approve business cases, allocate capital, and review stage gates. Each “product” must justify its next phase of investment through the same tollgate process designed for discrete projects — a process that assumes work has a beginning, a middle, and an end. A product team that needs to pivot based on what it has learned from its users has no governance mechanism to do so without re-entering the business case queue. The oversight model was built for certainty and sequential delivery; the product model requires it to accommodate learning and iteration.
Career paths remain functional. Engineers, designers, and analysts still belong to functional line management. Their performance is assessed by a functional head who may never see the product they work on. Promotion criteria reward technical depth and utilisation rate, not product outcomes or domain expertise. Consider the developer who spends six months learning a complex regulatory domain deeply enough to make genuinely good product decisions: in career terms, she is less visible than the developer who rotates across three high-profile delivery programmes in the same period. The incentive structure actively discourages the persistence that product ownership demands.
Team composition is still driven by resource allocation. The resource management function — whether it calls itself a PMO, a resource office, or a capability team — continues to treat people as deployable units. When a higher-priority initiative appears, the “product team” loses its most experienced engineer to a reallocation decision it had no say in. When a team member leaves, the replacement is whoever is available from the bench, not whoever has the right domain knowledge. The notion that a product team’s stability is itself a source of value — that the accumulated context in a persistent team is an asset, not a luxury — has not penetrated the resource model.
Accountability stops at delivery. The most telling structural failure is what happens after the first release. In a project model, the team delivers, the project closes, and a different group — operations, support, a maintenance team — inherits the result. In a product model, there is no handoff; the team that built it continues to own it, learn from its performance, and improve it. But the organisations I observe have not changed the post-delivery model. The “product team” builds the initial release and then, because approval was granted for delivery rather than for ongoing ownership, the team is either disbanded or redirected to the next build. The product is handed to a run-the-business function. Nobody owns the outcome. The feedback loop that is the entire rationale of the product model never forms.
The Worst of Both Worlds
What makes this pattern damaging — rather than merely incomplete — is that the partial adoption actively degrades performance. The organisation has not simply failed to achieve product-model benefits. It has also lost project-model discipline.
The old model, for all its rigidity, had a coherent logic. Scope was defined upfront. Timelines were baselined. Governance knew what it was tracking. Stage gates, however bureaucratic, forced clarity about progress and enforced decision points. The temporary nature of teams was a design feature, not a flaw — it allowed the portfolio to redeploy capacity towards the highest-priority work without sentiment.
The renamed model has dismantled that clarity without replacing it. Teams that call themselves product teams but operate without persistent membership or outcome accountability are left in a structural void. They cannot plan beyond the current approval cycle because their existence is not guaranteed past it. They cannot make genuine trade-off decisions because governance still expects scope adherence. They cannot invest in learning because their members may be reallocated next quarter. And they cannot point to outcomes because nobody measures them against any.
We have removed the scaffolding of the old model — the defined scope, the stage gates, the clear completion criteria — and replaced it with vocabulary. The vocabulary says “product.” The machinery says “project with no end date.”
What Would Actually Have to Change
The genuine shift to a product operating model is not primarily a team-design exercise. It is a governance and accountability exercise — and that is why so few organisations have made it.
It would require portfolio governance to move from approving business cases to allocating capacity to value streams — and then holding those value streams accountable for outcomes rather than for delivering against a predetermined plan. This is a fundamentally different governance posture: one that tolerates uncertainty about scope in exchange for clarity about objectives.
It would require career structures that reward domain depth and product impact, not rotation speed and utilisation rates. This means confronting how functional line management works — and whether the model of people “belonging to” a function and being “lent to” a delivery team is compatible with genuine product ownership.
It would require the organisation to stop treating team stability as an inefficiency to be optimised. Every time an individual is moved between teams for utilisation purposes, accumulated context is destroyed. We are fluent in measuring the cost of an under-utilised person sitting in a team. We are almost entirely illiterate in measuring the cost of the context that walks out the door with the person who is moved.
None of this is conceptually difficult. All of it is politically hard, because it challenges the authority of functional heads, portfolio boards, and resource management offices — the very people whose sponsorship any transformation programme depends upon.
The Honest Question
The pattern I have described is not a failure of understanding. The leaders I work alongside know, at an intellectual level, what a product operating model requires. They have read the same conference summaries, attended the same vendor presentations, and commissioned the same consultancy assessments. The operating model shift stalls not because the destination is unclear, but because the structural changes it demands redistribute authority in ways that the existing power structure will not readily accept.
A functional head who controls two hundred engineers wields considerable organisational power. A product model that embeds those engineers permanently into cross-functional teams does not merely change reporting lines; it dissolves the basis of that authority. A portfolio board that shifts from approving discrete investments to funding persistent teams loses its most tangible lever of control. These are not small concessions, and it is no mystery why they are resisted.
The honest question for any organisation that has declared a product operating model is not “how do we complete the transition?” It is whether the leadership is willing to change the things that actually need changing — or whether the relabelling was, in fact, the point.