The demo arrives via email. Fifteen slides, five use cases, three customer logos. The founder has already replied to the vendor’s follow-up before you have opened the original message.
In many founder-led businesses handed an AI mandate, the sequence runs in reverse. The tool arrives first. The problem it is supposed to solve arrives later, or not at all.
What is problem-first AI selection?
Problem-first selection is a working discipline for any delegate leading AI adoption. Before any tool is discussed, scoped, or budgeted, you name the concrete operational problem it must solve. The selection question then becomes whether AI is the right answer for that specific problem, and whether this particular tool is the right form of AI. The tool is the last decision in the sequence.
The opposite pattern has a name in the research, AI theatre. The phrase describes projects that look convincing at demo stage and produce nothing measurable three months later. They start with a tool, then search for a workflow to demonstrate it on. That search tends to land on whatever is visible and accessible rather than whatever matters to the business.
Problem-first selection short-circuits AI theatre before it starts. The question is simple and can be asked at any stage of the conversation. What is the specific operational problem this is solving, and is AI genuinely the right answer for it? Starting there changes the shape of every vendor meeting and every founder conversation that follows.
Why does tool-first thinking break AI projects?
The core failure is that tool-first AI tends to automate whatever already exists, including the broken parts. When a team asks what a tool can do for them, they map current workflows to its available features and deploy against those. If the underlying workflow is inefficient or built on a bad assumption, AI speeds it up. The result is faster waste, not less of it.
BCG’s research on enterprise AI adoption found that usage rates have climbed while measurable business impact has stalled. That gap is partly explained by this pattern. Teams use AI tools, sometimes extensively, but the usage is not translating into outcomes because it was never tied to a specific business problem that mattered.
The ROI patterns in AI adoption make this worse. Research consistently shows that the areas attracting the largest share of AI investment, typically sales and marketing automation, produce the weakest returns. The areas with the highest returns, back-office process work like document handling, reporting, and reconciliation, attract the least funding. The explanation is partly that sales demos are more compelling than accounts-payable demos. Tool-first selection favours the compelling demo over the high-value problem.
Korn Ferry’s research on AI readiness adds a further dimension. Leaders who focus on deploying tools for efficiency gains rather than building underlying capability see consistently lower adoption rates. The tool-first instinct fails on two levels, picking the wrong problems and building nothing durable.
Where will you actually run into tool-first pressure?
Tool-first pressure comes from two directions. Vendors arrive with polished demos, reference customers, and a feature list mapped to common pain points. Founders arrive with a specific product seen at a conference or read about in a peer group, and they are often not asking for your analysis. They want your endorsement. Both situations share the same structure. The tool has already been chosen.
The delegate’s role in these scenarios is to hold the question open without killing the momentum. That is harder than it sounds. Founder enthusiasm for a specific product is often political. They may have already mentioned it to the board, or spoken to the CEO at a peer firm who uses it. Vendor pressure is commercial by design. The demo was built to make the use case look obvious, and the follow-up cadence assumes a yes.
Putting the problem question on the table first tends to work better than pushing back on the tool directly. You might say something like, “That looks like it has real capability. Before we scope it, what’s the specific workflow problem we’re solving with it? If we can name that clearly, we can judge whether this is the right fit.” The conversation changes shape as soon as the problem is on the table. If the problem is genuine and well-understood, the initiative has a foundation. If nobody can articulate it clearly, you have your answer before spending anything.
When should you apply the “would it still matter without AI?” test?
Apply it before any scoping conversation, vendor negotiation, or internal budget pitch. Addepar’s guidance for executives evaluating AI adoption frames the test simply. Would this initiative still matter if it did not use AI? A no means the project has no business foundation. A yes means you have a real problem worth pursuing, and AI may be one route to solving it.
The test works on both new proposals and existing initiatives. If something is already scoped or in pilot, run it against what the initiative was originally designed to achieve, stripped of all technology. “We wanted to reduce the time the finance team spends on month-end reconciliations.” That statement stands without AI. The technology question then becomes whether AI is the fastest, most reliable, and most cost-effective route to that specific outcome.
The question also gives you a neutral redirect when a founder or vendor is already committed to a product. Asking what problem the investment is solving is not confrontational. If they can answer it well, the initiative has a genuine case. If they struggle to name the problem clearly, the filter has done its job without requiring a disagreement.
What connects to the problem-first discipline?
Problem-first selection is an entry point to a broader assessment sequence, not a standalone technique. Confirming the problem is real and worth solving comes before data readiness, capability gaps, and cost are assessed. This discipline belongs at the front of the first 30 days of an AI mandate, before any tool is scoped, any pilot is designed, or any vendor is shortlisted.
The assessment question that follows immediately is readiness. Does the business have the data quality, the process documentation, and the internal ownership to support an AI-led change in this specific area? Research consistently identifies poor data quality as the most commonly cited barrier to successful AI implementation. If the problem is real but the underlying data is not ready, the next step is data preparation, not tool selection.
After readiness comes prioritisation. An AI mandate typically arrives with more candidate problems than the team can address at once. Problem-first discipline gives you a consistent framework for comparing them, asking whether each problem is real, whether the business is ready, and whether AI is genuinely the right solution. Those three questions applied consistently produce a shortlist you can actually deliver.
The discipline also carries forward into ongoing governance. As AI rolls out across a business, departments bring their own requests and their own vendor relationships. A simple intake process that starts by asking what business problem this initiative is solving means every new proposal enters the same filter, not just the ones you personally review. The question does not get harder to ask with practice. It gets easier.
If you are still finding your footing on the AI mandate, a conversation with someone who has mapped this territory is worth having. Book a conversation to talk through where your programme stands.
