Back to Blog

Fourteen AI Requests, Budget for Three: Write the Stop List

A roadmap listing only what you will do is a wish list. Sort every excluded AI idea into four stops, each with an unlock event, and show the board.

Three blank cream index cards lit by a narrow blue light on a dark navy boardroom table, with eleven more cards filed into four brass-edged trays fading into the shadows behind them.
Direct answer

What does Fourteen AI Requests, Budget for Three: Write the Stop List mean in practice?

When facing fourteen AI proposals with budget for only three, Dr. Jonah Tebaa recommends creating a Stop List rather than leaving unfunded projects unexplained. In a composite case, excluded proposals are sorted into four categories: Not yet, Not here, Not ours to build, and Not worth it. The first three categories receive verifiable event-based unlock conditions rather than calendar dates, assigned to neutral owners who determine exactly when an initiative may legitimately return.

A composite, not a real client. The people and figures below are blended from patterns I meet repeatedly in my work.

Fourteen proposals, budget for three

Rami is the CFO of a 600-person distribution group. On a Thursday afternoon he has fourteen AI proposals spread across the boardroom table. Customer service wants a chatbot. Sales wants lead scoring. Finance wants invoice matching. Procurement wants supplier risk alerts. Operations wants demand forecasting. Nine more arrive from the remaining departments.

Each proposal has a slide, a champion and a reasonable argument. The budget, after a year of currency losses and one delayed receivable, covers three.

The usual move is to rank the fourteen, fund the top three and send the other eleven away with a vague "maybe next year." In my work I have watched that move produce the same result every time: eleven department heads who do not know why they lost, and who return in January with the same slide. That is the cost of an unexplained no.

Why a list of yeses is a wish list

A roadmap that lists only what the company will do tells the board nothing about the judgment behind it. Anyone can list three projects. The board cannot tell whether those three beat the other eleven or simply reached the table first.

Worse, an unexplained no is not a decision. It is a postponement with no terms, and it returns at every budget meeting, consuming the one resource the company cannot buy more of: executive attention.

The fix is a Stop List. Every excluded idea gets a reason, a category and an unlock condition. The unlock condition is an event, never a date. A date says "ask again in the third quarter," which invites lobbying as the quarter approaches. An event says what must be true before the idea returns, which turns lobbying into work.

I have written before about choosing the first use case, setting risk limits and giving approved cases an expiry date. This is the other half: publishing what was left out. The earlier pieces are on choosing a first use case, a board risk appetite statement and giving a business case a half-life.

The four stops

Every excluded idea lands in exactly one of four stops. If you cannot decide which, the idea is not yet understood well enough to be funded.

  1. Not yet. A dependency is missing: clean data, a documented process or a workflow owner. Test: if funding arrived tomorrow, could the team start on Monday? If not, it is a Not yet. Unlocks when: the named dependency exists and someone can show it.
  2. Not here. The idea is valid, but the organisation cannot absorb another change this year. Test: could the people who must change how they work do so without dropping something already promised? Unlocks when: a current programme finishes or capacity is freed in the affected team.
  3. Not ours to build. The capability is a commodity, and buying or waiting beats building. Test: would a competitor gain an edge from our version over a purchased one? Unlocks when: we take a buy decision, or a vendor meets a requirement we have written down.
  4. Not worth it. The value is below the management attention it would consume. Test: if it worked perfectly, would anyone on the executive team change a decision? Unlocks when: nothing, unless the facts change. Then it re-enters as a new proposal.

Two rules keep the list honest. First, an unlock condition must be something an outsider could verify. "When we are ready" is not one. Second, Not worth it must stay small. If a third of your list lands there, you are using it to avoid the harder sorting.

Overhead view of four brass-edged trays in a row holding five, three, two and one blank cards. Small brass keys rest on the first three trays and the fourth has none. Three funded cards sit apart in blue light above them.
The four stops, left to right: Not yet, Not here, Not ours to build, Not worth it. The first three carry an unlock condition; the last does not.

