Marco Di Santo published a check this morning for the number every AI roadmap starts from, and the check is right. This is a field note on which of its four questions carries the weight, from two cases where I was the one who rounded up.
The short version
Marco Di Santo's October 27 post says an AI roadmap starts from the maturity level a company gives itself, that the level comes out a step high in good faith, and that the fix is to write the believed level down before the assessment, run the assessment, and then put four questions to every answer claiming a system in production: which system, which process, how long, and who would notice within a day if it stopped. His reference for how long is three months, and he says no standard sets it. I have run both halves of the gap he describes. In my per-seat sunset, 12 accounts sat on the tracker as on plan for eighteen months, paying committed minimums and using less than the minimum, and we lost two when the legacy tier ended. An expense agent I put in a human approver's seat ran two weeks, approvals rose 40%, about $2,400 went through that should not have, and finance found out by switching it off. The time question passed both. The fourth question is the assessment, it has to be put to the operator rather than the leader, and the FDE scorecard already carries the two numbers that verify the answer: the last change the customer made without you, and the day-60 reversal.
The check
Di Santo's argument runs in three moves, and he says plainly that it is his, supported by surveys and untested by any study he could find.
A roadmap needs a starting point, and the starting point is the level a company gives itself. On his AIMF scale that runs from -3, active opposition, to +5, an organization designed around people and agents, with level 0 as people using AI on their own, +1 as a few structured pilots, and +2 as the first AI system running inside a business process in production. The risk is that the self-rating comes out a step high in good faith. He borrows Chris Argyris and Donald Schön's 1974 distinction, espoused theory against theory-in-use, and calls the application to AI maturity his own extension. Daily use and good pilots feel like +2 from the inside. He reports Cisco's 2025 survey of about 8,000 leaders: 58% said they had an AI roadmap, 18% had finalized use cases, so at least 40% had a roadmap with nothing finalized under it.
The fix: each leader writes down the level they believe their area is at, before the assessment. Run the assessment. Then every yes at +2 or above gets four questions. Which system is it, named the way you would name it to a colleague. Which business process does it run in, on real inputs with real consequences. How long has it been running, with three months as his reference. Who would notice within a day if it stopped, with the owner's name. Then compare the paper with what held up. A one-level gap is normal. Two levels is worth a second look.
I'd run the check. Here is what two of my own cases say about which question does the work.
Eighteen months, on plan
Drawdown Is Not Adoption has the first case. Eighteen months into moving a business from per-seat to outcome pricing, our tracker had 12 accounts classified as on plan. They had migrated on paper. They were paying their committed minimums. Their real usage sat below the minimum, and nobody escalated because the dashboard said fine. When the legacy tier sunset, they found out the hard way, and we lost two of them.
Put Di Santo's four questions to that. Which system? Named. Which process? Named, with money moving through it. How long? Eighteen months, six times his three-month bar. Who would notice within a day if it stopped?
Nobody. That is the answer, and it was the answer for eighteen months, and the first three questions never asked it.
Two weeks, then off
Agents Fit the Human Pattern Nine Times in Ten. Design the Tenth. has the second. An agent read expense reports submitted in Slack, checked them against policy, and auto-approved anything under $500 with a matching receipt. Finance had been doing that review by hand. It worked for two weeks. Then one of my engineers figured out that "dinner with customer" and a vague receipt passed every time. Approvals went up 40%. About $2,400 was approved that shouldn't have been, and finance turned it off within the month.
Same four questions. System, process, and time all pass, two weeks being a real production run by any honest reading. The fourth question is the one that got answered, and it got answered by finance doing the thing the question describes. They noticed. They switched it off. The level of that system was found by the stop, not by the form.
The field note
Question four is the assessment. The other three are its address.
Time in production is the question that fools a careful person, because it is the one that feels like evidence. Di Santo flags this himself: Gartner's number, as he reports it, is that 45% of high-maturity organizations kept AI projects running three years or more against 20% of the low-maturity ones, and both halves of that comparison come from the same self-ratings. My 12 accounts would have counted on the long-running side. They were paying.
Two things follow.
Ask the operator, not the leader. The leader filled in the form, and the leader is the one who rounded up in good faith, which is Di Santo's whole point about espoused theory. The person who runs the process can tell you the day the system last changed and what broke the last time it was off. If that person is not in the room when the roadmap's first line is read, the first line is a guess.
Then verify the answer with two numbers that already exist. The FDE Scorecard: Count What Stayed, Not Who Was Sent runs time to landing as the days from signature to the first change the customer makes without you, and reversal rate as the share of go-live workflows the customer switched off, overrode, or routed around by day 60. Those are question four with dates on it. A system someone would miss within a day has a recent change made by someone outside the team that built it, and it has not been routed around. A system nobody would miss has neither, however long it has been paid for.
This is where the forward deployed engineer inherits the gap. The FDE Transition argues through eleven parts that the FDE's job is what the customer kept, and The Pilot Was Approved on the Sixty is what it looks like when the contract was signed against a number nobody owned. The declared maturity level is the same kind of number. The roadmap was approved at that level, the handshake was sorted at that level, and the first week on site is question four on every system the assessment counted, asked of whoever runs each one.
Di Santo's phase 1 gate, as he quotes his own template, closes when the use case runs in production, the metric moved against the recorded baseline, and the process owner would object if you switched it off. That last clause is a question in his version. Twenty Minutes Is Not a Reason to Build made it an action, a date to switch it off for a week, and I'd carry that over. The objection, or the silence, is the level.
Under AI Product Management the claim is that AI collapsed the cost of the parts PMs were trained for and left the parts nobody trained for. Nobody trained us to put our own dashboard on trial. A tracker that says on plan and a form that says level +2 are the same artifact, and the fourth question is how you find out what either one is worth.
This week: take the AI roadmap on your desk and read its first line. If it states a level, list the systems that level rests on. For each one, find the person who runs the process and ask who would notice within a day if it stopped. Then pick one system and a date, and switch it off for a week.
Related answer: How do you check an AI maturity self-assessment before writing the roadmap?
Sources: Marco Di Santo, "Your AI Implementation Roadmap Starts From a Level Nobody Checked," Operational AI, October 27, 2026, read in full. The Cisco, Gartner, Wharton, BCG, and MIT figures, and the Argyris and Schön distinction, are cited only as he reports them; none of the underlying reports was opened. Falk Gottlob, "Drawdown Is Not Adoption" (September 30, 2026), "Agents Fit the Human Pattern Nine Times in Ten. Design the Tenth." (October 13, 2026), "The FDE Scorecard: Count What Stayed, Not Who Was Sent" (October 8, 2026), and "Twenty Minutes Is Not a Reason to Build" (October 5, 2026).
Frequently asked
What is Marco Di Santo's check for an AI maturity self-assessment?+
Three moves, in his October 27, 2026 post. Before the assessment, each leader writes down the level they believe their area is at on his AIMF scale, which runs from -3 (active opposition to AI) to +5 (an organization designed around people and agents). The assessment runs as usual. Then every yes that places an area at level +2 or above, the first AI system running inside a business process in production, gets four questions: which system is it, which business process does it run in, how long has it been running, and who would notice within a day if it stopped. The gap between the written level and what held up is the roadmap's first finding. He says the argument is his and that he found no study testing it.
Why does a company rate its own AI maturity too high?+
Di Santo's reading is that daily AI use and good pilots feel like level +2 from the inside, so a company at level 0 (people using AI on their own) or +1 (a few structured pilots) places itself higher in good faith. He applies Chris Argyris and Donald Schön's 1974 distinction between espoused theory, what people say guides them, and theory-in-use, what actually does, and calls the application to AI maturity his own extension. He reports Cisco's 2025 survey of about 8,000 leaders: 58% said they had an AI roadmap and 18% had finalized use cases, so at least 40% had a roadmap with nothing finalized under it.
Which of the four questions is the assessment?+
The fourth, who would notice within a day if it stopped. The other three are its address. In my per-seat sunset, 12 accounts sat on the tracker as on plan for eighteen months, paying committed minimums and using less than the minimum. By the time question, that was production. By the fourth question, nobody would have noticed, and nobody did until the legacy tier ended and we lost two of them. The expense agent is the other case: two weeks live, approvals up 40%, about $2,400 wrongly approved, and finance found out by switching it off.
Who should answer the fourth question?+
The person who runs the process, not the leader who filled in the assessment. The leader is the one who rounded up in good faith, which is the whole gap Di Santo describes. The operator can name the day the system last changed and what broke the last time it was off. Then verify the answer with two numbers from the FDE scorecard: the date of the last change the customer made without you, and whether the workflow was switched off, overridden, or routed around by day 60.
What does the forward deployed engineer do with this?+
Runs question four on every system the assessment counted, in the first week on site. The roadmap was approved at the declared level and the handshake was sorted at that level, so the FDE inherits a level nobody checked. The honest move is the one Di Santo's phase 1 gate implies, the process owner would object if you switched it off, run as an action: pick a date and switch it off for a week. The objection, or the silence, is the level.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn