2.1 Framing the Right Question
Before you even look at the data, get clear on the question your analysis needs to answer.
A useful question is not just interesting. It is tied to a real decision: who will do what differently if the analysis changes their mind?
In this chapter, I will walk through how to turn a vague request into a concrete business question, and then break that down into testable hypotheses.
Defining the Key Business Question
Before starting any analysis, ask yourself:
“As a result of this analysis, who in which department will take what action, and when? How much business impact can we expect from that action?”
If you can answer this concretely, the analysis is probably worth doing. If not, you are likely heading into a fishing expedition—wandering through data and hoping something useful turns up.
A useful business question passes three tests:
- Answerable — Can we answer it with available data before the decision deadline?
- Actionable — Can we name the owner and the decision it will affect?
- Worth it — Is the expected impact worth the analysis effort?
From Raw Request to Business Question
Most analysis requests do not arrive as clear business questions. They usually start out vague.
The analyst’s job is not to take the request at face value. The real job is to translate that request into a decision.
| Raw request | Better business question | Possible decision |
|---|---|---|
| Can you pull sales by channel? | Which channel explains the revenue gap? | Change next quarter’s budget allocation |
| Why is revenue down? | Which customer group, product category, or channel is driving the decline? | Decide which owner should act this month |
| How did the campaign perform? | Should we increase, maintain, or reduce spend on this campaign? | Reallocate campaign budget |
| Can you check retention? | Which customer cohort is at risk? | Launch a reactivation campaign |
The raw request tells you what data someone wants. The business question tells you what decision the analysis should change.
Hypothesis-Driven Design
Once you have a clear question, do not jump straight into the data. A question by itself is still too broad. Before you write any SQL, form specific hypotheses to narrow your search.
For example, instead of asking ‘Why is revenue declining?’, break it down: ‘Is new customer acquisition falling?’, ‘Are repeat rates dropping?’, or ‘Is average order value down?’. Before you pull any data, sketch out what the answer would look like. Ask yourself: ‘If this hypothesis is true, what chart or number would actually convince the decision-maker?’. Even a quick hand-drawn slide is enough. If you cannot sketch the output, your question or hypothesis is still too vague.
The key is not to think while you search. Lay out your hypotheses and possible conclusions first, then focus only on the validation you need. If the data contradicts your hypothesis, change course immediately. The moment you start cherry-picking data to fit your idea, you have left analysis and entered confirmation bias.
A simple template is enough:
Business question:
Hypothesis:
Metric to test:
Output needed:
Possible decision:For example:
- Business question: Why did Q4 revenue miss plan?
- Hypothesis: Existing customers purchased less frequently.
- Metric to test: Purchase frequency by customer cohort versus last year and versus plan.
- Output needed: Cohort-level trend chart with the largest gap highlighted.
- Possible decision: Launch a reactivation campaign for the affected cohort.
This template keeps your analysis from drifting. If you cannot fill it in before pulling data, your question is probably still too vague.
The workflow is simple: Question → Hypothesis → Output design → Data → Analysis → Decision. The important point is the order — start with the question, not the data.