In short
- A good first use case has four traits at once: it is repetitive, it genuinely hurts, the data already exists, and it is narrow enough to show before management patience runs out.
- The first project is not there to dazzle — it is there to work, get used and produce proof. Only proof opens the way to harder things.
- First trap: the most interesting idea is usually the most ambitious, and the most ambitious means the most unknowns at once.
- Second, opposite trap: a process that happens to be within reach but hurts nobody. The solution gets built, works, and nobody uses it.
- Interesting ≠ right. A first use case has to land where real pain meets available data.
What to look for in your first deployment
A good first use case has several traits at once. It's repeatable — it involves something that happens daily or weekly, not once a quarter, because only then does the saving actually add up. It hurts — someone at the company is losing real time on it and knows it, so the solution has a ready audience from day one. The data for it already exists — it sits in a system or in spreadsheets, you don't have to start collecting it from scratch. And it's narrow enough to build and demonstrate quickly, before management's patience runs out.
That sounds less impressive than "we'll deploy AI to forecast our entire production." And that's the point. The first project isn't meant to dazzle — it's meant to work, get used, and give the company proof that it works. Only that proof opens the door to harder things.
The most common trap
The trap works like this: the most interesting idea is usually the most ambitious one, and the most ambitious one means the most unknowns. Lots of data that isn't in good shape yet. Integrations with multiple systems. An effect that only becomes visible after months. Each of these is a risk on its own, and combined they produce a project that easily stalls and is hard to defend to management once it starts dragging on.
The other side of the same trap is picking a process just because it's convenient, even though it doesn't really hurt anyone. The solution gets built, it works, and nobody uses it, because the problem it solved wasn't painful enough. The first use case has to hit the point where real pain meets available data.
Where to get that list
Sometimes the first candidate is obvious — one process is clearly crying out for support and you don't have to search long. More often there are several candidates, and it's hard to tell from the outside — sometimes even from the inside — which one will win. That's what a readiness audit is for: it goes through processes, data, and people, pulls out concrete ideas specific to that company, and ranks them by feasibility and expected return. Instead of guessing, you get a list ordered from most promising down. What the audit covers and when it makes sense is something I've laid out separately.
What we don't know yet
Before acting on this article, it is worth checking whether the answers to these questions are known on your side:
- how many times a week the task you want to support genuinely repeats — counted, not estimated;
- whether the data it needs can be read today, or has to be gathered first;
- who in the department will feel enough relief to start using the tool of their own accord;
- which single number is meant to change, and what it stands at now;
- what you will do if the first implementation shows you picked the wrong process.
Frequently asked questions
How do we choose the first AI use case?
By testing a candidate against four things at once: is the task repetitive, does it genuinely hurt someone, does the data already exist, and can the scope be built quickly. The one that passes all four is your first implementation — even if it is not the most interesting.
Why not start with the most interesting idea?
Because the most interesting is usually the most ambitious, and that means the most unknowns at once: data in poor shape, integrations with several systems, and an effect visible only after months. Together they make a project that stalls easily and is hard to defend once it starts slipping.
What if a process is easy but hurts nobody?
That is the other side of the same trap. The solution gets built, it works, and nobody uses it, because the problem was not painful enough. A first use case has to land where real pain meets available data — the absence of obstacles is not enough.
Where does the list of candidates come from?
Sometimes the first candidate is obvious and needs no searching. More often there are several and it is hard to tell which will win — then a structured review walks through processes, data and people, draws concrete ideas out of that company and ranks them by feasibility and expected return.
What's next
If you have several AI ideas in front of you and don't know which to start with, check each one against four things: is it repeatable, does it really hurt, does the data already exist, and can it be built quickly. Whichever passes all four is your first deployment, even if it's not the most interesting one. And if there are more candidates and the choice isn't clear, an audit will do that sorting for you.
→ See how the audit picks your first project
→ Book a 30-minute consultation
