Productivity

Jul 22, 2026

What to automate first

The instinct is to start with the biggest problem. The better first project is usually the one that teaches you the most for the least.

Blog image

Once a business decides to act on AI, the next question arrives immediately and is harder than it looks: out of everything we could do, what do we do first?

The default answer is to pick the biggest pain. It is intuitive, it is easy to justify to a board, and it is frequently wrong — because the biggest pain in a business is usually the most entangled, the most political and the least well understood.

What a first project is actually for

A first AI project has two jobs. One is to deliver value. The other, less obvious and arguably more important, is to teach the organisation how to do this.

Nobody knows, in advance, how their own business will respond. How will the team react when part of their work changes? How good does output have to be before people trust it? How much effort does the data actually need? Who turns out to be the informal blocker?

Those answers cannot be reasoned out in a workshop. They are only produced by shipping something. A first project chosen for its teaching value pays for itself twice: once in the value it delivers, and again in every subsequent project it de-risks.

Four properties of a good first move

  1. Contained One team, one workflow, one owner. If the project needs three departments to agree before it can start, it is not a first project — it is a programme wearing a disguise.

  2. Frequent The work should happen daily or weekly, not quarterly. You need enough volume to see whether it is working within weeks, not to wait two quarters for the third data point.

  3. Reversible If it goes wrong, the old way should still be there. Anything where failure is invisible, irreversible or client-facing belongs later in the sequence, once you have calibrated.

  4. Visibly annoying Pick work the team already complains about. Adoption is enormously easier when the people affected have been asking for this exact thing to go away.

The best first project is rarely the most valuable one available. It is the one that makes the second and third projects cheaper.

What to avoid at the start

Some categories are perfectly reasonable projects and terrible first projects.

  • Anything customer-facing. The failure mode is public, and you have no calibration yet for how often it will fail.

  • Anything that requires a data migration to begin. You will spend four months on plumbing and the organisation will conclude AI does not work here.

  • Anything whose success depends on a person changing a habit they are attached to, before you have any credibility to spend.

  • Anything where nobody can say what a good result looks like. If quality is undefined, you cannot tell whether the project worked.

The sequencing question nobody asks

There is one more consideration, and it is the one most often missed: which project makes the others easier?

Frequently a modest piece of work — getting documents into a consistent structure, or capturing a decision that currently happens in someone's head — is a prerequisite for three more valuable projects behind it. On its own it looks unambitious. In sequence, it is the highest-leverage thing on the list.

That is the difference between a list of opportunities and a plan. A list is ranked by value. A plan is ordered by what unlocks what.

Recent blogs