# How to choose the right first AI use case (and avoid the wrong one) _Your first AI use case sets whether the whole program earns trust or burns it. Choosing it well is a business decision, not a technical one._ How to pick the right first AI use case so your pilot builds momentum instead of stalling. An anonymized story from an engineering leader who ran generative AI for a big-tech support org. # How to choose the right first AI use case (and avoid the wrong one) The first AI use case a company picks does more than deliver one feature. It sets the reputation of the whole program. Pick one that ships and moves a number, and every later request gets easier. Pick a flashy one that stalls, and you spend the next year explaining why AI has not paid off yet. MIT's 2025 study found roughly 95% of enterprise generative-AI pilots delivered no measurable return. The small group that did tended to share a profile: they focused on a back-office workflow, tied the result to a business metric, and integrated into how work already happened. In other words, the ones that worked were chosen carefully, not chosen for spectacle. ## The right use case is boring on purpose An engineering leader who ran generative-AI programs for a major tech company's support organization made the point that stuck with me. The barrier to building AI is now close to zero. Anyone can wire up an API call, get a single-shot result that looks amazing, and declare victory. He watched teams do exactly that and mistake the demo for the destination. His line was blunt: you can get to 80% and call it done, but that 80% is not something you can deploy in production. What separated the use cases his team could actually ship was an obsessive focus on the inputs and the outcomes, all of them, not just the happy path that demos well. The right first use case is one where you can map the realistic inputs, define the outcome that matters, and reach a level of reliability someone will trust with real work. That usually points you at something unglamorous. A repetitive support task. A document workflow. A place where "good enough to run unattended" is a reachable bar, not a fantasy. He also built his firm around signing off on outcomes rather than selling hours. That framing is a great filter for use-case choice. If you cannot name the outcome you would stake the project on, you have not found the right use case yet. The trap he described is the single-shot demo. A model produces one impressive result on one clean input, and the room decides the problem is solved. But the gap between that moment and production is the long tail of inputs nobody tested, the odd formats, the missing fields, the requests the demo never saw. A use case you can only vouch for on the happy path is a use case that will embarrass you the first week it runs unsupervised. ## A filter for the first one Run each candidate through four checks and start with the one that passes all four. - **Reliability is reachable.** You can define the inputs and hit a trust bar for production, not just a good demo. - **The outcome is nameable.** One metric you would happily be measured on. - **A real owner wants it.** Someone whose work gets better and who will adopt it. - **The blast radius is survivable.** If it is wrong occasionally, the process can catch it. The most technically interesting problem almost never passes all four. The boring back-office one often does, and it is the one that earns you the right to do the interesting one next. ## How we approach it at Density Labs Use-case selection is the first thing we do in the AI Readiness Assessment, our $2,500 engagement. We take the list of things a team wants AI to do and score each on reachable reliability, a nameable outcome, a real owner, and a survivable failure mode. Then we recommend the one to start with and, just as important, the ones to wait on. The goal is a first pilot that reaches production and buys credibility for everything after it. Pick the use case that ships. The exciting one will still be there once the boring one has earned its keep.