Most teams measure AI by time saved, which is the half that looks good

Buried in the findings of a 2026 product management survey is a sentence that describes the entire measurement problem around AI at work:

Most teams measure AI's impact through time saved, which is useful but not sufficient to defend a strategy.

That is Productside, summarising its own research. The wording is careful and the implication is larger than the caution suggests: the industry has standardised on a metric that measures the step where the gains appear and not the step where they go.

What the survey says

Productside's State of AI for Product Management 2026 is based on a proprietary survey of 250+ product professionals across industries, regions and organisation sizes. Five findings shape it, per the publisher's own summary:

• 80% of PMs now use AI regularly. Personal adoption is mainstream.
• Nearly half of organisations are investing in customer-facing AI, but most cannot clearly articulate the expected return.
• Only 23% have a clear AI strategy with defined ownership. The rest are developing one, running bottom-up experimentation, or have none.
• The biggest blocker is data access and quality — not tools, not budget.
• Most measure impact through time saved, which the report calls insufficient to defend a strategy.

What this is

A self-reported vendor survey, and worth labelling as such before drawing anything from it.

Productside sells product management training, including AI product management training. A finding that individual adoption is high while organisational readiness is low is, among other things, a description of a market for the thing they sell. That does not make it wrong — the pattern is plausible and matches other reporting — but it is not a neutral measurement.

The sample is 250+ self-selected respondents, the full report is gated, and the findings quoted above come from the publisher's own summary rather than the underlying data. Treat the numbers as directional.

Worth noting separately: several secondary write-ups of "2026 PM AI adoption" mix these figures with numbers from entirely different surveys — a 73% weekly-use figure from a survey of 1,200 PMs, a 68% PRD-writing figure from somewhere else. None of those appear in Productside's stated findings, and combining them produces a picture no single study supports.

Why time saved is the wrong half

The finding worth acting on is the fifth one, and it becomes sharper when read next to Google's DORA research.

DORA describes a verification tax: time saved generating code gets reallocated to auditing and verifying it. The work does not disappear. It moves — from writing to checking.

Put those together and the problem is structural rather than a matter of rigour. Time saved is typically measured at the point of generation, which is exactly the point where the saving is real and visible. The cost lands later, in a different activity, often for a different person, and usually with no instrument pointed at it.

So the metric is not false. It is partial in a direction that flatters. A team measuring drafting time will record a genuine improvement while the total time to a correct, shipped result stays flat or rises — and nothing in the measurement will show that.

This is the same shape as proxy displacement: a reasonable stand-in becomes the target, and the link to what it stood for quietly breaks.

The product-team version

Specs are the clearest case, because PRD drafting is one of the most common AI use cases in the job.

Drafting time collapses. That is real and easy to observe. What is not measured is what happens downstream: whether the draft was specific enough to build from, how many clarifying questions it produced at handoff, whether the ambiguity in it got resolved or silently implemented one way.

A spec written in ten minutes that generates five questions in refinement and one wrong implementation has not saved forty minutes. It has moved them, into three people's calendars, and recorded a win.

What to measure instead

One substitution does most of the work: measure end to end, not step by step.

Elapsed time from starting a piece of work to it being correct and shipped. That number includes the generation step, the review step, the clarification round and the rework — which is to say it includes the place the saving goes.

It is harder to attribute and noisier than drafting time. It is also the only version that can fall as well as rise, which is the property that makes a metric worth having at all. A measurement that only ever improves is not measuring anything.

Two supporting numbers, both cheap:

• Questions per handoff. If specs get faster to write and the question count stays flat, the drafting saving is real. If questions rise, you have located where the time went.
• Rework after review. Track whether "AI-assisted" specs need more or fewer passes than hand-written ones. Nobody is measuring this and it is the most direct evidence available.

The uncomfortable read

Eighty percent adoption, 23% with a strategy, and the dominant metric measuring the half of the process where the savings show up.

The honest conclusion is not that AI is not helping. It is that most teams currently cannot tell, because the instrument they are using was chosen for being easy to read rather than for being able to return bad news.

FAQ

How do most teams measure AI impact? Time saved — one of five headline findings, described by the publisher as insufficient to defend a strategy.

What is wrong with it? It measures the generation step. DORA's verification tax says the saved time reappears in auditing and checking.

How reliable is the survey? Self-reported, vendor-published, 250+ respondents, gated report. Directional.

What instead? End-to-end elapsed time to a correct shipped result, plus questions per handoff and rework after review.