Framing the problem
Customers usually arrive with a solution in mind: "we need a chatbot," "we want to fine-tune a model," "we need an agent." Your job is to find the problem underneath, frame it so success is measurable, and check that the requested solution is actually the right one.
From request to problem
Ask "why" until you reach something the business cares about in its own terms — time, money, risk, revenue or customer experience.
"We want a chatbot for our policy documents." Why? — "Support agents spend too long searching for answers." Why does that matter? — "Average handling time is high and customers wait." What would good look like? — "Agents find the right answer in under a minute."
Now the problem is reducing time-to-answer for support agents, and a chatbot is one possible solution among several (better search, a curated FAQ, an assistant inside the ticketing tool).
A problem statement template
<User group> currently <does task> by <current method>,
which takes <time/cost> and results in <pain/error>.
We will consider this solved when <metric> moves from <baseline> to <target>
within <timeframe>, measured by <data source>.
If you can't fill in the baseline, discovery isn't finished.
Choosing the success metric
Good metrics are tied to the business, measurable from data you can access, and sensitive enough to move within the pilot.
| Metric type | Example | Use it for |
|---|---|---|
| Outcome (lagging) | Cost per claim, customer satisfaction | The business case and executive reporting |
| Operational (leading) | Handling time, cases per agent per day | Day-to-day progress during the pilot |
| Quality | Accuracy against a reviewed sample, escalation rate | Guarding against faster-but-worse |
| Adoption | Weekly active users, % of cases using the tool | Knowing whether people actually use it |
Always pair a speed or cost metric with a quality metric. "Twice as fast" means nothing if accuracy dropped.
Is AI the right tool?
Part of your value is saying when a simpler approach wins.
| If the task is… | Consider first |
|---|---|
| Deterministic and rule-based | Plain code or a rules engine |
| Finding known documents or records | Search (keyword, hybrid) and better data hygiene |
| Predicting a number or class from structured data | Classical ML |
| Understanding or generating unstructured language | LLMs — prompting, RAG or tool use |
| Multi-step work across systems with judgement | LLM with tools, behind strong guardrails |
Recommending the simpler option builds enormous credibility — and often leaves room to bring in AI where it genuinely adds value.
Prioritising among several problems
Discovery usually surfaces more problems than you can tackle. Score each on value (size of the pain, strategic importance) and feasibility (data availability, integration effort, risk), then start with high-value, high-feasibility work. A fast, visible first win buys the trust and budget for harder problems later.
When two problems are close, pick the one whose users are most eager. Enthusiastic users give feedback, tolerate rough edges and become your champions.
In decomposition cases, interviewers watch for this move: you reframe the stated request into a measurable problem, propose a metric with a baseline, and consider non-AI alternatives before designing anything.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.