The AI productivity gap
This article was drafted with AI assistance and reviewed by our team before publishing.
You've subscribed to the tools. Your team is using Copilot, ChatGPT, or something purpose-built for your industry. Productivity feels better — meetings are shorter, first drafts appear faster, support tickets get answered in seconds. And yet, when you look at the numbers that actually matter — revenue, margin, operational efficiency — the needle hasn't moved. You're not imagining it, and you're not alone. Roughly 88% of organizations have now adopted AI in some form, according to research aggregated from McKinsey 2025 and the Stanford AI Index 2026. But only around 6% report meaningful impact on their EBIT — earnings before interest and taxes, the profit metric that strips out financial noise and shows what the business actually earned from operations. That's a gap so wide it deserves its own name. It does, in fact, have a precedent. Economists call it the Solow Paradox — named after Nobel laureate Robert Solow's 1987 observation that computers were showing up everywhere except in the productivity statistics. AI in 2025 is following the same script. The technology is real, the individual gains are real, and the business-level impact is largely missing. Understanding why is the only way to get to the other side of it.
The Gains Are Real — They Just Stop at the Task Level
This isn't a story about AI being overhyped in a simple sense. The task-level performance data is compelling. Research from METR, NBER, and MIT shows customer support teams handling 14–35% more interactions with the same headcount, and engineering teams merging roughly 26% more pull requests per week when working with AI coding assistants. These are real, measurable gains that show up in sprint reviews and support dashboards. The problem is what happens next. Those gains are happening inside individual tasks — a support agent resolving a ticket faster, a developer writing a function more quickly. But most business value isn't created at the task level. It's created at the workflow level: the sequence of steps, handoffs, decisions, and feedback loops that connect individual actions into an outcome a customer pays for. And at that level, the surrounding process almost always hasn't changed. Think of it this way: if an AI helps your support agent respond in two minutes instead of ten, but the ticket still has to travel through the same three-step escalation process before it reaches them, the customer doesn't notice. The eight minutes you saved disappear into the queue. Task speed without workflow redesign is like upgrading one lane of a motorway while leaving the roundabout at the end untouched.
Why the Workflow Layer Gets Skipped
There are a few structural reasons this keeps happening. The first is that AI tools are built and marketed at the task level — they solve for "write this," "summarize that," "answer this question." Procurement decisions get made on the same basis. A founder sees a demo showing a 30% reduction in time-per-ticket, buys the tool, and measures success by whether agents are closing tickets faster. The workflow surrounding those tickets is treated as someone else's problem. The second reason is organizational inertia. McKinsey's State of AI research consistently flags that companies leading on AI impact are far more likely to have redesigned processes and roles alongside their technology investments — not just layered AI on top of existing structures. Most companies haven't done this. Changing how work flows through an organization is harder than adding a new software subscription, and it touches people, which makes it politically uncomfortable. The third reason is measurement. If you're only tracking individual task metrics — tickets closed, code committed, emails sent — you won't see the workflow-level collapse. You'll see green dashboards while margin sits flat. This is precisely why the 6% figure looks so counterintuitive against the 88% adoption rate: most companies are measuring the wrong thing and concluding the tool is working.
The Hidden Threshold Between Adoption and Impact
McKinsey's broader analysis of where AI creates value draws a useful distinction between AI that automates a task and AI that transforms a workflow. The former is additive — it saves some time, and that time mostly gets absorbed by other tasks. The latter is compounding — it removes a structural constraint, which changes what's possible downstream, which in turn changes what customers experience and what the business can charge or retain. The threshold between the two isn't technical. It's architectural. It's the difference between asking "what can AI do for this step?" and asking "if this step no longer worked the way it currently does, how would the whole process need to change?" The second question is harder, slower, and requires more organizational alignment. It's also where the 6% live. Companies on the right side of this threshold tend to share a few characteristics. They identified one or two high-leverage workflows — not just tasks — and rebuilt them around AI capability rather than inserting AI into the existing flow. They defined success at the workflow output level: lead conversion rate, customer retention, time-to-ship, support cost per resolved issue. And they treated the implementation as a change management project, not a software rollout.
What Closing the Gap Actually Looks Like
The practical path forward starts with workflow mapping before any new tool evaluation. Pick a specific business outcome you want to move — not "be more productive," but something measurable like "reduce the time between a qualified lead and a sent proposal" or "cut the cost per successfully resolved support case." Then trace every step currently involved in producing that outcome, including the handoffs and decision points that don't live inside any single tool. This is the kind of work we do at Kova Design Studio — helping businesses go from "we're using AI tools" to actually redesigning the process around them. The mapping stage almost always reveals that the bottleneck isn't where anyone expected it. With that map, the question becomes: where in this sequence does AI remove a structural constraint, not just speed up a step? Often it's in the synthesis layer — pulling together information from multiple sources to make a decision — or in the first-response layer, where speed directly affects downstream conversion or satisfaction. These are the points where redesigning around AI capability, rather than plugging AI into the existing design, creates compounding returns. Once you've identified the leverage points, instrument the right metrics before you start. If you only measure task speed after launch, you'll see the gains that were always going to be there — and miss the workflow-level impact you were actually trying to capture. Measure the end-to-end outcome from day one, so you have a baseline and can see whether the structural change is working. Finally, treat the human side of this with the same rigor as the technical side. The workflows that compound are almost always ones where roles shifted alongside the process. That means being explicit with your team about what changes, what they're now responsible for, and how success is measured — before the tool goes live, not after confusion sets in. The 88% number will keep climbing. The 6% will stay stubbornly small until the question changes from "are we using AI?" to "have we rebuilt the workflows that AI makes possible?"