The marketing lead went first: a chatbot for the support queue. Then operations: automated scheduling. Then sales: lead scoring, call summaries, proposal drafts. By the time the meeting ended, the whiteboard had something like forty bullet points under the header “AI opportunities,” and nobody in the room could say where to start with AI, or which three items mattered. This is not a failure of imagination. It is what happens the moment a leadership team accepts, correctly, that large language models can touch almost any task involving text, pattern recognition, or repetitive judgment calls. Once everything is technically possible, nothing is obviously first.
That gap between possible and prioritized is where most AI initiatives actually die, not in the technology but in the sequencing.
When every idea is technically possible
The constraint that used to narrow the list, namely what the technology could even do, has mostly disappeared. What is left are organizational constraints: time, budget, risk tolerance, and who owns the problem. A company evaluating AI today is not choosing between options that work and options that don’t. It is choosing among dozens of things that would plausibly work, which is a harder decision, not an easier one.
This is why so many pilot programs stall after the first demo. The demo answers “can this work,” which was never really in doubt. It does not answer “should this be the first thing we automate.” That second question needs information the demo cannot supply: how often the task actually recurs, who gets blamed when it goes wrong, and whether the team doing it today would even want it gone.
The first filter is ownership, not enthusiasm
The candidates worth pursuing first are the ones with a single, identifiable owner who feels the pain weekly and has the authority to change the process without a committee vote. Enthusiasm from a department that merely touches the task is a weak signal. Ownership from the department that lives with it every week is a strong one.
A lot of AI shortlists get built backward. Someone reads about a use case, gets excited, and goes looking for a department to apply it to. The order that actually works runs the other direction. Start with the person who already complains about a specific task, confirm they have the standing to change it, and only then ask whether AI is the right tool for that specific complaint. Sometimes it isn’t. A scheduling bottleneck caused by three people needing to approve the same form is a process problem before it is an AI problem, and no model fixes an approval chain.
A two-week trial beats a six-month roadmap
The fastest way to separate a real candidate from a plausible one is to run a two-week trial against a narrow, measurable task. That beats writing a roadmap document that tries to sequence all forty bullet points at once. A roadmap answers questions nobody has asked yet. A trial answers the one question that matters this month.
This is the part teams resist, usually because a roadmap feels like due diligence and a two-week trial feels like skipping steps. It is the opposite. A roadmap built before anyone has touched the tool is a guess dressed up as a plan. A trial produces a number: how many support tickets actually got resolved without escalation, how many hours a week the task genuinely freed up, how many times the output needed a full rewrite versus a light edit. Those numbers either justify the next investment or they don’t, and either answer is useful. A six-month roadmap that nobody tested against reality is useful to no one, including the vendor selling it.
Why the first choice is a technical judgment, not a vendor demo
Deciding which candidate goes first is a judgment about integration cost, data readiness, and failure consequences. It should not be outsourced to whichever vendor gave the best sales pitch. The task with the flashiest demo and the task with the lowest integration cost are rarely the same task.
This is the gap an outside technical lead often gets brought in to close: someone who can sit with the forty bullet points, ask which ones touch systems that are actually ready, and say no to the nine that would take four months of data cleanup before a model could do anything useful. Kody Doherty, a fractional CTO who runs AI opportunity reviews for companies at exactly this stage, has more on where to start with AI. The value isn’t picking the most impressive use case. It’s picking the one the organization can actually finish.
What changes after the first decision gets made
Once one candidate has been through a real trial, with real numbers attached, the next nine decisions get faster. The team now has a template for what evidence looks like instead of a template for what sounds exciting.
That is the actual payoff of starting small on purpose. It is not that the first project changes the business, because a single two-week trial rarely does. The payoff is that the organization learns how to tell a real candidate from a plausible one. That skill, unlike any individual tool, keeps paying out long after the whiteboard gets erased.
