Keeping the scope small on purpose

Most stalled AI projects we have looked at were not stalled on capability. They were stalled because nobody could say precisely what the system was supposed to do, so nobody could tell whether it was doing it.

“Help the support team” is not a task. “Given a new ticket, suggest which of our nine categories it belongs to” is a task. It has an input, a bounded output, and an obvious way to check the answer. It is also much less impressive to describe, which is part of why it tends to get skipped.

Narrow first, then widen

Starting narrow buys you three things worth having.

You can measure. A bounded output means you can compare against a labelled set and get a number, which is the difference between improving something and fiddling with it.

You can ship in weeks rather than never. A narrow task has a small surface, so the integration work is small too.

You learn what the wide version would need. Almost every time, the categorisation task surfaces something nobody expected — the tickets that legitimately belong to two categories, the ones that are actually a duplicate of an open ticket. Those discoveries change the design of the broader system, and they are cheaper to find now.

The honest trade-off

Narrow scope means the first version will not do the thing someone imagined in the meeting. That is a real cost, and it is worth naming out loud rather than quietly delivering less than was expected.

The version to argue for is the one where you can point at a number after a few weeks and say what it means. From there, widening is a series of small decisions with evidence behind each one, which is a considerably better position than a large system nobody can evaluate.