Product Operating Models Still Treat Engineering Capacity as the Scarce Resource

In our view, the fundamental reason to establish the product operating model in the past was to make better use of the expensive software engineering time and money. So, organizations applied the model to point resources at work worth doing, instead of bunch of work that may not pay off. Do discovery before commitment, because building the wrong thing costs months of time. Use roadmaps as capacity allocation, because there was a fixed amount to allocate.

Now the capacity problem is different, so the application of the model should look different.

Where Cagan is right

Cagan published the AI productivity paradox in July 2026. Atlassian surveyed 12,035 knowledge workers and 173 Fortune 1000 executives and found 89% of executives saying AI increased the speed of work while 6% could point to a clear example of organization-wide ROI. His read is that the paradox is organizational rather than technical. Companies are accelerating workflows that were already producing the wrong things, and acceleration does not improve direction. He quotes Hilary Gridley of Whoop:

"It's never been faster to build, which means it's never been easier to run 10 times faster in the wrong direction."

DORA has reported the same thing from the engineering side two years running. The 2025 report found higher AI adoption tracking with an increase in both delivery throughput and delivery instability, and DORA's March 2026 analysis holds that finding while adding that 90% of technology professionals now use AI at work. Their framing is that AI amplifies whatever system it lands in. DORA's 2026 ROI report prices the second half. Modeling a 500-person engineering organization, it lands on roughly 39% first-year return with change failure rate climbing from 5% to 6%. Our CTO landed in the same place in January, arguing that the bottleneck was never really the code.

Where we would add to it

His prescription is that companies escape the paradox by moving to the product operating model, and the acceleration then lands on outcomes.

Some of the model's mechanics encode the assumption that engineering capacity is the scarce input, so adopt the model as specified and you inherit that assumption along with the principles. Your organization can run the transformation faithfully and still land in the paradox.

Aakash Gupta and Rohan Varma described the shift in June 2026:

"Writing code is hard, and engineers are your scarcest resource. Building code is no longer expensive. A task that takes an engineer ten hours now takes ten minutes with Codex or Claude Code."

Cursor reached significant scale with roughly 40 engineers and one product manager, and OpenAI runs Codex with two product managers and about 40 engineers across 10 to 12 product surfaces. Our CTO predicted this compression in March, arguing the PM-to-engineer ratio follows the constraint. What the Cursor and Codex numbers add is the limit on it. Those ratios are unreachable when the product manager is the queue every decision waits in.

Which product operating model mechanics assumed scarce engineering

Four of them, each calibrated for a build cycle that cost months of time.

Discovery before commitment assumed validating an idea is cheaper than building it. When a probe takes an afternoon, some discovery costs more than the build it was meant to avoid.

The roadmap as capacity allocation answers which few things fit inside a fixed budget of engineering weeks. When throughput stops being fixed, that document is answering a question nobody asked, and roadmaps built this way slip for structural reasons.

The quarterly cycle exists because changing direction was expensive and feedback was slow. Both numbers changed and the cadence did not.

The product manager as the person who says no was the high-value act when capacity was the binding constraint. The binding constraint now is how fast a decision can be recorded in a form people and agents can both act on, which makes the high-value act writing precisely rather than filtering. Anthropic's 2026 State of AI Agents report, a survey of more than 500 technical leaders, found the top blockers to agent value were system integration at 46% and data access and quality at 42%. Model capability did not make the list. Those are context problems, and adding capacity does not move either one.

What replaces them

Specification becomes the control surface. A spec used to be a communication device between two people who could ask each other questions. When agents write a large share of the code, it becomes the interface between human judgment and machine execution, and everything it leaves out gets guessed. Specs now carry what used to live in a conversation. Which services the change touches, which prior decision it reverses, what breaks at ten times the volume, and how anyone will know it worked. That is more work per spec and considerably less per sprint. Half of product and engineering people already report ticket quality causing drag on delivery, measured before agent volume arrived. More in what spec-driven development actually is and specification quality is where AI lands hardest on product management.

Measurement moves from output to delivered outcome. Productboard and UserEvidence found only 40% of product teams measured AI against a business outcome while 98% had changed team structures. Changing structures without changing measurement is how you arrive at the 6% number.

The org chart changes last, because ratios like 40 engineers to one product manager are downstream of context quality. One product manager can support 40 when the decisions, the constraints and the customer evidence are written down somewhere both people and agents read. Cut headcount without doing that work and you get 40 engineers producing output against an unwritten strategy.

What the product operating model keeps

Almost all of the principles survive, and several matter more now. Outcomes over output gets harder to fake when output is cheap. Giving a team a real problem to own holds, because judgment is the input that did not get cheaper. Accountability holds most of all, because no volume of generated output removes the person whose name is on the result, which is the argument in the rise of the AI product manager.

The strongest case against all of this is that most companies never adopted the model, which makes criticizing its calibration a luxury problem. That is right for the median company and least right for the ones furthest along, who are now finding that a faithful transformation still leaves them unable to say where the investment went. Tooling helps with that and settles none of it, which we worked through in the new stack of AI tools for product managers.

What to do this week

Pick the most expensive thing you shipped last quarter and trace where the engineering investment went. Wherever the trail goes cold is the gap your specs leave for agents to guess at, and that point is the requirement.

Then take one spec in refinement, add the four things a conversation used to cover, and count the questions it draws. That count is your baseline.

‍

The Allstacks team writes about how software actually gets delivered, using data from across the delivery lifecycle rather than any one tool.

Give your operating model somewhere to put the context. Allstacks Product Studio composes product definitions grounded in your codebase, your customer voice and your delivery history, stress-tests them with adversarial AI reviewers, and scores them for readiness. Free right now, and one repository is enough to start. Sign up for Product Studio.

‍