Get Started
Chapter 28 min read

Asking Questions Worth Answering

The quality of an analysis is set by the question, not the technique. How to move from vague curiosity to something answerable, and how to avoid confirming what you already believed.

'Analyse this data and tell me what is interesting' produces a summary of column averages that nobody acts on. It is the most common request and the least useful one, because interestingness is not a property of data — it is a property of a decision you are trying to make.

From vague to answerable

A good question names a comparison, a population and a time window, and implies what you would do with either answer.

  • Vague: 'How are sales doing?' → Answerable: 'Did revenue per customer change after the March price increase, comparing the three months either side?'
  • Vague: 'Which marketing works?' → Answerable: 'Of customers acquired last quarter, which channel has the highest 90-day repeat purchase rate?'
  • Vague: 'Are people happy with support?' → Answerable: 'Did the proportion of tickets resolved within 24 hours change after we added the second agent in June?'

Pre-commit to the method

State how you will measure before you see the result. Otherwise you will try segmentations until one shows what you hoped, which is a well-documented way to be sincerely wrong.

This is the discipline that separates analysis from advocacy, and it costs one sentence written down in advance.

A briefing that produces real analysis

Analysis prompt

Dataset: order-level sales, Jan 2024 – Jun 2025.
Columns: order_id, customer_id, order_date, channel,
amount_npr, is_repeat.

Question: did average revenue per customer change after our
price increase on 1 March 2025?

Method I want:
- Compare Dec 2024–Feb 2025 against Mar–May 2025
- Revenue per customer, not total revenue (customer count
  changed between periods)
- Report both periods, the absolute and percentage difference,
  and the number of customers in each

Also tell me:
- Anything about the data that makes this comparison unsafe
  (seasonality, a channel mix shift, missing rows)
- What the result would NOT prove

Write the code, show it, and show the intermediate numbers.
Do not just give me the conclusion.

Ask what would change your mind

After you have a result, ask directly for the case against it: what else could produce this pattern, what is missing from the data, what a sceptic would say. Models are agreeable by default and will support your framing unless you explicitly ask them not to.

The strongest single instruction in analysis work is 'argue the opposite of what I just concluded, using this same data'.

Segment carefully

Slicing data into groups is where insight lives and where false findings breed. Every extra cut makes it more likely that something looks significant by chance alone.

Two safeguards, both cheap: decide the segments that matter before looking, and check the group size on anything surprising. A dramatic pattern in eleven customers is not a pattern.

What to take from this chapter

  • A good question names a comparison, a population and a time window
  • Write down what you will do for each possible answer before you run anything
  • Pre-commit to the method so you cannot hunt for a flattering segmentation
  • Ask what the result would not prove, and ask the model to argue the opposite
  • Check group sizes before believing any pattern in a small segment

Try it

Take a question you want answered about your own work. Rewrite it with a comparison, a population and a time window, then write the two actions you would take for each outcome. If they are the same, pick a different question.