A lot of business leaders feel a specific, quiet anxiety about AI right now: a sense that everyone else has already figured it out, that their own organization is falling behind, and that catching up requires some large, complicated initiative they haven’t gotten around to launching yet. Almost none of that anxiety is warranted, and almost none of it reflects what actually works. Getting started with AI doesn’t require a data science team, a company-wide strategy document, or a large budget. It requires one well-chosen use case and the discipline to learn from it honestly before expanding.
Why the “big strategy first” instinct usually backfires
It’s tempting, especially for larger organizations, to want a comprehensive AI strategy before doing anything — a document that maps every possible use case across every department, prioritized and sequenced. In practice, this instinct tends to produce a lot of planning and very little actual progress, because a strategy built before anyone in the organization has hands-on experience with what AI can and can’t reliably do tends to be built on assumptions rather than evidence. We’ve written in AI Adoption Is a Decision Architecture Problem about why AI initiatives fail more often from an unredesigned decision process than from the technology itself — and a comprehensive strategy built in the abstract, without a single real use case to learn from, tends to walk straight into exactly that trap, because nobody yet knows what decisions would actually need to change.
A better starting point: one use case, chosen deliberately
The organizations that get real value from AI early tend to start with a single, specific, well-bounded use case rather than a broad initiative. A good first use case has three characteristics worth being deliberate about.
It solves a real, specific, currently painful problem — not a hypothetical future one. The best first AI projects address something your team already complains about regularly: a repetitive task that eats real time, a decision that currently takes too long because gathering the information is tedious, a process where errors currently slip through because a human is doing something a well-designed system could do more consistently. Starting with a real, currently-felt pain point means you’ll actually know quickly whether the AI project is working, because you already know what “better” looks like.
It has a clear owner and a low cost of being wrong at first. Choose a use case where a named person is genuinely responsible for it succeeding, and where an imperfect first version doesn’t create serious business risk. This is why customer-facing, high-stakes processes are usually poor first choices, even though they’re often where leadership imagines the biggest potential impact — the learning curve is real, and it’s much safer to climb it somewhere the mistakes are cheap.
It produces a result you can measure honestly, not just a demo that looks impressive. Before starting, define specifically what success would look like in business terms — time saved, error rate reduced, a specific outcome improved — and commit to measuring against that definition honestly, even if the result is underwhelming. A use case chosen partly because it will “look good” in an internal presentation, rather than because it’s genuinely measurable, tends to produce exactly the kind of unclear, unconvincing pilot outcome we describe in Pilot Purgatory — technically completed, but never quite proving anything either way.
What to actually do once you’ve picked a use case
Move quickly to a working version, even an imperfect one, rather than spending months refining requirements before building anything. AI projects benefit enormously from real, hands-on experience — the gap between how a use case looks on paper and how it actually behaves with real data and real users is often significant, and you can only close that gap by actually building and testing something, not by planning more thoroughly in the abstract.
Equally important: decide in advance who will actually use the AI’s output, and what specifically will change about how they work because of it. This is the step most first AI projects skip, and it’s the single most common reason a technically successful pilot fails to produce real business value — the output gets generated, but nobody’s actual workflow or decision process was redesigned to use it differently than before.
A note on who should lead this first project
It doesn’t need to sit with your most senior technical person, and it often shouldn’t. The best owner for a first AI project is usually whoever is closest to the actual problem being solved and genuinely motivated to see it improve — technical skill can be supplemented with outside support if needed, but genuine ownership and motivation are much harder to substitute for.
What this looked like for one of our clients
We worked with a mid-sized insurance brokerage whose leadership had spent nearly a year discussing a broad “AI strategy” without launching a single real project. We helped them instead pick one specific, currently painful process — the time-consuming manual review of incoming claims documentation — as a first use case, with one clear owner and a specific, measurable target: cutting initial review time by a defined amount within eight weeks. That focused first project succeeded, gave the organization real, hands-on experience with what worked and what didn’t, and created much more grounded momentum for expanding into additional use cases than the year of abstract strategy discussion ever had. You can read more in our insurance brokerage AI pilot case study.
The bottom line
If you’re feeling behind on AI, the fix isn’t a bigger, more comprehensive plan — it’s a smaller, sharper first step. Pick one real problem, give it a clear owner, define what success actually looks like, and build something real quickly enough to learn from it. Everything else — including whatever broader strategy eventually makes sense for your organization — gets easier to figure out once you have real experience to build it on.