HyperTeamsThree questions for choosing work
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.
The second place transformations stall
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.
The three questions
Three is enough.
graph 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.
Their real purpose is to eliminate
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 |
Look at what got shelved
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 "they all look good," you asked the question wrong
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.
Where to find candidates
The three questions are a filter, not a finder. Collect candidates like this.
1. Start with where time goes
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.
2. The "we decided not to automate" list
In why now we saw that break-even dropped. The list you abandoned then may look different today.
3. Things people put up with
Work that generates complaints but never gets improved. Usually because improvement was expensive — and that cost may be different now.
Real cases
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 |
Common misconceptions
"You said start small — now you're saying pick high impact?"
Those are different axes.
- The three questions ask "is this worth doing at all" → they filter candidates
- Sequencing asks "which of those goes first"
Among worthwhile candidates you do the small, quickly-proven one first. You do not pick the small one among the worthless ones.
"Is employee convenience really unimportant?"
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.
Check yourself
1. Why does "internal policy search chatbot" get shelved?
Answer
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?
Answer
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?
Answer
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