Outcome-Based Funding and Allocation

Part of our AI Driven Product Operating Model hub. Start there for the full map of guides, checklists and templates.

The easiest sign that an organization is still output-driven is its budget: annual project funding, dated feature lists and status reports on delivery. An outcome-based operating model changes how money and capacity flow.

Allocation versus funding

• Outcome-based allocation: Distributes resources across several outcome goals for the whole portfolio, then checks planned against actual allocation.
• Outcome-based funding: Releases resources to a single product or initiative over time, based on achieving agreed outcome milestones or metrics.

Portfolio-management vendors such as Dragonboat describe allocation as the foundation and funding as an extension of it, and say both need ongoing collaboration and good data.

What has to be true first

Cagan’s warning applies directly: moving to outcomes is a consequence of moving to the product model. Companies that layered OKRs onto output-based roadmap processes expected change and rarely got it. The OKR technique assumes teams that can discover solutions and choose how to deliver.

A practical sequence

OUTCOME BRIEF
Team / product:
Owner (accountable):

Problem to solve (customer and business):
Outcome metric:
  Baseline today:
  Target:
  By when:
Constraints (mandatory only; say why each exists):
Decision rights: the team chooses the solution. Escalate if:
Four risks to test in discovery
  Value (will they choose it?):
  Usability (can they use it?):
  Feasibility (can we build it?):
  Viability (does it work for the business?):
Evidence plan: what we will test first, and what would change our mind
Review cadence and date:

A worked example (illustrative numbers)

The numbers below are made up to show the mechanics. A product group sets four outcome goals, plans capacity for each, and compares plan with actual at each review.

Governance cadence

QUARTERLY OUTCOME REVIEW
1. Outcomes: target vs actual, per team (10 min each)
2. Evidence: what we learned from discovery, including ideas we stopped
3. Flow: cycle time, bottlenecks, release frequency
4. Allocation: planned vs actual capacity by outcome goal
5. Risks and bets: which bets paid off, which to drop or double
6. Constraints: which mandatory constraints slowed teams this quarter?
7. Decisions: reallocate, release more funding, pause or stop
Output: decisions and owners recorded; no status slides.

FUNDING RELEASE MEMO
Product / initiative:
Outcome goal it serves:
Funding released to date:
Milestone agreed for this tranche:
Evidence of progress (metric movement, learning, customer proof):
Remaining uncertainty:
Next tranche requested and milestone:
Decision: release / hold / reduce / stop
Rationale and decision owner:
Review date:

Funding, OKRs and roadmaps

Think of funding as the money rule, OKRs as the goal-statement technique and the roadmap as a view of outcomes over time. If any one of them is output-based, the others tend to follow it.

QUARTERLY BETS
Business objective(s) served:
Bet 1:
  Problem and outcome:
  Confidence today (low / medium / high) and why:
  What evidence would raise or lower confidence:
  Capacity allocated:
Bet 2: ...
Bet 3: ...
Portfolio of risk: how many bets are safe, medium, high risk?
Stop rules: what would make us stop early?
Review dates:

What McKinsey recommends on funding

In its operating-model research, McKinsey lists funding among five capability areas where top and bottom performers differ most. Its advice: give each product and platform team funding based on measurable goals, check that the goals can be tracked and line up with organizational priorities, and earmark funding but release it only against each team’s progress. Product Talk names executives funding outcomes or teams instead of projects during annual planning as a milestone of a working transformation.

Five pitfalls

1. Funding by outcome without discovery, which rewards optimistic claims.
2. Outcome metrics nobody can measure, so funding decisions turn into opinions.
3. Releasing or withholding money too quickly, so teams chase short-term metrics.
4. Ignoring cross-product work, so shared platforms starve.
5. Calling it outcome-based while still approving annual feature lists.

Why OKRs Fail on a Project Model

Many organizations adopted OKRs hoping teams would shift from shipping features to changing results. A few quarters later the objectives sit on slides, the key results read like a delivery plan, and teams still get a prioritized list from above. SVPG calls this the single most common problem when companies try to focus on outcomes: they assume they can move to outcomes without moving to the product model.

Why the template alone cannot work

Cagan’s point is about origin. The OKR technique grew out of the product model and assumes its conditions: empowered teams, discovery, a product strategy and instrumented products. Where those exist, the technique is straightforward. Where they don’t, OKRs get layered over an output-based roadmap process and nothing about how decisions get made changes.

Crisp’s writing on the product model adds a structural explanation. Organizations drift toward maximizing output because handover layers act as proxies: each layer measures its own deliverable, and the feedback loop to real customer results gets longer and weaker. Success means maximizing outcomes while minimizing outputs, which a goal-setting technique can’t do on its own.

Five failure patterns

Rewriting key results: three examples

Notice that the outcome version is harder to write, because it needs a baseline and a way to measure. That difficulty is the point. If the product can’t show whether the number moved, instrumentation comes before the OKR.

A healthier quarterly rhythm

1. Leaders set a small number of company objectives and the problems most worth solving, following the strategy.
2. Teams propose outcome-style key results they can influence, with baselines and instrumentation.
3. Teams run discovery on candidate solutions and bring evidence rather than feature lists.
4. Mid-quarter reviews look at outcome movement and what was learned, not delivery status.
5. At quarter end, leaders reallocate capacity and funding based on evidence, and teams reset.

How to tell it is working

Product Talk suggests watching for these signs: executives fund outcomes or teams rather than projects, outcomes take precedence over outputs day to day, stakeholders give input on solutions without dictating them, and the defined outcomes improve over time. If your OKR process does not produce those signs after a few quarters, look at the operating model, not the template. The product washing guide lists common causes.

Where OKRs fit with roadmaps and funding

Scrum.org’s APOM characterization points the same way. In the State of Play series, West says evidence starts in portfolio planning for cross-product initiatives with OKRs, then carries into how individual products are managed with Evidence-Based Management and flow metrics. OKRs are one input to an evidence loop, not the loop itself.

Related guides in this hub

• AI Driven Product Operating Model
• What Is the Product Operating Model?
• POM vs APOM compared
• POM in the AI era

Sources

Marty Cagan and Felipe Castro, "Outcomes Are Hard" (SVPG, March 17, 2025); Dragonboat, outcome-based allocation and funding guide; Crisp, "The Key Insight and Core Idea Powering the Product Model". Also: Marty Cagan and Felipe Castro, "Outcomes Are Hard" (SVPG, March 17, 2025); Crisp, "The Key Insight and Core Idea Powering the Product Model"; Scrum.org, "APOM State of Play, Part 1" (May 12, 2025). Examples are illustrative.

Further reading: Product Talk, "Funding Projects Vs. Teams" (Teresa Torres and Petra Wille podcast); Metis Strategy, "Developing a New Funding Model for Product-Based IT"; Thoughtworks, "Funding agility: Moving beyond project budgets"; Atlassian, "From output-funded projects to a living hybrid operating model" (whitepaper).