This resource extends Chapter 6 (Funding Products Over Projects) and Chapter 15 Commitment 3 (Consumption-Speed Finance) of Evolve: The Operating Model AI Demands (Hodgson, 2026) to address cloud and AI spend governance at team level. Appendix B of Evolve lists this page as part of the investment governance set. It assumes familiarity with the book’s argument and provides the governance mechanics for direct application.
In Brief
- Token and compute costs are consumption costs, not capital costs — stage-gate instruments create the appearance of control while spend accumulates at the speed of API calls.
- Consumption-speed finance (Ch 15 Commitment 3) places financial delegation at the point of consumption: the Product Owner governs spend within the Sprint boundary.
- Expenditure is reported against the Key Value Area that fits the product’s lifecycle stage, not against a scoped deliverable.
- One threshold set governs all escalation levels: defined once, applied consistently across daily alerts, cumulative escalation, and the worked example.
- Portfolio visibility comes from structured escalation out of team-level governance, not from centralised approval of every allocation.
Token and compute costs are consumption costs. That distinction is structural, not semantic, and it is the distinction that motivates the governance design in Chapter 6 of Evolve (Hodgson, 2026).
Stage-gate approval processes were designed for capital investment events: a named project owner takes accountability for the investment, a budget is authorised up front, and phase gates determine whether each tranche is released. Consumption costs do not behave this way. They are continuous, incremental, and distributed across thousands of micro-transactions executing at the speed of API calls — fractions of a cent per Large Language Model (LLM) inference, accumulating across every conversation, document, query, and batch process the team runs. Governance cycles designed around approval events cannot surface these costs in time to act on them (Hodgson, 2026, Ch. 6).
By the time the monthly invoice arrives, the Sprints have closed and the team has moved on. The connection between that consumption and the outcomes it funded is gone. An organisation that continues to treat AI platform cost as an undifferentiated shared-services budget line will find that cost has outrun its governance. Not because spending is excessive, but because nobody at the point of consumption is accountable for connecting that expenditure to the outcome it was supposed to produce (Hodgson, 2026, Ch. 15).
Stage-gate instruments create governance latency for cloud and AI consumption costs
The FinOps Foundation (2024) describes the governance response. FinOps is “an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams” (FinOps Foundation, 2024). Its principle that “everyone takes ownership for their technology usage” requires that the people making consumption decisions hold both the authority and the information to govern them (FinOps Foundation, 2024). A stage-gate instrument operating above the team does not achieve that. It creates approval latency and accountability distance simultaneously.
Chapter 15 Commitment 3 of Evolve names this the consumption-speed finance commitment: the financial governance design that matches the speed at which consumption decisions are made (Hodgson, 2026, Ch. 15).
Financial delegation must sit at the level where consumption decisions are made. Evidence produced at each level must be visible to the level above it. Expenditure is reported against value produced, not against scope delivered. These three conditions distinguish a consumption-speed governance structure from a project approval instrument applied to a consumption cost.
The FinOps Crawl/Walk/Run maturity model describes the organisational path. It “enables organizations to start small, and grow in scale, scope, and complexity” (FinOps Foundation, 2024). For most organisations, the Crawl stage establishes centralised cost visibility: tagging every AI inference and cloud compute cost to the product team that incurred it, and making daily spend visible to the Product Owner within one working day of accrual. The Walk stage delegates the daily alert threshold to the Product Owner. The Run stage implements the full three-level delegation structure described below.
Consumption-speed finance places delegation at the point of consumption
FinOps governance only functions on top of a product accountability structure. A business-as-usual operations team inheriting AI platform spend as an undifferentiated budget line is not the accountability structure FinOps requires underneath it (Hodgson, 2026, Ch. 6).
The delegation ladder operates at three levels, each defined by the scope of the decision (Hodgson, 2026, Ch. 15).
At the Sprint level, the Product Owner holds spending authority. This is where consumption-speed decisions are made: model selection, inference volume, batch processing scope. Daily cost visibility is the Product Owner’s accountability. When daily spend exceeds the defined alert threshold, the Product Owner logs the cause and determines whether the spend was proportionate to the Sprint Goal.
At the product level, the Product Manager holds authority within the product’s investment envelope. When cumulative Sprint spend exceeds the escalation threshold, the Product Manager reviews the pattern: is the consumption aligned with the product’s lifecycle stage, the investment hypothesis, and the Key Value Area (KVA) the portfolio review is tracking? The Product Manager may reallocate capacity within the investment envelope without executive approval.
Financial delegation must match the level of the consumption decision
Portfolio-level reallocation sits with the executive. The quarterly portfolio review assesses whether each product’s investment envelope is calibrated to its lifecycle stage and Evidence-Based Management (EBM) evidence (Scrum.org, 2024). An executive who withholds delegation authority to control consumption costs will find that approval latency becomes the binding constraint on the team’s throughput — and the cost of that latency, measured in delayed outcomes, exceeds the cost of the consumption it was designed to contain (Hodgson, 2026, Ch. 15).
Chapter 15 of Evolve maps each product lifecycle stage to the Key Value Area the portfolio review needs to assess (Hodgson, 2026, Ch. 15). The four KVAs — Current Value, Unrealised Value, Ability to Innovate, and Time to Market — are defined in the EBM Guide (Scrum.org, 2024).
The cost question shifts from “Are we on budget?” to “Is the spend proportionate to the value the evidence is showing?” A product in Growth stage reporting its AI inference spend against a scoped deliverable is answering the wrong question. The portfolio review cannot assess whether the investment is working. The same spend reported against Current Value evidence — adoption rates, customer outcomes, the investment hypothesis threshold — gives the executive a basis for a genuine funding decision.
| Lifecycle stage | KVA for expenditure reporting | The cost question |
|---|---|---|
| Introduction | Time to Market + Ability to Innovate | Is spend producing learning at the rate that validates or invalidates the hypothesis? |
| Growth | Current Value | Is spend proportionate to adoption growth and the current value threshold in the investment hypothesis? |
| Maturity | Unrealised Value | Does spend still justify development investment, or should funding be redirected? |
| Decline | Migration cost | What is the cost of migrating customers to the successor product? |
Expenditure reported against lifecycle stage answers the portfolio’s investment question
A product consuming funds while delivering declining value is visible in this reporting structure. In project accounting, it is invisible: the project is closed, deliverables are signed off, and nobody is accountable for whether the investment continues to produce what it was funded to produce (Hodgson, 2026, Ch. 15).
A single threshold set governs all levels of the framework. Define it once; apply it consistently across all sections and the worked example.
- Daily alert: daily spend exceeds 15% of the Sprint budget → Product Owner notified; cause logged in the Sprint log. No escalation at this level — logging and investigation only.
- Cumulative escalation: cumulative spend reaches 60% of the Sprint budget before the end of day 5 → Product Manager review triggered. The Product Manager examines the cause and determines whether to reallocate within the investment envelope.
- Portfolio alert: Sprint closes more than 10% over the Sprint budget → raised at the next executive portfolio review.
A threshold set to “an appropriate level for your context” is not a threshold — it is a deferred decision. Chapter 15 of Evolve is explicit: the team has delegated authority within a defined boundary, and a boundary requires a line (Hodgson, 2026, Ch. 15). Organisations implementing this framework should calibrate the 15% daily threshold and 60% cumulative threshold to their own Sprint budgets before the first Sprint begins; the numbers above are starting-point defaults, not recommendations to accept without testing against your actual consumption patterns.
Worked example: Growth stage team
An AI-augmented product team is in Growth stage, reporting spend against the Current Value KVA. Sprint budget: $1,000. The threshold set above applies throughout.
Daily target: $100 (Sprint budget ÷ 10 working days).
Daily alert threshold: $150 (15% of $1,000).
Cumulative escalation threshold: $600 (60% of $1,000) before end of day 5.
One threshold set governs every level of the delegation structure
| Day | Daily spend | Cumulative spend | Alert status |
|---|---|---|---|
| 1 | $80 | $80 (8%) | No alert |
| 2 | $90 | $170 (17%) | No alert |
| 3 | $100 | $270 (27%) | No alert |
| 4 | $180 | $450 (45%) | Daily alert: $180 exceeds $150 threshold → Product Owner logs cause: complex multi-step reasoning task run at premium model tier |
| 5 | $200 | $650 (65%) | Cumulative escalation: $650 exceeds $600 threshold → Product Manager review triggered |
Product Manager review (end of day 5): cumulative spend is $650 (65% of Sprint budget) with five working days remaining. The Product Manager examines the cause: the day-4 premium model use was justified for that task’s complexity, but running standard tasks at the same model tier for the remainder of the Sprint will exhaust the budget. The Product Manager directs standard tasks to revert to a standard model tier for Sprint days 6–10, reducing expected daily spend to approximately $60–70.
Sprint days 6–10: $70 average daily spend × 5 days = $350.
Sprint close: total spend $1,000 — on budget. The Sprint Review reports $1,000 against the Growth stage Current Value KVA. Evidence: two new customer onboarding flows deployed; Current Value adoption metric 12% above the prior Sprint baseline, tracking toward the investment hypothesis threshold.
The arithmetic is consistent because one threshold set governed every decision. The day-4 daily alert did not contradict a different threshold in the escalation section. The day-5 cumulative figure correctly triggered escalation because $650 > $600. No escalation arose at day 4 — the daily alert triggered a log entry and cause investigation, not a Product Manager review. The distinction matters: conflating alert-level and escalation-level responses produces either under-governance (ignoring cumulative patterns) or over-escalation (Product Manager involved in every daily variance).
The Sprint Review is the financial accountability artefact the portfolio review needs
The Sprint Review surfaces both what the team produced and what it cost. Without cost visibility at the decision level, the review shows output evidence without expenditure evidence, and inspection is incomplete (Hodgson, 2026, Ch. 15).
A Growth stage product Sprint Review includes:
- Sprint budget and actual spend, reported against the Current Value KVA
- Cause of any daily alerts, logged during the Sprint and available at review
- Whether the investment hypothesis threshold is being tracked
- Any Product Manager escalations: what triggered them, what was decided, and the outcome
- Whether the Sprint budget needs recalibration for the next Sprint based on what this Sprint’s consumption pattern revealed
This is not a cost report. It is the financial accountability artefact the portfolio review needs to assess whether the product’s investment envelope is calibrated to the evidence. An executive who only receives confirmation that spend was within budget has been given a project answer to a product question.
What this means for senior leaders
- Financial delegation to the Product Owner is the governance structure FinOps requires — a stage-gate instrument above the team creates approval latency and accountability distance simultaneously, while the consumption decisions that determine spend are made at the Sprint level.
- Reporting expenditure against Key Value Areas rather than scoped deliverables gives the portfolio review a basis for genuine funding decisions; reporting against a deliverable answers a project question that no longer applies once the product is live.
- One threshold set defined before the Sprint begins is the boundary that makes delegation workable — a threshold deferred to “an appropriate level for your context” is not a governance structure, it is a deferred decision.
- Portfolio visibility emerges from structured escalation out of team-level governance; an executive who withholds delegation to control consumption costs will find that approval latency becomes the binding constraint on throughput, and the cost of that latency exceeds the cost of the consumption it was designed to contain.
Working with ZXM
ZXM designs investment governance structures for organisations building product operating models. The ZXM services page describes where that work begins.
References
- Hodgson, M. (2026). Evolve: The operating model AI demands. Zen Ex Machina.
- FinOps Foundation. (2024). FinOps framework. FinOps Foundation. https://www.finops.org/framework/
- Scrum.org. (2024). The evidence-based management guide: Improving value delivery under conditions of uncertainty. Scrum.org. https://www.scrum.org/resources/evidence-based-management-guide
