Sixteen months, and it worked
A regional insurance group of about 1,900 staff approved a three-year AI roadmap with eleven initiatives on it. Item three was an in-house document-extraction engine for claims intake: $740,000, sixteen months, a team of six — the strongest internal engineers in the company.
It went live on schedule. It worked.
Eleven months into that build, the vendor of the claims platform the group already licensed shipped document extraction as an included capability. By the time the in-house engine reached production, the same function cost about $34,000 a year inside software the group was already paying for. A competitor turned it on in six weeks.
I want to be precise about what went wrong, because it is not what most people assume. The build was not badly run. Every approval in that chain was defensible on the day it was made: the need was real, the cost was inside tolerance, and nothing on the market at the time of the vote delivered the function.
The loss sits on a different line. Item seven was a pricing model built on twelve years of the group's own claims history — the one initiative on that roadmap no vendor could ever ship to anybody else. It has not started. The six people who could have built it were busy.
Two kinds of item, one column
Every AI roadmap I read contains two structurally different kinds of item, and they are almost never labelled as different.
The first kind is an arriving capability. It is generic across industries — document extraction, meeting summarisation, first-line support triage, translation, code assistance. It requires no proprietary input to function. Two or more major platforms are already shipping some version of it, and the direction of travel is public, because vendors publish what they are building. Microsoft maintains a public feature roadmap listing what is in development, rolling out, or launched; Google runs a continuous release feed for Workspace. These are not rumours sourced through a friendly account manager; they are documents your procurement team can read on a Tuesday.
The second kind is a proprietary capability. It exists only because of something only you have: your historical data, your regulated process, your licence, your customer relationship. Item seven was this. Twelve years of claims history in one market, with the outcomes attached, is not a feature any vendor can build once and sell to eleven competitors. It is buildable by exactly one organisation, and the choice between a custom system and something off the shelf is only a real choice on lines of this kind.
Both items sit in the same table in the board pack. Same columns: initiative, sponsor, cost, timeline, projected return. Both carry an ROI number computed the same way, which is exactly what makes the difference invisible at the moment of the vote. The pack answers whether each line is worth doing. It does not answer whether each line is yours to do.
Four questions that set the date
Whether to do something and when to do it are separate decisions, and most roadmaps only make the first one. These are the four questions I put to each line — not to the roadmap as a whole, to each line, one at a time. Each has an answer that should worry the board.
- If we fund nothing here, does this capability arrive in software we already license within twenty-four months? This is an evidence question, not an opinion question. Acceptable evidence: a published vendor roadmap entry, two or more major platforms already shipping the function, and no proprietary input required to make it work. The answer that should worry you is "our needs are unique." Occasionally that is true. Usually it describes how the work feels from the inside rather than a property of the capability.
- Does the value come from having it before our competitors, or from having it at all? Funding an arriving capability early does not buy the capability. It buys earliness. Earliness is sometimes worth a great deal — but only against a specific, dated competitive consequence somebody can name: a tender in March, a regulatory deadline, a contract that renews once. If nobody can name one, earliness is not a benefit and should not be funded as though it were.
- What in this build is ours in a way a vendor could not sell to our competitor next quarter? Name the asset out loud: the data, the process, the licence, the relationship. If the sponsor cannot name it, the item is a purchase pretending to be a project — and it will be staffed like a project and overtaken like a purchase.
- If we wait and we are wrong, how long is the catch-up? Waiting has a cost, and it is not the same cost on every line. If being wrong means turning on a vendor feature six weeks after a rival did, that is a cheap wrong answer, and you should be willing to be wrong often at that price. If being wrong means starting a two-year data-and-model programme from a standing start while a competitor is two years in, that is not recoverable inside a strategy cycle. Build that one now, and build it first.
Notice what these questions are actually rationing. Not money. The insurance group could have found another $740,000 — capital allocation is a different lens on the same board pack. What it could not find was another six engineers of that calibre. Capital spent wrongly is embarrassing and recoverable. A year of the only team that could have built the proprietary item is not recoverable at any price.
Waiting is a workstream, not a gap
The fair objection to all of this is that "wait" is how organisations fall behind — because in most companies "wait" means nothing happens and nobody is responsible for the fact that nothing happened.
So make waiting a workstream. A decision to wait carries three obligations, and without all three it is not a decision.
Keep the data adoptable. If a capability is arriving, what determines whether you can use it in six weeks or sixteen months is the state of the input you will hand it. Extraction, classification, retrieval — they all consume your documents, your records, your history. Waiting well means those are structured, accessible and exportable before the capability lands, not after.
Fix portability at the next renewal, not at the adoption negotiation. The moment to secure export rights, format guarantees and exit terms is the contract renewal that is happening anyway this year, while the vendor is trying to keep you. The moment you have no leverage at all is the day you call to say you would like to switch on the new module. Put the clause in early, when it costs you nothing but attention.
Give the item an owner and a date. Not "we'll keep an eye on it." A named person, and a review in a specific quarter, minuted. That is the whole difference between patience and drift.
Do those three things and the arithmetic changes. An organisation that can absorb a new capability in six weeks does not need to build early to stay level with anyone — and staying adoptable is cheaper, faster, and does not consume the six people who should be building the thing only you can build.
The column to add to the next board pack
There is one structural change I would make to the next roadmap that comes in front of a board, and it is a single column.
Beside every initiative, one of three words: BUILD, ADOPT-WHEN-AVAILABLE, or WATCH. Each with a named owner. Each with a review date. BUILD means a named proprietary asset sits behind the line and the catch-up cost would be unrecoverable. ADOPT-WHEN-AVAILABLE means we expect it in a platform we already license, we are keeping the inputs ready, and someone is watching for the release. WATCH means we are not sure yet, and we have booked the date on which we will be. This is the column most missing from an otherwise board-ready roadmap.
Then minute the timing decision, not just the funding decision. Boards record what they approved and how much. Almost none record why they approved it now rather than in eighteen months, which means nobody can be held to that reasoning when the market moves underneath it.
Item seven is still not built. That is the sentence I would want a board to sit with. The test of a roadmap is not how much of it is moving. It is whether the part only you could have built is the part you actually built.
