What you will learn How to choose what to do first when you have ten candidates. And why "they all look good" is the most dangerous state to be in.
In the previous part we saw the difference between adoption and transformation. The next wall an organisation hits after deciding to transform is this:
"So what do we do first?"
Faced with that question, one of two things usually happens.
One, they start with whatever. Whichever department shouted loudest, or whichever case study happened to catch someone's eye.
Two, they never start. Collecting candidates produces twenty of them, three prioritisation meetings follow, and it fizzles out.
Both happen because there is no criterion.
Three is enough.
HyperTeamsgraph TD
Q["Should we do this?"] --> Q1["1 Does the customer-facing product get better?"]
Q --> Q2["2 Do operating costs go down?"]
Q --> Q3["3 Does it directly affect revenue or margin?"]
Q1 --> Y["Any 'yes' → candidate"]
Q2 --> Y
Q3 --> Y
Q1 --> N["All 'no' → shelve"]These three are distilled from more than twenty enterprise deliveries, and the order is meaningful. Business impact grows as you go down.
Each principle gets its own chapter next. Here we only learn how to use them.
On first reading the three questions look obvious. Applying them to a real candidate list is different.
Here is a real list:
| Candidate | Quality? | Cost? | Revenue? | Verdict |
|---|---|---|---|---|
| Automated customer replies | ○ | ○ | △ | candidate |
| Invoice data entry automation | △ | ○ | ✗ | candidate |
| Internal policy search chatbot | ✗ | △ | ✗ | shelve |
| Automatic meeting notes | ✗ | △ | ✗ | shelve |
| Competitor price monitoring | ✗ | ✗ | ○ | candidate |
| Internal AI training programme | ✗ | ✗ | ✗ | shelve |
Policy search chatbot and automatic meeting notes are nice-to-haves. Employees are more comfortable. But the customer-facing product does not get better and operating costs do not visibly fall.
These are the most dangerous candidates. Nobody objects, so they pass easily; once built, you hear "we're using it a lot" while the metrics stay flat. It ends as Failure 1 — adopted without a purpose.
The internal AI training programme deserves special care. It is necessary, but it is not itself the work. Training is a prerequisite for executing the work. Make it your first project and you cannot answer "we did the training, so what changed?"
Separating "nice to have" from "must do" is the purpose of these questions. Three "no"s does not mean it is a bad idea. It means it is not the thing to do now.
If you apply the three questions and all ten candidates come back "yes," you did not really ask. Ask again.
| Loose question | Strict question |
|---|---|
| "Does cost go down?" | "By how much? How many hours a month go into this today?" |
| "Does quality improve?" | "Quality measured how? What is that number today?" |
| "Does it help revenue?" | "By what path does it become revenue? How many steps in between?" |
Answering the right column requires numbers. A candidate with no numbers is usually not a "yes" but a "maybe." And maybe means shelve.
The three questions are a filter, not a finder. Collect candidates like this.
Ask each team:
"What were the three repetitive tasks that took the most time last month? How many hours each?"
Do not ask "what should we use AI for?" Ask that and people search within the AI features they already know (chatbots, summaries). Collect problems first and attach solutions later.
In why now we saw that break-even dropped. The list you abandoned then may look different today.
Work that generates complaints but never gets improved. Usually because improvement was expensive — and that cost may be different now.
There are published cases for each principle. Looking at them while choosing candidates helps you calibrate quickly.
| Principle | Cases |
|---|---|
| Quality | multi-channel review analysis · customer support automation |
| Cost | invoice processing · HR onboarding · resume screening |
| Revenue / margin | dynamic pricing · global price research |
Those are different axes.
Among worthwhile candidates you do the small, quickly-proven one first. You do not pick the small one among the worthless ones.
It matters. It is just unsuitable as a first project, because it cannot be proven. "Staff are more comfortable" does not produce an expansion budget.
Change the order instead — produce one provable result first, then use that credibility to do the convenience work. Much easier.
1. Why does "internal policy search chatbot" get shelved?
Because none of the three questions comes back clearly "yes." Staff are more comfortable, but the customer-facing product does not improve and operating costs do not visibly fall. Nobody objects to work like this so it passes easily, and once built the metrics do not move, leaving "so what got better?" unanswerable.
2. Why should you not ask "what should we use AI for?" when collecting candidates?
Because people search inside the AI features they already know. You get chatbots and summaries. Ask instead "what were the three most time-consuming repetitive tasks last month?" — collect problems first, attach solutions later — and real candidates surface.
3. All ten candidates came back "yes." What now?
Ask again, more strictly. Not "does cost go down?" but "by how much, and how many hours a month go into this today?" A candidate with no numbers is a "maybe," not a "yes," and maybe means shelve.
The next three chapters cover the three principles one at a time. Quality first → Quality