AI Isn't Your First Problem

Many conversations about AI begin with a tool and work backwards in search of a use. A leadership team sees a demonstration, feels the pressure of competitors who appear to be moving faster, and asks: where can we put this? It is an understandable question. It is also the wrong first question.

The more useful question is older and less exciting: what is actually not working, for whom, and what does it cost us to leave it that way? Until that is answered with some precision, any AI project is a solution looking for a problem — and those projects are hard to evaluate, hard to fund honestly and easy to abandon.

Symptoms are not problems

"Our customer service is too slow" is a symptom. The underlying problem might be that requests arrive through five channels, that half of them need information held by one person, or that approvals sit in an inbox for days. Each of those has a different remedy. Only some of them involve AI. Several are solved better by a clearer process, a shared record or a changed responsibility.

When a symptom is treated as the problem, teams tend to automate the visible part of the work and leave the cause intact. The result is often a faster version of a broken process.

Why problem definition is a leadership task

Defining the problem means making choices: which outcome matters most, which trade-offs are acceptable, who owns the result. Those are not technical decisions. Delegating them to a vendor or an internal technical team usually means they are made implicitly — by whatever the chosen tool happens to do well.

Clarity before commitment: if you cannot describe the problem in two sentences without naming a technology, it is too early to buy one.

A practical way to start

• Describe the work as it happens today, step by step, including the workarounds people rarely mention.
• Name where time, money, risk or customer goodwill is actually lost — and how you know.
• Separate what must be true (rules, obligations, quality) from what is merely habit.
• Only then ask which parts are candidates for automation, assistance or simply a better process.

Sometimes this exercise shows that AI is exactly the right lever. Sometimes it shows that the problem is small, or that a simpler change gets most of the value. Both are good outcomes. The expensive outcome is committing budget before you know which one you are in.

Build a decision brief, not a technology wish list

A useful executive brief has five parts: the affected work, the observed friction, the desired outcome, the constraints and the decision to be made. Write each in ordinary language. An illustrative example, not a client case, is an order team that repeatedly contacts customers for missing information. The question is not whether an agent can write those messages. It is whether better intake, clearer product rules or assisted follow-up will remove the delay without introducing unacceptable mistakes.

Keep observations separate from explanations. A queue that grows every Monday is an observation. Insufficient staffing is one possible explanation; uneven demand, incomplete inputs and delayed approvals are others. Ask what evidence would distinguish them before selecting a remedy. This prevents the loudest stakeholder's preferred solution from becoming the definition of the problem. It also makes disagreement productive: people can challenge an assumption rather than defend a technology.

Use four gates before authorising a pilot

• Reality gate: can the team show representative records of the friction, rather than only a memorable complaint? Record what is unknown as well as what is known.
• Leverage gate: would changing this step improve the end-to-end outcome, or merely move the queue somewhere else? Trace the next handoff and its capacity.
• Alternatives gate: compare doing nothing, changing the process, conventional automation and AI assistance. Give each the same outcome and constraints to satisfy.
• Readiness gate: identify the owner, authoritative information, review capacity and stop conditions. If these are absent, make readiness work the next step rather than disguising it as a pilot.

These gates are decision aids, not a scoring formula. A high-value opportunity may still be unready because the organisation cannot judge whether an output is correct. A modest opportunity may deserve a small experiment because it is bounded and reversible. Avoid combining those distinctions into a single attractive score: value, confidence and readiness answer different questions and should remain visible to the person approving the work.

Find the constraint before accelerating the task

Suppose drafting a response becomes faster but every response still waits for the same manager's approval. The local task improved; the customer experience may not. Ask where the limiting constraint sits, who controls it and whether a proposed change will relieve it. If an approval exists for a legitimate reason, removing it is not a productivity gain until the risk is addressed. If it exists only from habit, a policy decision may outperform a new tool.

End the first review with a small, explicit decision: proceed to a bounded test, gather missing evidence, repair the process first, or stop. Name the next owner and the evidence required to revisit that decision. This is how discovery creates standalone value. Leadership does not need to buy something to leave with a clearer understanding of what is wrong, what matters and what can safely wait.

If a pilot is justified, define its decision criteria before starting: From AI Pilot to Proven Business Value.