Turning a request into a question

You will receive requests that look like specifications and are not. "Can you pull revenue by region for Q3?" arrives looking complete. It is missing: which revenue, which regions, gross or net, booked or recognised, in what currency, at what exchange rate, including or excluding the refunds that were processed in Q4 for Q3 orders, and — the important one — what happens next depending on the answer.

If you just run the query, you will produce a number, and there is a good chance it is the wrong one. Worse, it will get repeated in a board deck and become the number.

The five questions#

Ask these before opening a query editor. They take four minutes and routinely save four days.

1. What decision does this change? If there is no decision, you may still do the work — sometimes curiosity is legitimate, sometimes it is a board slide — but you should know, because it sets how much precision is worth buying.

2. What would you do if the answer were the opposite? This is the sharpest of the five. If both answers lead to the same action, stop. You have found a request that does not need to exist, and saying so politely is a genuine contribution.

3. What is the unit? Per user, per session, per order, per account, per day? This is the grain question from the previous lesson, wearing business clothes.

4. What is the comparison? A number alone is never informative. "Revenue was 4.2M" means nothing until you know whether the honest comparison is last quarter, the same quarter last year, the forecast, or a control group. Choosing the comparison is doing most of the analysis.

5. When do you need it, and how good does it need to be? A rough answer today usually beats a precise one next week, and stakeholders are almost never asked which they want.

Write the sentence before you write the query#

Before touching data, write the sentence you expect your result to complete:

Among [population], [metric] was [value] over [period], compared with [comparison].

Filled in: Among accounts that signed up in 2023, twelve-month retention was 61%, compared with 54% for the 2022 cohort.

That single sentence has now forced you to define the population, the metric, the window, and the comparison. Write it into the ticket. Send it back to the requester before you start. Roughly a third of the time they will say "oh — actually I meant something else", and you have just saved a day.

Scope creep has a specific shape#

It nearly always arrives as "while you're in there". While you're in there, can you also split by channel? And add last year? And can it be a dashboard?

The healthy response is not refusal, it is sequencing: "Yes — the first cut answers the retention question by Thursday. Channel splits are a separate piece; do you want them instead of, or after?" This converts an unbounded request into an ordered one without a fight.

Say the caveat once, loudly, at the top#

Analysts bury caveats at the bottom where nobody reads them, then feel wronged when the number is misused. Put the load-bearing caveat in the first sentence, in plain language:

This counts orders, not shipments, so returns are not netted out. On that basis, Q3 was up 8%.

One sentence. Not a methodology appendix. If a caveat is important enough to affect the decision, it goes above the number; if it is not, it goes in a footnote or nowhere at all.

Delivering the answer#

The format most likely to be read and least likely to be misread, in order:

1. The answer, in one sentence. Not the approach. The answer.
2. The load-bearing caveat, if there is one.
3. The supporting chart or table — one, not six.
4. What you would do next, if asked.
5. Everything else, linked rather than pasted.

Almost every analyst does this in the reverse order, opening with methodology and arriving at the answer in paragraph nine. Nobody reads paragraph nine.