Why Should an AI Roadmap Separate Commitments From Options?
An AI roadmap should separate commitments from options because roadmap lines carry different risks that conventional planning disguises. Dr. Jonah Tebaa introduces the Commit-or-Option Sort, which divides initiatives into internal process bets funded fully as commitments and external capability bets funded with small, capped options. In a composite example, commitments take 70 percent of an illustrative budget, while capability bets receive 30 percent and rely on observable tripwires instead of progress percentages to trigger full conversion or closure.
Boards approve AI roadmaps the way they approve most plans: line by line, in order of priority, with a budget and a quarter beside each. Dr. Jonah Tebaa, an AI strategist and business transformation consultant, argues that this familiar format hides a problem. The lines in a roadmap do not all carry the same kind of risk, yet the page makes them look as if they do.
His answer is a short method he calls the Commit-or-Option Sort. Its core claim is plain: a multi-year AI roadmap should divide every line into a commitment, which works with today's models and is funded fully, or an option, which needs future capability and is funded small, with a named tripwire.
The question that exposes a weak slide
Dr. Tebaa often opens with a composite scene. A board pack shows five AI lines for 2027 to 2029. A director asks which of them still work if the models never get better than they are today. Nobody can answer, because the slide was never built to. Each line has an owner, a budget and a target date, and none says what it depends on.
In his view the director's question is the most useful one a board member can ask, because it separates two kinds of promise. One kind depends on the company. The other depends on the technology.
Process bets and capability bets
A process bet pays off if the firm does something it controls, such as cleaning its data, naming a process owner or training its staff. When it slips, the cause sits inside the company, and management has levers to pull.
A capability bet pays off only if the technology can reliably do something it cannot yet do reliably. When it slips, the cause is external. Dr. Tebaa points out that this is the one dependency management can neither control nor schedule. A leadership team can hire, reorganize and escalate, but it cannot decide when a model becomes good enough.
The trouble, he says, is that a conventional roadmap gives both kinds of bet the same format. A board reading that page cannot tell whether a late line reflects a failure of delivery or a technology that has not yet arrived.
The four parts of the Sort
The method asks for four steps on each line.
- Name the dependency. Complete the sentence "This line pays off only if ___."
- Classify it. If the blank concerns the firm, the line is a process bet. If it concerns what the technology can do, it is a capability bet.
- Size it. Process bets receive a full budget and a delivery date. Capability bets receive a capped option: a small pilot, one named owner and a fixed spend ceiling.
- Set the tripwire. Each option carries one observable condition that turns it into a commitment and one date or condition that closes it.
Dr. Tebaa is firm about the last step. In his work, he asks boards to look at tripwires rather than progress percentages, since a figure such as "70 percent complete" says nothing about whether the technology has crossed the threshold that matters.
What the composite example shows
To make the method concrete, he walks through a composite regional distributor, explicitly not a real client. Its roadmap has five lines. Cleaning product and price data, and drafting quotes with human review, are process bets. They become commitments and take 70 percent of the illustrative budget. Three lines, which are reading messy supplier documents in several languages, forecasting demand across seasons, and fully hands-off customer service, are capability bets. They become options and share the remaining 30 percent.
The supplier-document option shows how a tripwire works. It converts to a commitment if the system reaches an agreed accuracy on a sample of 200 real documents. If that has not happened by the closing date, the money goes back to the pool.
A subtler finding concerns the quote-drafting line. It depends on the data-cleaning line, so although it needs no better model, it is not free of risk. Dr. Tebaa uses this to show that the Sort also surfaces company-side dependencies hidden inside commitments.
Why options are not a hedge
A common objection is that an option is a cautious way of saying no. Dr. Tebaa disagrees. An option keeps the upside of a future capability while capping the cost of waiting for it. If the capability arrives, the firm already has a pilot, an owner and a test in place. If it does not, the loss is small and known in advance.
He also separates the Sort from his earlier Stop List. The Stop List addresses what to exclude when requests outnumber the budget. The Sort works on the lines that remain and asks what kind of risk each one carries.
The five questions for the boardroom
Dr. Tebaa offers directors five questions that can be put to any roadmap without preparation: which lines pay off if models stay as they are; what each option's tripwire is and who watches it; what the spend ceiling is; when each option closes if its tripwire never fires; and which commitments are waiting on something the company must fix first.
The board pack that results is a single page with two columns. Commitments list owners and delivery dates. Options list ceilings, tripwires and closing dates. The board reviews at fixed intervals and again whenever a tripwire fires.
His closing suggestion is simple enough to try the same day: write "This pays off only if ___" beside every line of your own roadmap, then count how many turn out to be options.
Related evidence: Google's Rules of Machine Learning guidance tells teams to design and implement metrics before formalising what the system will do, and to track as much as possible in the existing system first. (Google's Rules of Machine Learning)
