Consulting · From the rollout trenches
Two ways AI rollouts fail — and how to dodge both
We've sat in enough kickoff meetings to know how this usually goes. A company has decided this is the year for AI. There's energy, there's budget, and there's a slide that says "transform." And then, a few months later, one of two things has happened — and they're almost opposites.
Failure one: all roadmap, no production
The first kind of company builds a gorgeous strategy. There's a maturity model, a steering committee, a center of excellence, and a deck so polished you could see your reflection in it. What there isn't, six months later, is a single thing anyone uses to do their actual job.
This happens when the planning becomes the product. Every question gets answered with another workstream. The pilots are real, technically, but they live in a sandbox nobody depends on, so nothing is ever quite ready to trust. The roadmap keeps getting more detailed and the work keeps not shipping.
Planning that never meets production isn't strategy. It's a very expensive way to feel busy.
Failure two: fast, but the wrong thing
The second kind of company has the opposite problem. They move. Somebody wires up an agent over a weekend, it demos well, and suddenly it's in front of customers. The energy is great. The aim is not.
Because nobody stopped to ask the boring questions — what exactly should this do, where must a human stay in the loop, what does "working" even mean — the thing that shipped solves a problem nobody had, or solves a real one in a way that quietly creates three more. Then comes the expensive part: a year of unwinding, re-scoping, and rebuilding trust with the people who got burned.
The dodge: enough aim, enough motion
Both failures come from the same root — treating strategy and shipping as separate phases owned by separate people. The teams that succeed keep them in the same hands and run them close together. Enough strategy to point in the right direction. Enough engineering to actually get there. The same crew carrying it from the question to the running system.
In practice that looks like our usual arc: discover what's worth doing, pilot it in real work where you can measure whether it helps, and only scale it once it's earned the right. You can stop after any stage. That's not a hedge — it's the point. A rollout you can stop is a rollout you can trust.
If you're staring at a roadmap that won't ship, or a quick win that's starting to wobble, that's a normal place to be. It's also a fixable one.