How to Fix the AI Productivity Gap

Marty Cagan published a piece this week called The AI Productivity Paradox. The core argument he makes is one we have been making some version of for well over a decade. "The real problem with the project model was never that it was too slow," he writes. "The larger problem is that it's designed to deliver output, rather than outcomes." He backs it with a compelling figure from Atlassian's State of Teams 2026 report . A full 89% of executives say AI has increased the speed of work, and only 6% feel confident they can point to specific organization-wide AI ROI. This is a familiar theme these days and this report adds another set of data to the AI productivity gap challenge many organizations are facing. .

We did not expect to read that argument three more times in the same seven days, but we did. Netflix's Chief Product and Technology Officer Elizabeth Stone told Lenny Rachitsky that the company is betting on systems thinkers over narrow specialists because AI makes the building cheap and the judgment scarce. Mind the Product ran a podcast on the one thing AI can't automate. Ash Maurya published a piece arguing that cheaper prototyping makes validation more important, not less. Melissa Perri's State of AI in Product 2026 survey found the same results in the data a month earlier, with 87.7% of product leaders using AI coding assistance and only 36% saying it strengthened their product operating model.

There’s no denying there’s an issue here. What’s lacking from these concentric arguments is what these companies should do about it. This is particularly challenging when you’re not the person with the organisational impact to make that change. What should you do if you’re not the person who gets to redesign the operating model?

The advice assumes an authority most people don't have

Read those pieces carefully and you notice who they are addressed to. Cagan is writing to leaders who can replace the project model with the product model. Stone is speaking from the CPTO chair at Netflix. Maurya is writing largely to founders, who can simply decide to pressure-test an idea because there is nobody above them to ask. Every one of these arguments pushes the kind of change that requires organizational authority to act on.

We work with a lot of teams in large organizations. While they also feel the AI productivity gap described in these various studies, they are often not in a position to make the kind of org-wide change necessary to start fixing it. The product manager we meet in a workshop is usually three or four layers down, has a roadmap that was substantially decided before it reached them, and is measured on whether the thing they were handed shipped on the date somebody committed to. Telling that person that their company's operating model is optimized for output is not news to them. They can see it. What they don’t obviously have is the authority and capacity to change that reality.

What changed, and why the old filter stopped working

When building software was expensive, the estimate of the level of effort did a good chunk of the governance work almost implicitly for teams. If a feature was going to take two engineers a full quarter, somebody senior was eventually going to ask whether it was worth two engineers and a quarter, and a certain number of bad (or good) ideas died in that conversation for reasons that had nothing to do with product sense. The scarcity of engineering time was doing the filtering.

Now that a capable engineer with good AI tooling can produce a working version of something in an afternoon, that implicit filter is gone. For now, in most large orgs, nothing has clearly replaced it. The ideas that didn’t make it past the estimate now pass through much more easily because the “engineering effort” question no longer has any teeth when the answer is "about an afternoon." This is the AI productivity paradox in a nutshell. We can make more stuff, faster. Great. But how do we decide which of that output gets to see the light of day?

What can a product manager do without permission

So what do you do if you can’t change the operating model?

The next time work arrives on your desk, before you estimate it and before you schedule it, write one sentence in this shape:

We will know this worked when [a specific group of people] does [a specific observable thing] [more, less, faster, or differently] than they do now. (If you want to add a metric that estimates by how much that behavior changes, even better.)

Then take that sentence back to whoever handed you the work and ask them to confirm it is right.

Here’s why this works and is (in most situations) not a career-limiting move. Asking a senior person to confirm your understanding of success comes across as diligence. You are doing the right work to ensure what you end up building makes a meaningful difference to the business.

Two things can happen once you present your success criteria to your stakeholder. Sometimes the person can answer immediately and precisely, in which case you’ve just gotten a real outcome for free and your prioritization for the quarter got easier. More often they cannot fill in the blanks, and then the conversation you are actually having is about whether anyone has thought about this yet, which is a much better conversation to have in week one than in month four. Josh has been asking a version of this for years in Outcomes Over Output with the question "who does what by how much," and the reason it survives is that it is nearly impossible to answer with an output. Try to describe a feature you shipped in that grammar and the sentence falls apart.

None of this is exotic, and none of it requires a mandate. It requires doing it early, which is the one advantage individual contributors and team leads already have. It shifts the conversation immediately from production and tooling to what would have to change for the work to have been worth doing.

The productivity numbers are going to keep getting better. The 6% ROI is not going to move until somebody decides, in a specific room, on a specific piece of work, what success actually looks like before the building starts. You do not need permission to be that person. You just have to ask before the estimate, not after.

Give this a shot on the next piece of work that lands on you, and let us know how the conversation goes.

Next
Next

Traits Before Tools: What Barry O'Reilly Taught Us About Adopting AI in the Right Order