Every organization exploring AI eventually ends up with a whiteboard full of candidate ideas — some ambitious, some modest, most generated in an enthusiastic brainstorming session. The hard part isn’t generating ideas. It’s picking the right one to actually start with, and the instinct that usually wins that debate — go with the most ambitious, most exciting idea, the one that would make the biggest splash if it worked — is very often exactly the wrong instinct for a first project.
Why the exciting idea is usually the wrong first choice
Ambitious AI use cases tend to share a specific set of properties that make them poor starting points: they usually touch complex, high-stakes processes, they require cleaner and more extensive data than most organizations actually have readily available, and they often need cross-functional coordination the organization hasn’t yet built the muscle for. None of this makes the idea bad — it just makes it a poor place to start learning, because everything that could go wrong is more likely to go wrong on your very first attempt, before you’ve built any of the organizational experience needed to handle it well. We describe this pattern in Pilot Purgatory: ambitious pilots often succeed technically but then stall indefinitely, because the gap between a promising demo and genuine production readiness is much larger than anyone accounted for at the start.
A four-criteria scoring framework
Instead of ranking candidate use cases by how exciting or strategically significant they sound, score each one against four more practical criteria.
How painful and frequent is the current problem, really? A use case addressing something that happens constantly and causes real, ongoing frustration is a better starting point than one addressing something rare or only mildly annoying, even if the rare problem sounds more interesting to solve. Frequency matters because it gives you more opportunities to learn quickly, and pain matters because it means the eventual improvement will be genuinely felt, not just theoretically nice to have.
How measurable would the outcome actually be? Some use cases have a clean, obvious way to measure success — time saved, errors reduced, a specific number that moves in a clear direction. Others are much fuzzier, with success being more a matter of subjective impression than hard data. Favor the measurable ones for a first project, because a use case you can’t cleanly measure is a use case you can’t honestly evaluate afterward, which makes it much harder to build a confident case for expanding further.
How low is the cost if the first attempt isn’t great? Every first AI project will have rough edges — that’s normal and expected. What matters is choosing a use case where those rough edges are cheap and safe, rather than one where an imperfect first version creates real risk to customers, revenue, or compliance. Internal-facing processes are usually safer starting points than customer-facing ones for exactly this reason.
How much good, accessible data already exists for it? AI performance depends heavily on the quality and availability of the data behind it. A use case that sounds compelling but would require months of data cleanup and consolidation before any real AI work could even begin is a much weaker first choice than one where reasonably good data is already sitting somewhere accessible, even if the underlying business problem sounds less dramatic.
Scoring in practice: comparing two candidate ideas
Imagine two candidate use cases: an ambitious AI system to personalize pricing dynamically across your entire customer base, versus a more modest project to automatically flag anomalies in expense report submissions before they go to a human reviewer. The pricing idea sounds more strategically significant and would likely generate more excitement in a leadership meeting. But it scores poorly on cost-of-being-wrong (pricing mistakes directly affect revenue and customer trust) and on data readiness (dynamic pricing typically requires extensive, clean historical data most companies don’t have well-organized). The expense report idea scores much better across all four criteria — frequent and mildly painful, easily measurable, low-risk if imperfect at first, and usually built on data that’s already reasonably accessible. It’s the better first project, even though it will never be the one featured in an all-hands presentation.
A note on resisting internal pressure to start bigger
It’s worth naming that there’s often real internal pressure — from leadership eager to show visible progress, or from a board asking what the AI strategy is — to start with something more ambitious than this framework would recommend. Part of managing a first AI project well is being willing to explain, clearly and confidently, why a smaller, better-scored use case is actually the faster path to real results, even if it looks less impressive in an initial announcement.
Why this discipline pays off even for the more ambitious ideas
Choosing well on a first project doesn’t mean abandoning the more ambitious ideas on your whiteboard — it means sequencing them correctly. The organizational learning, technical infrastructure, and internal trust built through a well-chosen first project directly improve your odds of succeeding with the more ambitious ones later. Skipping straight to the most exciting idea, without that groundwork, is exactly the pattern that produces the stalled pilots we describe in Pilot Purgatory.
What this looked like for one of our clients
A logistics company came to us with a shortlist of AI ideas, led by an ambitious real-time route optimization system that leadership was most excited about. Scoring the full list against these four criteria surfaced a much less glamorous but far more viable first project — automated flagging of delivery exceptions that currently required manual review. That project succeeded quickly, and the confidence and infrastructure it built made the later, more ambitious route optimization project measurably more successful when they tackled it a few months afterward. You can read more in our logistics AI use case selection case study.
The bottom line
When choosing a first AI project, resist ranking your options by ambition or excitement. Score them against pain and frequency, measurability, cost of imperfection, and data readiness instead — and be willing to start with the option that scores best, even if it’s not the one you’d lead with in a pitch to the board. The exciting ideas will still be there once you’ve built the experience and credibility to tackle them well.