Where to start with AI: the first case is not the most important one

The question that arrives is almost always "which tool should we use?". The one that settles things is different: "which case do we pick first?" — far less discussed, and far more decisive.

The first case is usually chosen by the most intuitive and most mistaken criterion: the problem that hurts most. It makes sense on paper — if you are going to spend effort, spend it where the damage is greatest. In practice, it is the most reliable way to burn your first attempt.

Four questions, not one

A case is chosen on four things at once: value (how much changes if it works), risk (what happens if it fails), feasibility (can it be done with what we have) and cost of error (what it costs to undo).

The last one almost never enters the account, and it is what separates a trial from an accident. A mistake you fix in an afternoon and a mistake that reaches the customer are not the same kind of mistake, even if they are equally likely.

And from that comes the rule:

Autonomy does not make its debut in the process that stops the company if it fails.

That is not cowardice. It is that the first case has a second job, one almost nobody weighs when choosing.

The first case exists to teach you the second

Nobody gets the first one right. Context will be missing, scope will overflow, somebody will discover in week three that the real process is not the one that was drawn.

That is not failure: it is the ordinary cost of learning to build. The right question is not "is this the most important case?", it is "is this the case that teaches me most cheaply?" — because what you take from it is not only the solution: it is knowing how to specify, how to validate with the people who use it, and where your own company gets it wrong when describing what it does.

After that, the important case becomes far safer. Before that, it is a gamble with a project's name on it.

What nobody defines, and everybody argues about later

There is a five-minute step that prevents the most unpleasant conversation these projects have: measurable success criteria, defined before building.

Without them, the assessment becomes opinion — and opinion, on a new subject, tends to favour whoever championed the idea. With them, the closing conversation is simple and free of resentment: this is what we wanted, and it either arrived or it did not.

It is also worth writing down what the solution will not do. Open scope is the most polite way of never finishing anything.

Every case leaves the team more fluent

Here is the return that appears on neither side's invoice.

Every solution built leaves the area more fluent — from spectator to author.

Whoever took part in building something understands what can be asked for next time, and — more importantly — what is not worth asking for. That literacy is not a training phase on the schedule. It happens continuously, with every solution the team helps to raise.

Which is why outsourcing everything carries a hidden cost: it delivers the result and leaves no capability behind.

And the second comes faster than the first

There is an effect that only shows up from the third case onwards, and it is what makes the arithmetic actually work:

Every solution deposits reusable pieces... the next solution is born faster than the last, because part of what it needs already exists.

The login, the report, the way of talking to the system that was already there — none of it is rebuilt. Whoever looks at the first case in isolation almost always finds it expensive. It is expensive: it is also paying for the second and the third.

The test

Pick the candidate for your company's first case and answer:

If it goes wrong, what exactly happens — and what does it cost to undo?

If the answer involves a customer, money going out, or something that cannot be reversed, that is not the first one. It is the third — and you will get there far sooner than if you had started with it.