The single most common reason an operating model transformation fails is not the operating model itself. It is the funding architecture that sits underneath it. You can design a beautiful product-based structure — clear product lines, empowered teams, OKR hierarchies that connect team-level work to board-level strategy — and then watch it collapse the moment someone tries to raise a funding request and finds that the finance system still only understands annual project budgets.
This is not a new observation. McKinsey, BCG, and every major technology advisory firm has published something about the project-to-product shift. The problem is that publishing a framework is not the same as funding it, operationalising it, and holding a governance forum through its first live cycle.
The Structural Incompatibility
Annual project budgets and iterative product delivery are structurally incompatible. Here is why. A project budget is tied to a scope, a timeline, and a set of deliverables. When you fund a product team iteratively — as you must if you want to retain the ability to pivot based on evidence — there is no fixed scope. There is a product vision, a roadmap, and a discovery cadence. None of those map neatly onto an annual Capex/Opex classification that finance needs before it will approve anything.
The result is typically one of three things:
- The product team works under a project wrapper, which means it cannot actually behave like a product team because it has fixed outputs and fixed timelines
- The product team loses funding mid-year because it cannot demonstrate committed deliverables at the frequency the finance cycle demands
- The transformation programme gets stuck in a holding pattern while finance and technology try to agree on a classification framework that neither of them fully controls
Three Funding Model Archetypes That Work
In our work across airlines, government departments, and financial services organisations, we have seen three funding model archetypes that actually work in practice. Each requires different conditions to succeed.
1. Annual + Seed Funding
This is the most common model we implement for large enterprises. Teams receive an annual allocation at the start of the financial year, sized against their product portfolio and strategic priority. Within-year requests for unplanned work go through a lightweight seed funding mechanism — typically a governance forum with a two-week turnaround, not a six-week Capex committee.
The critical design requirement: the seed funding process must be demonstrably faster than the annual planning process, or teams will route everything through annual planning and the model collapses.
We implemented this model for a major European airline. Demand approval cycle time fell from six weeks to approximately five days. The governance forum met fortnightly and approved or declined in session, with written rationale. Teams could plan with confidence.
2. Outcome-Linked Budget Pools
Rather than funding teams, you fund outcomes — defined OKR clusters that span multiple product teams. Each outcome has a budget pool. Teams draw from the pool on a quarterly basis, justifying spend in terms of progress against the outcome, not completion of deliverables.
This model works best in organisations that already have mature OKR practice. It breaks down when OKRs are vanity metrics, because then the quarterly review becomes a rubber stamp rather than a genuine funding decision.
3. Milestone-Gated Iterative Funding
Funding is released in tranches tied to defined milestones — not deliverables in the traditional sense, but observable outcomes: a user research programme completed, a prototype tested with real users, a pilot delivered and metrics baselined. Each milestone releases the next tranche.
This is the most appropriate model for genuinely new product development where strategic direction is uncertain. It is the hardest to implement because it requires finance, technology, and product leadership to agree on what constitutes a milestone before the work starts — and to resist the temptation to convert milestones back into deliverables when they become uncomfortable.
What It Costs to Get Wrong
The cost of getting the funding model wrong is not just a delayed transformation. It is a cynical workforce. When a technology organisation announces a product operating model and then funds it like a project organisation, the people doing the work learn immediately that the transformation is performative. They adapt by speaking the new language — product, OKR, empowerment — while continuing to work exactly as they did before. The metrics look better because the vocabulary changed. Nothing else did.
Reversing that cynicism is significantly harder than designing the right model from the start. It requires visible leadership commitment, at least one demonstrable example of the new model producing a better outcome than the old model would have, and patience that most programmes do not have by the time they realise the problem.
If you are designing or reviewing an operating model transformation, start with the funding architecture. Not the org chart, not the OKR framework, not the governance forums. The funding model. Everything else depends on it.