Skip to main content

adoption vs utility

the real reason enterprise AI keeps stalling

here’s a scenario we’ve seen more than once.

a product team gets mandate and budget to bring ai into their workflow. they pick a vendor. they scope a pilot. they run it in a controlled environment with clean data and a motivated squad. it works. the demo is good. leadership is impressed.

then someone asks who owns the rollout.

the room gets quiet.

six months later, the pilot is still a pilot. a new vendor is being evaluated. and the team is quietly demoralized, not because they failed, the technology worked, but because nothing they built made it to the people it was supposed to help.

this is the pattern mckinsey1 calls “pilot purgatory.” in their 2025 state of ai research, covering nearly 2,000 organizations across 105 countries, they found that nearly two-thirds of enterprises remain stuck in experiment or pilot mode. only around 6% are seeing ai move the needle on enterprise-level outcomes. that gap isn’t about capability. it’s about execution infrastructure. the organizational conditions that let a proof-of-concept become a production system.

and those conditions are almost never technical.

ai amplifies. it doesn’t fix.

google’s DORA team2 has been studying high-performing software delivery organizations for a decade. their 2025 report, drawing on nearly 5,000 technology professionals worldwide, arrived at something product leaders need to internalize:

ai doesn’t fix a team. it amplifies what’s already there.

strong teams (the ones with clear ownership, stable priorities, and workflows designed to ship) use ai to move faster and build better. teams with unclear decision rights, fragmented handoffs, and processes that were designed for a different era find that ai surfaces their problems faster than anything else.

this reframes the question entirely. before a team can benefit from ai at scale, they need to get the work system right. the process, the roles, the rhythm. the human infrastructure that connects strategy to something in production.

most organizations skip this step. they buy the tools first and try to retrofit the structure later. that’s why the demos are always better than the deployments.

the workflow redesign gap

mckinsey identified one factor that most distinguishes high-performing ai organizations from everyone else:

they redesigned their workflows, rather than layering ai on top of existing processes.

only 21% have done this.

think about what that means for teams inside regulated industries (pharma, fintech, financial services) where the existing processes were built for compliance, not for speed. where MLR review, change control, and approval chains create friction that no ai tool can shortcut. the teams that are making progress aren’t fighting the compliance layer. they’re redesigning the work that sits around it (the brief, the handoff, the iteration loop) so that what reaches review is already tighter, faster, and cleaner.

that’s a product design problem. and it requires someone who understands both the regulatory environment and how high-functioning product teams actually operate. that intersection is rarer than it should be.

what it looks like to get unstuck

nielsen norman group3 put it bluntly at the start of 2025, and it connects all of this. their words: “we’re seeing a massive regression of the average UX maturity in organizations (and that average wasn’t very high to begin with).”

it is an assertion from practice, not a tracked dataset. it also matches what we see.

organizations that should be getting better at building user-centered products are, under cost pressure and ai hype, moving backward. design gets compressed. research gets cut. products get built for approval, not adoption.

the teams that break the pattern aren’t always the ones with the most resources.

they’re the ones that kept asking the hard questions even when they were inconvenient. who is this for? what has to be true for them to actually use it? what does the work need to look like on a tuesday, not just in a demo?

that’s not a framework. it’s a discipline.

and it’s what separates the organizations that are in production from the ones still planning their next pilot.