Your AI Roadmap Keeps Changing. That Is the Point.

An AI roadmap that adapts over time is built as a sequence of constraints rather than a list of projects, because finishing any one initiative changes the business it was planned against. One explanation for why AI roadmaps go stale is that the technology moves too fast to plan around. That explanation is partly true, and it puts you in the passenger seat. There is a second reason that has nothing to do with model releases, and you have far more control over it.

When you remove the thing that was holding your business back, you do not arrive at a finished state. You arrive at a place where you can finally see the next thing holding your business back.

Manufacturing has a picture for this, and it is worth getting the provenance right. Norman Bodek, who brought Taiichi Ohno's "Toyota Production System" into English in 1988, set it out in his publisher's foreword: Toyota drove down work in process the way you would lower the water level in a river to expose the rocks, then chipped away at each problem the water had been covering.¹ The image is credited to Ohno, though it reaches us through Bodek rather than through Ohno's own chapters.

Inventory is the water. The rocks on the riverbed are the problems: the defects that slip through, the process that drifts out of control, the supplier who is quietly unreliable. When the water is high, the boat floats over all of it and the operation looks healthy. Lower the water and the rocks break the surface, one after another.

The rocks were not created by lowering the water. They were always there.

Why does an AI roadmap stop matching reality so quickly?

An AI roadmap stops matching reality because each completed initiative removes a constraint, and removing a constraint promotes a different problem to the front of the line. This is not a planning failure. It is the expected behavior of any system where the parts depend on each other.

Eliyahu Goldratt built a management discipline on this observation in 1984. His five focusing steps end with an instruction that reads almost like a warning: if a constraint has been broken, go back to step one, and do not allow inertia to become the system's constraint.² He wrote that about factories. It describes AI programs precisely.

I spent years at SmartOps doing the industrial version of this work. Inventory optimization is, in the plainest terms, a business built on lowering the water. You take out the buffer stock that was covering for unreliable forecasts and long supplier lead times, and what surfaces is every weakness the buffer was hiding. The customers who got the most value understood that surfacing those problems was the deliverable. The ones who struggled thought the project ended when the inventory came down.

AI programs behave the same way, and most roadmaps are not written to expect it.

What does lowering the water level look like in an AI program?

In an AI program, the water is whatever is currently absorbing your organization's slack: manual effort, waiting time, work in process, or people quietly compensating for a broken step. AI is unusually good at draining that particular reservoir, which is why it exposes rocks faster than most technology does.

Automate a step that used to take a person three days and you have not just saved three days. You have changed the arrival rate into whatever happens next. Every downstream process that was comfortable receiving work at the old pace now receives it faster than it can absorb.

This is why AI roadmaps that read as a tidy list of use cases, ranked once and scheduled across four quarters, come apart around the second item. The ranking was calculated against a version of the business that stopped existing the day the first item shipped.

The rocks were always there. Finishing the first project is what drained enough water to see them.

What happens after the first AI constraint is removed?

After the first constraint is removed, the useful question changes from "what was next on the list" to "what is binding now." Those two questions have different answers more often than not, and the gap between them is where AI programs lose momentum. Two Proxigee engagements this year show the pattern from opposite directions.

The retail operator I wrote about in a recent post on where AI should sit relative to your existing systems could not hire fast enough to keep its stores staffed. The opening work went straight at that constraint and brought staffing down from an emergency to something manageable. That is where the earlier story ended. It is not where the engagement ended.

With the fire out, the operators started asking something that had never come up while they were short-handed: what is the best way to share people between stores? Which locations could cover for each other, on which days, and what would we have to build to make that possible?

That question could not have been on the roadmap. While every store was scrambling to fill its own schedule, there was no spare capacity to share, so sharing it was not yet a real idea. Solving the first problem is what made the second one thinkable.

A second client, in a different industry, ran the same pattern in reverse. Their focus was growth, so the opening use cases went after reach: getting the company in front of more of its market, more consistently, without adding people to do it. That worked. Inbound interest climbed.

Then a hiring manager fielded more than fifty calls on a single job posting. Directly, to them, for the first time in twenty years of doing the work.

That is what success looked like. It was also, immediately, a different problem. Fifty people who call about a job are fifty people waiting on an answer, and the process for answering them had been built for a quieter era. It is a good problem to have. It is still a problem.

So the next initiative wrote itself, and nobody had written it beforehand: how do you receive and evaluate that many candidates respectfully and efficiently? Applicant tracking and the workflow around it, which is not a sentence anyone says at the start of a growth engagement.

Put those two engagements side by side and something useful shows up. In the first, hiring was the rock that surfaced first. In the second, hiring was the rock that surfaced second, and only because an unrelated initiative succeeded. Same function, opposite positions in the sequence.

There is no universal order to this. The order depends on which constraint your business happens to be sitting behind on the day you start.

In both cases the new constraint was not visible before the first program resolved something else. Not underestimated. Not deprioritized. Not visible.

Is this just an excuse for a roadmap nobody follows?

No, and the difference between a roadmap that adapts and a roadmap that drifts is testable in about a minute. Ask why the plan changed. If the answer names something you learned by finishing work, the roadmap is adapting. If the answer names a preference that shifted, an executive who got excited about a demo, or nothing anyone can articulate, the roadmap is drifting.

Adaptation has a receipt. Drift does not.

This matters because the two look identical on a status slide. Both show a plan that no longer matches what was approved in January. What separates them is a record of what each initiative was meant to relieve and what actually surfaced when it did. In my experience that record does more good than any other document an AI program produces in its first year, and it is rarely anyone's assigned job to keep it.

It does not have to be a document at all. On Proxigee engagements it is a standing status meeting that covers three things: what has happened, what could be better, and what opportunities are emerging. The first two are familiar ground for any project review. The third is the one that catches the rock, and it is the one most easily lost when the meeting runs long.

How do you plan when you know the plan will change?

You plan in decreasing resolution: the current constraint in detail, the next one in outline, and everything beyond that as a direction rather than a date. A roadmap is directionally good, and that is the right ambition for it. What it also has to do is anticipate the need to flex for the unforeseen, which means building that flex in deliberately instead of treating every change as a failure of the original plan. This is the phase that follows the goals and guardrails covered in starting with goals and governance.

In practice that means three things.

Name the constraint, not the technology. "Reduce the time from application to scheduled interview" survives contact with reality. "Deploy an AI scheduling agent" does not, because it is an answer pretending to be a goal.

Schedule the re-look, not just the work. Put a date on the conversation where you ask what surfaced, and hold it whether or not the project finished on time. Plenty of programs review status. Fewer review what the status revealed. Moving quickly helps here, which is the argument in why AI implementations take so much longer than they need to.

Budget for the second rock. A common way an AI program stalls is that the first initiative succeeds, exposes a real problem downstream, and there is no money or authority left to go after it. The win becomes the reason the program stops, which is a close cousin of the failure described in the pilot that succeeded and went nowhere.

Goldratt's warning about inertia lands hardest here. The constraint that stops an AI program after a successful first project is often not technical. It is the plan itself, defended past the point where it described anything real.

Where does this leave a small or midsize company?

A smaller company has a structural advantage here, because the distance between noticing a new constraint and acting on it is measured in days rather than budget cycles. Proxigee Services is an AI advisory firm in the Pittsburgh area that helps small and midsize businesses put AI to work inside the systems and teams they already have, and this pattern is most of what a first year of that work actually looks like. It is also why readiness is built in motion rather than settled in advance.

The companies I have watched get the most out of a first year with AI were not the ones who picked the best opening project. They were the ones still moving when the second rock came up.

Lower the water. Then look at what surfaced, and go again.