The transition from project to product is, at its core, a funding architecture change. Everything else — the operating model redesign, the OKR framework, the empowered teams — depends on solving the funding problem first. An organisation that declares itself 'product-led' while funding its teams through annual project budgets is not product-led. It is performing product leadership while operating a project management system.
This piece documents three funding model archetypes that have worked in practice — at airline scale, inside a UK government department, and within a major financial services group. Each carries different prerequisites, different failure modes, and different appropriate contexts. There is no universal answer. There is a set of conditions that, when matched to the right archetype, produces a funding architecture that actually supports product delivery.
Archetype 1: Annual Allocation + Lightweight Seed Funding
Teams receive a base annual allocation at the start of the financial year, sized against product portfolio scope and strategic priority tier. Within-year unplanned work goes through a lightweight seed funding mechanism — not the full annual planning process.
The seed mechanism is the critical design element. It must be fast (two-week maximum cycle), low-friction (a one-page business case, not a full benefits realisation model), and have genuine decision authority (not a recommendation to a committee that meets quarterly).
We implemented this at a major European airline. The annual allocation funded standing product teams. The seed mechanism handled emergent strategic priorities, compliance-driven urgent work, and opportunistic market responses. Demand approval cycle fell from six weeks to five days. The governance forum met fortnightly, reviewed seed requests in session, and issued written decisions by end of day.
Prerequisites: A functioning product team structure already in place; finance leadership willing to approve a parallel funding channel; a governance forum with genuine decision rights.
Failure mode: The seed mechanism gets captured by business-as-usual requests that should have been in the annual plan. Requires active management of the seed pipeline to prevent this.
Archetype 2: Outcome-Pooled Funding
Rather than funding teams, you fund outcomes — defined clusters of strategic value that may require multiple teams to deliver. Each outcome has a budget pool. Teams draw from the pool quarterly, justifying spend in terms of outcome progress rather than deliverable completion.
This archetype requires mature OKR practice. It breaks down immediately if OKRs are vanity metrics, because then the quarterly review becomes a rubber stamp. When OKRs are real — when they measure something that is genuinely hard to achieve and would be visibly absent if the team failed — the quarterly draw mechanism creates genuine accountability for outcome progress.
We implemented a version of this inside a UK government department. The outcome pools were aligned to the programme's public benefit commitments — specific, measurable improvements in service delivery. Teams requested quarterly draws by demonstrating progress against those commitments. The governance forum included both technology leadership and the senior responsible owner from the policy team who owned the benefit commitment. That combination eliminated the common disconnect between delivery progress and benefit realisation.
Prerequisites: OKR framework that measures genuine outcomes, not output proxies; cross-functional governance forum with both technology and business representation; quarterly cadence for draw reviews.
Failure mode: OKRs drift toward output metrics; the governance forum becomes a reporting meeting rather than a funding decision meeting.
Archetype 3: Discovery-Staged Funding
Funding is released in defined tranches tied to observable discovery milestones — not deliverable completion, but evidence-based decision points. A typical three-stage structure: Discovery (fund problem definition and user research), Alpha (fund prototype and testing), Beta (fund build and limited release). Each stage release requires documented evidence from the previous stage.
This archetype is most appropriate for genuinely novel product development — new market entry, a product category the organisation has not operated in before, or a technology approach with significant uncertainty. It is least appropriate for business-as-usual technology delivery where the solution space is known.
The critical design requirement is that the evidence standards for each stage gate are defined before the work starts, not negotiated retrospectively. 'We will release Alpha funding when the Discovery team has completed at least twelve user research sessions with representative users and documented a validated problem statement' is a defined evidence standard. 'We will release Alpha funding when leadership is satisfied with the Discovery outcomes' is not.
Prerequisites: Leadership tolerance for staged uncertainty; defined evidence standards agreed before work starts; a product discovery practice with the capability to produce stage-gate evidence.
Failure mode: Stage gates get waived under delivery pressure; evidence standards get renegotiated downward when teams cannot meet them; the model collapses back to waterfall delivery with a discovery vocabulary.
Choosing the Right Archetype
The right archetype depends on three variables: the maturity of your product practice, the risk tolerance of your finance function, and the stability of your strategic direction.
Annual Allocation + Seed works for organisations with an established product structure that need to retain financial control while gaining flexibility. Outcome Pooling works for organisations with strong OKR practice and genuine strategic alignment between technology and business leadership. Discovery Staging works for organisations building new capabilities where the solution space is genuinely uncertain.
Most large organisations need a portfolio of approaches — one archetype for their core product teams, another for innovation and new product development, and a third for compliance and regulatory work that does not fit the product model at all.
The mistake is choosing one archetype and applying it universally. The result is always the same: the archetype works well for the use cases it was designed for, and fails visibly for everything else, which generates the conclusion that the model does not work — when in fact the model was never designed to handle the full range of investment types in a large organisation.
Design your funding architecture to match the actual portfolio of investment types your organisation makes. Then staff the governance forums that manage it with people who have genuine decision authority, genuine accountability for outcomes, and the time to exercise both.