Project-to-Product Isn't a Reorg. It's an Operating Model.

The renaming trap

I have walked into more "project-to-product" transformations than I can count, and almost all of them begin the same way: a renaming exercise. Project managers become "product owners." Teams become "squads." The org chart gets a fresh coat of Agile paint, a new wiki is stood up, and leadership declares the shift done. Six months later I go back and the funding model is unchanged, the governance gates are unchanged, and the success measures (on-time, on-budget, scope delivered) are unchanged. Nothing about behaviour has changed, because nothing structural has changed.

The lesson I keep relearning is that the shift from project to product is not lexical. It is structural. A project is a temporary team assembled to deliver a defined output and then disband. A product is a persistent team that owns an outcome across a lifecycle. Those are two different operating systems, and you cannot run one with the other's operating model. Calling it "product" while still funding "projects" produces the worst of both worlds: persistent teams carrying temporary mandates, with no clear owner of the outcome once the project logic expires.

Why the renaming keeps happening

I think the renaming trap survives because it is easy and the alternative is hard. Renaming is a deck, a rebrand, and a re-org diagram, all things a transformation function can produce in a quarter. The four structural shifts below take years, they threaten established power, and they touch money. So organisations do the cheap part and skip the expensive part, and then are surprised when the culture survey says nothing changed.

Mik Kersten makes the point directly in Project to Product: the gap between what technology organisations produce and what the business actually needs is a flow problem, not a naming problem, and flow is governed by the funding and team structures, not by titles.¹ Matthew Skelton and Manuel Pais make the complementary point in Team Topologies: team cognitive load is the real constraint, and the only way to reduce it at scale is to design team types around the flow of value.² Marty Cagan, in Transformed, frames the same shift as the difference between a "feature team" that ships output and a "product team" that owns outcomes.³ All three are describing the same structural reality. None of them are describing a renaming.

The four shifts

When I assess whether an organisation has actually moved to product, I look for four concrete changes to the operating model. If any one is missing, the others will drift back to project logic within a year.

1. Funding. Stop funding projects; fund value streams. Money attaches to an outcome and a long-lived team, not to a bounded scope with a fixed end date. This is the shift most organisations skip, because it touches Finance and the annual cycle, and it is the one that matters most. Kersten's Flow Framework makes the case: fund the flow, not the feature, because flow is what carries value to the customer.¹
2. Teams. Replace project teams assembled per initiative with stable, cross-functional teams aligned to a product or value stream. Team Topologies calls these stream-aligned teams, supported by platform, enabling, and complicated-subsystem teams.² The point is not the taxonomy; the point is that teams persist and own cognitive load over time, rather than being spun up and torn down around each initiative.
3. Governance. Replace stage-gates that approve outputs with cadence-based reviews that inspect outcomes, flow, and fitness for purpose. A gate that approves a scope and a budget is a project artefact. A review that asks "did flow improve, did the outcome move, is the team fit for purpose" is a product artefact. Same people, different question.
4. Success measures. Replace on-time / on-budget with outcome and flow metrics, the Flow Framework's time-to-value, throughput, efficiency, and reliability.¹ If the board still asks "are we on budget," you are still running a project model. If the board asks "is time-to-value falling," you are running a product model.

The funding shift is the one nobody wants to make

In my experience the funding shift is where transformations die. It is politically easier to restructure teams and rebrand roles than to tell Finance that the annual project budget cycle is the thing we are trying to fix. But the annual project budget is exactly the thing we are trying to fix, because it forces the organisation to commit, in advance, to scope it cannot yet see in a market it cannot yet read, and then to defend that commitment for the rest of the year.

I have seen this play out at scale. In one portfolio I ran, more than 60% of funded initiatives still had their original scope and budget at the twelve-month mark, even where the market they were built for had materially shifted. The governance apparatus spent the year protecting the estimate instead of protecting the outcome. That is not a governance failure; that is the funding model doing exactly what it was designed to do. The fix is not better governance of project budgets; it is a different funding model.

Why it matters

A project organisation optimises for the predictable delivery of a defined scope. A product organisation optimises for sustained outcomes in an uncertain market. They are not the same system. You cannot run one with the other's operating model, and most "transformations" fail because they try.

When I advise an executive on whether their organisation has actually shifted, I ask one question: if the strategy changed tomorrow, how long before the funding moved? If the answer is "next budget cycle," the organisation is still a project organisation, whatever the deck says. If the answer is "next cadence review," it has begun the shift. The operating model is the strategy. Everything else is decoration.

The operating model is the strategy. Everything else is decoration.

Start with funding and governance. If those two don't change, the rest is theatre, and I have watched enough theatre to know.

¹ Mik Kersten, Project to Product (IT Revolution, 2018). ² Matthew Skelton & Manuel Pais, Team Topologies (IT Revolution, 2019). ³ Marty Cagan, Transformed (Wiley, 2024).