Learn With Nathan
Sign in
Full sample chapter · AI for Executives
Choosing the First Use Case
Turn a shortlist of plausible ideas into one scored, defensible choice you can explain to your board and start on this month.
Chapter 04
Choosing the First Use Case
Turn a shortlist of plausible ideas into one scored, defensible choice you can explain to your board and start on this month.
By this point you have candidates. The failure mode now is not choosing badly — it is not choosing at all, or choosing the most interesting one instead of the one most likely to work.
The first use case carries a weight the second and third never will. It sets what your team believes is possible, it determines whether you get a second attempt, and it is the one your board will remember. That argues for choosing on likelihood of success rather than size of prize.
This chapter gives a scoring method simple enough to complete in an afternoon and strict enough to overrule your instincts. The score is not the decision — you are — but a written score makes it much harder to drift toward the exciting option without noticing.
The first one should be slightly boring
The first project buys the right to attempt the second
The purpose of the first project is not to transform the business. It is to prove, to you and to your staff, that this can produce a real result in your company with your material. A modest success in eight weeks is worth more than an ambitious attempt that is still ambiguous at six months, because the modest success is what funds and licenses everything after it.
This inverts the usual instinct. The tempting first project is the one with the biggest number attached. The right first project is the one where you would be genuinely surprised if it failed — and where, if it did fail, you would learn something specific about why.
Score every candidate on five factors
Volume, checkability, ownership, exposure, and baseline
Score each candidate one to five on all five. The factors are chosen because each one, when absent, has killed real projects in companies of this size.
Volume. How often does the task happen? Weekly is a floor; daily is better. Low volume means the saving is invisible and the team never builds a habit.
Checkability. Can somebody tell quickly that an answer is right? If verification requires an expert, you will not be able to build confidence incrementally.
Ownership. Is there one named person who does this work today and wants it improved? A task owned by everybody is owned by nobody, and volunteers evaporate in a busy month.
Exposure. If it produces a wrong answer, who sees it? Internal-only is a strong positive for a first project. Customer-facing is a reason to wait.
Baseline. Can you measure the current cost before you start — hours, error rate, turnaround time? Without a baseline you will not be able to prove the result, which means you will not be able to justify the second project.
Scoring a candidate use case
Five factors, scored one to five, with two that act as vetoes
Audiobook description
Five factors are listed: volume, checkability, ownership, exposure, and baseline. Checkability and baseline are marked as vetoes. The total score ranks candidates against each other, but a score of one or two on either veto factor disqualifies a candidate outright, however high its total.
Two factors are vetoes, not weights
A high total cannot compensate for these two
Ordinary scoring lets a strong factor offset a weak one, which is right for volume, ownership, and exposure. It is wrong for checkability and baseline, because those two are not benefits — they are the conditions under which you can learn anything at all.
Without checkability you cannot build trust incrementally, so the project depends on faith and collapses at its first visible error. Without a baseline you cannot demonstrate the result, so even a successful project ends in argument about whether it worked. Both failures are terminal, and neither is repairable after the fact: a baseline in particular cannot be taken retrospectively, which is why it must be a veto rather than a nice-to-have.
Write the choice down before you start
One page, agreed in advance, settles the argument later
Before any tool is bought, write a single page: the decision or task being improved, the person who owns it, the baseline as measured this week, what result would count as success, what result would end the attempt, and the date you will decide. Circulate it to whoever will be in the room when the result is discussed.
This page costs an hour and prevents the most common ending, which is not failure but ambiguity — a pilot that produced a generally positive impression and no decision, discussed for a further two months and then quietly dropped. Agreeing the stopping condition while everybody is still optimistic is the only time it can be agreed honestly.
Pause and apply
Reflection questions
- Which candidate are you drawn to for reasons the scoring does not capture — and is that instinct evidence or appetite?
- For your leading candidate, exactly how would somebody check that an answer is right?
- What result, specifically, would make you stop? If you cannot answer, you are not ready to start.
Sources and further reading
Chapter 4 endnotes
- OECD. AI Adoption and Diffusion in Small and Medium Enterprises, 2026. OECD digital economy research.