How do you convert an ambiguous stakeholder request into a measurable analytical problem?
Requests arrive as sentences like "can you look into why sales are down". That is a topic, not a question. Converting it into something answerable is the skill interviewers are testing, because an analyst who starts querying immediately usually delivers a correct answer to the wrong problem.
Start from the decision — ask what action the answer will trigger and who owns it; if no decision changes on any result, the request is curiosity and should be scoped or declined accordingly.
Define the metric precisely — "sales" must become gross or net, booked or recognised, which statuses count, whether refunds and cancellations are deducted, and in which currency.
Pin population and time window — which customers, regions, channels and products are in scope, over what period, and compared against which baseline (prior period, same period last year, or plan).
Agree the decision threshold — ask how large a change would matter; this separates statistical noise from a business-relevant result and stops a 2% movement from triggering a reorganisation.
Write it back and confirm — restate the question, metric, scope, baseline, deliverable and deadline in two or three sentences and get explicit agreement before any query runs.
Key terms: problem statement, decision-driven analysis, metric definition, scope, baseline, decision threshold, success criteria, scope creep
The best answer is a demonstration, not a description — take the vague example the interviewer gives and actually ask the clarifying questions out loud: what decision, which definition of the metric, which population, over what window, against what baseline, and how big a change would matter. Candidates who list "I gather requirements" sound generic; candidates who ask "what will you do differently if the answer is yes?" sound like they have run these conversations.
Expect a follow-up where the stakeholder cannot answer or wants everything — the right response is to propose a narrow first version with a deadline and iterate, not to refuse. Always finish with writing the problem statement back for confirmation.