The Boring Task My Team and I Always Pilot AI on First

When a business is excited about AI, the instinct is to pilot it on the most ambitious thing available — the use case that would be most impressive if it worked. My team and I almost always recommend the opposite starting point: the most boring, lowest-stakes, easiest-to-verify task in the business. That ordering isn't about managing excitement. It's about how pilots actually succeed or fail, and about building a foundation of evidence a business can actually trust before betting anything significant on it.

This approach often disappoints people in the first conversation, because starting boring doesn't sound like the dramatic transformation most businesses imagine when they first commit to exploring AI seriously. The disappointment tends to fade quickly once the actual mechanics of why this order works are laid out clearly.

Why the exciting use case is the riskier place to start

An ambitious first pilot is also usually the hardest one to evaluate honestly — more moving parts, more ways a partial success can get mistaken for a full one, or vice versa.

The most ambitious use case is typically also the most complex one to judge fairly — more variables, more ways partial success could be overstated or a genuine success could be dismissed because of one visible flaw. Starting there means the business's first real data point about whether AI works for them is also the noisiest, least reliable one available, which is precisely the data point a business is relying on most heavily to decide whether to invest further.

Why a boring task makes a better first data point

A low-stakes, well-defined task produces a clear, unambiguous result quickly — exactly the kind of evidence a business needs before deciding how far to take this.

A boring, well-defined task — summarizing routine documents, sorting a predictable category of requests — tends to produce a result that's easy to judge as clearly successful or clearly not, usually within days rather than months. That clarity is exactly what's needed before a business commits further, because it answers the real first question honestly: does this actually work here, on something we can verify without much ambiguity, before any larger resources get committed to something harder to evaluate.

A concrete picture of what a good first pilot actually looks like

Automatically sorting incoming support requests into three or four standard categories, checked against how a person would have sorted the same batch, produces a clean, countable accuracy number within the first week.

Picture a business piloting AI on something genuinely unglamorous: automatically sorting incoming customer support requests into a handful of standard categories, the same categories a person has always sorted them into by hand. Within the first week, the business can directly compare the tool's categorization against what a person would have chosen for the same batch of requests, producing a clean, countable accuracy number. That number, however unexciting the task sounds, gives the business genuine, verifiable evidence about how well this category of AI actually performs inside their specific operation — evidence a more ambitious first pilot would have taken far longer, and far more ambiguity, to produce.

What a successful boring pilot actually builds

A clean early win on something low-stakes builds the internal trust and working knowledge needed to tackle a harder use case next — trust that an ambiguous first pilot never builds.

A clear, verifiable early success — even on something unglamorous — builds two things a business needs before going further: genuine internal trust that the technology works, and practical experience with how to evaluate and manage it. Both of those transfer directly to the next, more ambitious use case, which goes considerably smoother for having not been the first thing attempted, because the team has already learned, on a low-stakes task, how to properly evaluate and manage a tool like this before applying that same discipline to something with real consequences attached.

Why skipping this step tends to backfire

Starting ambitious and getting an ambiguous result tends to produce premature enthusiasm or premature abandonment — neither of which is based on much real evidence either way.

Starting with the ambitious use case and getting a mixed, hard-to-interpret result tends to push a business toward one of two overreactions — declaring AI doesn't work based on one noisy data point, or declaring it a success prematurely and scaling something that was never properly verified. Starting boring avoids both failure modes, by making sure the first real conclusion the business reaches is actually based on clean evidence, rather than an ambiguous result that gets interpreted however the loudest voice in the room happens to feel that week.

Why this approach requires some patience from leadership

Starting boring asks leadership to delay the exciting rollout they originally imagined, in favor of a smaller, less visible first step — a request that requires genuine buy-in, not just technical agreement.

This sequencing only works if leadership genuinely buys into starting small, rather than treating the boring pilot as a formality to rush through on the way to the exciting rollout they originally imagined. Explaining the reasoning clearly upfront — that the boring pilot is building the evidence and trust the exciting rollout will actually depend on — tends to secure that patience far more reliably than simply asserting that starting small is the right approach without explaining why it matters.