Every annual planning cycle I have sat through worked the same way. The product org submitted a headcount plan. More output meant more people, and the cost grew in predictable steps. The CFO could draw the line a year out and trust it. The entire ritual rested on one assumption: that output scales with heads.
That assumption is quietly breaking, and the planning processes built on top of it have not caught up.
The short version
The product org used to be a fixed headcount cost: want more output, hire more people, and the cost line grows predictably. In an agent-native company, a growing share of output comes from compute (tokens, tool calls, GPU time) rather than people. That cost is variable, usage-driven, and monthly, which means the "product org cost" line stops behaving like a fixed cost and starts behaving like infrastructure. For CPOs and CFOs, three things change: you budget output instead of heads, marginal cost stops being zero so quality and waste become financial, and capacity becomes elastic. The org that learns to plan in this blended unit wins on capital efficiency. The one still budgeting product purely in headcount is optimizing the wrong number.
For the customer-facing side of this shift, see per-outcome pricing and the Jevons cliff. For what boards now expect to see, see the CPO Mandate 2026.
How product used to be budgeted
The model was clean. Headcount was the unit of capacity. You sized the team to the roadmap, the cost was salaries plus overhead, and it grew in steps as you hired. It was fixed in the accounting sense: it did not move with how much the product was used. A quiet week and a launch week cost the same.
That predictability was a feature. It let finance plan, it let the board model burn, and it let the CPO defend a number. The whole apparatus of annual planning, headcount requests, and quarterly reviews was built for a cost that behaved this way.
What changed
Output stopped being a pure function of headcount. A team of six running a fleet of agents now produces what a team of twenty used to. I have watched this directly, and the math is not subtle. The work still gets done. But a meaningful share of the capacity now comes from compute, and compute does not show up as salaries.
It shows up as tokens, tool calls, and GPU time. And it has the opposite cost shape from headcount. It is variable, not fixed. It scales with usage, not with the org chart. A launch week genuinely costs more than a quiet week. The cost moves monthly, sometimes daily.
Blend those two together (a fixed headcount line and a variable compute line) and the combined product cost stops looking like a payroll line and starts looking like an infrastructure bill. That is the part planning processes were never designed for.
The three things that change
You budget output, not heads. The planning question shifts from "how many people do we need" to "how much outcome do we need, and what does it cost to produce." Cost per outcome replaces cost per FTE as the number that matters. This is uncomfortable because cost per outcome is harder to forecast and easier to be held accountable for. That discomfort is the job now.
Marginal cost stops being zero. Under the old model, once you had hired the team, an extra unit of work was free. The salaries were sunk. Under the new model, every agent run has a price. That means waste is now financial, not just operational. A poorly scoped agent burning tokens on low-value work is a line item, not just a process smell. Quality and efficiency move from engineering concerns to budget concerns.
Capacity becomes elastic. This one is an opportunity, not a threat. You could never scale a human team up for a launch and down the week after. You can do exactly that with compute. The product org gains the ability to flex capacity to demand, which changes how you plan launches, seasonal load, and experiments. The orgs that exploit this run leaner baselines and surge when it counts.
How to actually plan this way
Start by instrumenting compute spend at the workflow level. You cannot manage a cost you cannot see, and most orgs see one aggregate cloud bill with no attribution. Break it down by agent and by outcome. The CPO Mandate post has the board-facing version of this line; the internal version is more granular.
Then bring a blended view to finance. Not "here is my headcount ask" and separately "here is a mysterious AI bill." One picture: the fixed headcount line, the variable compute line, and cost per outcome as the metric that ties them together. Show the CFO the trade-off explicitly. A dollar of compute and a dollar of headcount buy different things with different risk profiles, and the mix is now a real decision.
Finally, hire for the part compute cannot do. Judgment, taste, direction, and accountability still come from people, and those do not scale with tokens. The mix shifts toward fewer people making higher-leverage decisions, each directing more compute. You are not eliminating the team. You are changing what the team is for.
The plain version
For decades, more product meant more people, and the cost was predictable. Now a growing share of product output comes from compute, which is variable, usage-driven, and behaves like infrastructure. If you are still budgeting your product org purely in headcount, you are measuring a shrinking part of how the work actually gets produced.
Pull one number this week: your total agent and compute spend for the last quarter, divided by a unit of output you care about. That cost-per-outcome figure is the start of the new budget. Most CPOs have never calculated it. The ones who have are the ones planning for the next three years instead of the last ten.
If you are working through a blended headcount-and-compute plan with your CFO and want a second set of eyes, this is one of the more common conversations I am in right now. Find me on LinkedIn.
Further reading
Also on Medium
Full archive →Frequently asked
What does 'the product budget is a compute budget' actually mean?+
It means a growing share of product output now comes from compute (agent runs, tokens, tool calls, GPU time) rather than from additional headcount. The cost of producing work shifts from fixed salaries to variable, usage-driven spend. So planning the product org increasingly looks like planning infrastructure, not just sizing a team.
How is this different from per-outcome pricing?+
Per-outcome pricing is about what you charge customers. This is about how you budget internally. The product budget shift is a capital-allocation and planning problem: how a CPO and CFO forecast and control the cost of producing product work when that cost is part fixed headcount and part variable compute. They are related, because internal cost-per-outcome informs external price, but they are different decisions.
Why does variable compute break annual planning?+
Annual planning assumes a fixed, step-wise cost that grows when you hire. Compute is monthly, usage-driven, and elastic. When you blend a fixed headcount line with a variable compute line, the combined 'product cost' stops behaving like a predictable fixed cost and starts behaving like infrastructure spend, which most annual planning processes are not built to model.
What should a CPO actually do differently?+
Budget output rather than heads by tracking cost per outcome, instrument agent spend so marginal cost is visible per workflow, and treat capacity as elastic (scale compute up for a launch, down after). Then bring a blended view to the CFO that shows both the fixed headcount line and the variable compute line, with cost-per-outcome as the unifying metric.
Does this mean we stop hiring?+
No. Judgment, taste, and accountability still come from people, and those do not scale with compute. It means you stop treating headcount as the only lever for output. You hire for judgment and direction, and you scale execution with compute. The mix shifts; people do not disappear.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn