# The use-case selection mistakes that doom AI pilots _Most doomed pilots were doomed at selection. They chased the shiny problem, added tooling that produced work instead of results, and confused activity with progress._ The use-case selection mistakes that quietly doom AI pilots, from chasing hype to adding tools that produce work instead of results. An anonymized story from a cybersecurity CEO on clarity over noise. # The use-case selection mistakes that doom AI pilots By the time a pilot is clearly failing, most people go looking at the model, the data, or the team. The decision that actually doomed it happened earlier and quieter, when the use case was chosen. A few selection mistakes show up again and again, and they all feel reasonable in the moment. A useful discipline here: even when you plan to build, pilot the leading off-the-shelf option for 60 to 90 days first. It tells you what "good" looks like, what the real requirements are, and whether the problem is worth solving at all before you commit to owning it. ## The mistakes that look like ambition A cybersecurity CEO whose firm protects mission-critical payment systems described a pattern that maps directly onto AI selection. His customers, he said, rarely complain about attackers first. They complain about complexity. Too many tools, too many dashboards, too many reports that generate work without reducing risk. His line stuck with me: most teams are not short on products, they are short on clarity about what they actually need to do. That is exactly how use cases get chosen badly. A team adds an AI feature because it is impressive, not because it removes a real problem, and ends up with more surface area and no less pain. He was just as sharp about hype. AI, he pointed out, did not invent new attacks, it made average attackers better at the ones that already existed. The lesson for selection is to be suspicious of any use case whose main appeal is that it is new. Novelty is not impact. A pilot chosen for how modern it sounds usually solves a problem nobody was actually losing sleep over. The doom pattern, then, is a use case picked for spectacle, wrapped in tooling that produces dashboards instead of outcomes, defended because it demos well. It survives review meetings and dies in production. His point about clarity is the one to hold onto. A team drowning in tools is not confused about which product to buy next. It is confused about what problem it is actually trying to solve. AI selection goes wrong the same way. The question is never "what could AI do here," because the answer is always "a lot." The question is "which specific pain, felt by which specific team, is worth removing first." A use case that cannot answer that in one sentence is a use case chosen from a menu of possibilities rather than from a real problem, and it will produce exactly the kind of impressive, unused feature that makes leadership skeptical of the next request. ## How to select against the pattern Catch these before you commit engineering time. - **Solve a felt problem, not a fashionable one.** If no team is losing sleep over it today, it will not fund itself later. - **Count outcomes, not tools.** A use case that adds dashboards but not decisions is adding complexity. - **Discount novelty.** "It is new" is not a business case; "it removes this cost" is. - **Benchmark with off-the-shelf first.** A short trial of an existing tool exposes fake use cases cheaply. ## How we approach it at Density Labs Half of the AI Readiness Assessment, our $2,500 engagement, is telling teams which use cases not to pursue. We screen each candidate for a real, felt problem and a measurable outcome, and we flag the ones that are mostly novelty or mostly new tooling. When a good off-the-shelf option exists, we say pilot that for a couple of months before you decide to build, because it is the cheapest way to learn what the problem actually demands. A doomed pilot rarely dies of a technical cause. It dies of a use case that was chosen for how it looked, not for what it fixed.