I've watched this play out more times than I can count. A founder or team lead gets excited about an AI tool — and they should, because the tools are genuinely remarkable. They buy the subscription, schedule a demo, maybe record a Loom walkthrough. The team nods along. And then, somewhere between week two and week three, usage quietly drops to zero.
It doesn't feel like a failure at first. People are busy. There's a deadline. They'll get back to it. But they don't. And six months later, the company is paying for licenses nobody opens.
This isn't a story about bad tools or resistant employees. It's a story about a missing step — one that almost no rollout includes.
MIT NANDA, 2025
McKinsey, 2024
The pattern
Almost every failed AI rollout follows the same arc. It's not random — it's predictable, which means it's also preventable.
The friction in week two is the critical moment. When someone gets an output they don't understand or can't use, they have two choices: figure out why, or go back to doing it the old way. Without a structure for figuring out why — a prompt library, a person to ask, a workflow that's been designed for their actual tasks — they almost always choose the second option. And once they've chosen it twice, the habit is set.
Why demos don't work
A demo shows what a tool can do in ideal conditions, with prepared examples, by someone who already knows how to use it. That's almost the opposite of what a new user encounters.
Real work is messy. The task a team member actually needs to do on Tuesday morning doesn't look anything like the polished example from the onboarding video. And when the output doesn't match expectations, most people don't diagnose the prompt — they conclude the tool doesn't work for them.
This is the gap I work in. It's not a technology gap — it's a translation gap.
What the successful rollouts have in common
I've seen rollouts that actually stick, and they share a few features that the failed ones don't.
Based on observed patterns across client engagements. Not a formal study.
The one change that fixes it
If I had to name a single intervention that separates the rollouts that work from the ones that don't, it's this: design the first task.
Don't give people a tool and a demo and tell them to explore. Give them one specific task — something they actually do every week — and show them exactly how to do it with the new tool. Walk through it. Let them do it themselves. Let them get it wrong and recover. Make the first real-world use case a success, and the second one will come naturally.
Schedule a demo. Share a login. Send a Loom. Tell people to "play with it and see what's useful." Wait for adoption to happen organically.
Audit one workflow. Build a prompt for that specific task. Run a 90-minute session where the team does it live, together, with someone in the room who can answer questions.
The difference sounds small. The results aren't.
Teams that go through a structured first-task session are significantly more likely to still be using the tool a month later. Not because the tool changed — because their relationship with it did. They moved from "this is something I'm supposed to use" to "this is something I actually know how to use." That shift is everything.
If this sounds familiar
If you've got a tool that's been gathering dust, the rollout isn't over — it just stalled. You don't need to start from scratch. You need the missing piece: a workflow that fits how your team actually works, and someone to bridge the gap between what the tool can do and what your people need it to do.
That's the work I do. If you'd like to talk through where your rollout got stuck, I'm easy to reach.