In 30 seconds

People often arrive with a solution already chosen: "We need an AI chatbot." The solution hides the problem. Ask what goes wrong today and what it costs before deciding what to build.

The right solution is much easier to find once the problem is clear.

Why this comes up

A solution is concrete and exciting. A problem is vague and frustrating. So people describe the solution and assume the problem is obvious.

But the stated solution is a guess. If you build it directly, you may automate something that was never the real bottleneck.

Get to the underlying problem

When someone names a solution, ask what it would fix.

Now you have a problem: two people are a bottleneck for routine questions. An assistant is one possible answer. So is a better-organized handbook, or a shared list of common answers. You can now compare options instead of committing to the first one.

Look for the symptom behind the symptom

"The report is always late" might really be "the data arrives late from another team," which might really be "nobody owns the handoff." Follow the chain until you reach something you can actually change.

Estimate the cost, roughly

You do not need a precise number. You need to know whether this is worth solving.

  • How often does it happen?
  • How much time or money does each occurrence cost?
  • What is the impact when it goes wrong: a delay, a complaint, a financial error?

A frequent, cheap-to-fix problem is often a better first project than a rare, dramatic one.

What this does not solve

Understanding the problem does not tell you whether AI is the right fit. It tells you what "right" would mean. The fit question comes later, in deciding whether a workflow needs AI.

Good enough to move on when

  • You can state the problem without naming a technology.
  • You know roughly how often it happens and what it costs.
  • You have separated the symptom from the underlying cause.