Sorting the fourteen

Back to Rami. Over two sessions with his team, the fourteen sorted like this.

  • Go (3): invoice matching, collections prioritisation and routing of customer enquiries. Each has a business owner, usable data and a team ready for the change.
  • Not yet (5): demand forecasting, lead scoring, supplier risk alerts, contract review and churn prediction. In each case the data sits in several systems, spreadsheets and branch-level habits that do not agree on what a customer or a product code is. The dependency is a single, trusted record.
  • Not here (3): dynamic pricing, warehouse re-slotting and a CV screener. Price lists change weekly with the currency, and the sales team is already absorbing that volatility by hand. A model on top would be a change the organisation cannot carry this year.
  • Not ours (2): meeting summaries and document search. Both are commodity capabilities. The unlock is a buy decision, not a project.
  • Not worth it (1): a narrated dashboard for a report the board reads twice a year. It would work, and nobody would act differently because of it.

In Lebanon and much of MENA, I see the two middle stops carry more weight than they would in a calmer economy. Fragmented data is the normal condition, not a failure, so Not yet is often the honest answer. Currency volatility and constant firefighting reduce the change capacity of every team, so Not here is too. Naming this plainly is kinder than funding projects that stall.

Putting the stop list in front of the board on one page

The Stop List is only useful if the board sees it. I ask for one page with three columns.

  • Do: the three funded bets, each with a named business owner.
  • Stop, with unlock: the eleven excluded ideas, each tagged with its stop and the event that would bring it back.
  • Owner of the next look: one named person per stop who watches for the unlock event and brings the idea back only when it happens.

A note on that owner: it should not be the idea's sponsor. A sponsor watches for the event that favours their proposal. A neutral owner watches for the event itself.

Rami's version fit on one sheet. The chairman read the eleven stops first, which surprised him less than it surprised the department heads, who could now see that their ideas had been judged and not ignored. Two of them asked what it would take to move from Not yet to Go. That is the conversation you want.

A roadmap is credible when you can see what it cost to choose

Any company can announce three AI initiatives. What earns trust is showing what those three displaced, and why. A Stop List makes the cost of choosing visible, and it gives every sponsor a fair route back that does not run through the CFO's calendar.

If you hold more proposals than budget, do one thing this week: take your longest list of requests and write one stop and one unlock event beside every item you will not fund. Then ask which stop holds your most requested idea.

Related evidence: Nielsen Norman Group's chatbot research found that users generally reacted favourably when a bot owned its failure and offered an escape hatch, such as a phone number or a live agent. (Nielsen Norman Group research on chatbot UX)

Article 14 of the EU AI Act requires high-risk AI systems to be designed and developed, including with appropriate human-machine interface tools, so that natural persons can effectively oversee them throughout the period they are in use. (EU AI Act Article 14 on human oversight)

Frequently asked questions

Should the board see the stop list, or only the roadmap?

The board should see both, on the same page. A roadmap alone shows what management chose, while the stop list shows how it chose. Directors can only challenge a judgment they can see.

How is a stop list different from a backlog?

A backlog is a queue, and everything in it quietly expects to be built eventually. A stop list is a set of decisions, each with a reason and an event that would change it. In my work I find a backlog invites waiting, while a stop list invites someone to go and create the missing condition.

What do I do when a department head insists their idea belongs on the roadmap?

I ask them which stop they disagree with and what evidence would move it. Usually the disagreement is about a dependency or about capacity, and that gives us something concrete to work on instead of an argument about priority. If they can show the unlock event has happened, the idea comes back, and that is exactly how the list is meant to work.

How often should the stop list be reviewed?

Not on a calendar. Each stop has an owner who watches for its unlock event, and the idea returns when the event occurs. The board sees the full page when the roadmap is next presented, so the list stays current without a recurring meeting to re-argue it.

Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.