The one idea
An analysis is not finished when you have numbers. It is finished when someone can make a decision they could not make before.
So the first thing you produce is not a chart. It is one sentence:
We are deciding whether to ___, and this analysis will tell us ___.
If you cannot fill in both blanks, you are not ready to open the file. Go back and ask.
Before looking at data, work out what someone is going to do differently depending on what you find.
Convert a vague request into a specific question, name the decision it informs, and agree it with the requester before you build anything.
Define the population, the metric, the time window and the comparison baseline. An analysis without a defined comparison produces a number that cannot be interpreted.
The mental model
A vague request becomes answerable when you have pinned down four things. Miss any one of them and the answer is unusable.
| Piece | The question you ask | "Look into sales" becomes |
|---|---|---|
| Population | Which rows count? | Retail orders only, excluding staff purchases and cancellations |
| Metric | What exactly do we measure? | Net revenue after discount and returns — not order count |
| Window | Over what period? | Jan–Mar 2026, compared with Oct–Dec 2025 |
| Comparison | Compared to what? | Same quarter last year, because December is always high |
The comparison is the one people skip, and it is the one that makes a number mean anything. "Revenue was 42 lakh" is not information. "Revenue was 42 lakh, against 51 lakh in the same quarter last year" is.
Why most analysis fails before the tool is opened
Three failures, in the order they happen.
Answering the question as asked
"Look into sales" is not a question. It is a feeling that something is off. Your job is to find the question underneath it. The person asking often cannot articulate it — that is normal, and it is not their failure. It is the work.
Not knowing what would change the answer
Ask yourself: if the number came out high, what would we do? If it came out low, what would we do? If the answer to both is "the same thing", the analysis does not matter, and you should say so rather than spend three days on it.
Not agreeing the question in writing
You clarify verbally, you go away, and by the time you present, the question in your head and the question in theirs have drifted apart. One short message before you start prevents this entirely.
Request: "Can you find out why support tickets went up?"
Weak start: opening the export and sorting by date.
Strong start: "Before I dig in — are we deciding whether to hire another support person, or whether something broke in the product? Those need different cuts. I would guess the second, so I would look at tickets by category and product version for the last eight weeks against the eight before. Does that match?"
Two minutes, and it saves two days. It also makes you look like someone who thinks, rather than someone who fetches.
You are asked in an interview: "How would you find out if our marketing spend is working?"
The weak answer lists tools. The strong one starts: "It depends what decision it feeds. If it is whether to increase next quarter's budget, I would want spend and new customers by channel, and how long someone takes to convert — spend in March may show up as customers in May. If it is whether to cut one channel, that is narrower."
You have not touched any data and you are already ahead.
Turning a vague request into an answerable question
1 of 6Write down the request in their exact words. "Sales have been weird this quarter — can you look into it?" Keep it. You will compare your final question against it to check you did not drift somewhere more convenient.
Try this
Your manager sends: "The website numbers look bad. Can you check?"
Write down four questions you would ask before opening anything.
Your challenge
Level 3 · IndependentTake a real vague request you have received at work or in study — or use "how are we doing on customer retention?"
Produce a written brief of no more than 150 words containing: the decision this informs, the population, the metric defined in words, the window and comparison, and one sentence saying what result would point which way.
Success test: hand it to someone who does not know the topic. They should be able to tell you what you are about to measure, and what you would conclude if the number came out high.
What people usually get wrong
- Opening the data first. The data suggests questions it can answer, which are not necessarily the questions that matter. You end up reporting whatever was easy to count.
- Accepting "just have a look". It feels cooperative. It guarantees rework.
- Not defining the metric in words. "Active users" has caused more pointless meetings than any other phrase in business.
- Choosing the comparison after seeing the result. If you pick the baseline that makes the number look best, that is not analysis, it is decoration.
- Silently excluding rows. Dropping refunds may well be right. Dropping them without saying so makes every number you produce unverifiable.
- Answering a question nobody asked because it was more interesting. Do the asked question first, then offer the interesting one as a note at the end.
How someone experienced does it
Experienced analysts ask one more question: what would change your mind? It reveals whether the decision is genuinely open or already made and looking for support. Both are worth knowing. If it is made, you can stop pretending it is analysis and write the summary they actually need.
They also state the expected answer before running anything. "I expect revenue down roughly 10%, mostly in the North" costs thirty seconds. If you are right, the analysis is quick to trust. If you are badly wrong, you have found something real, rather than a data error you would have quietly explained away.
And they size the work to the decision. A question worth fifty thousand rupees does not get a week. Say what you can answer in two hours, and offer the deeper version only if that is not enough.
When not to use this
Do not run this whole process on a five-minute question. If someone asks how many orders came in yesterday, look it up and tell them.
The framing work earns its place when the request is vague, when the answer will be shown to someone else, or when getting it wrong means redoing it. Those are exactly the cases where people skip it.
Prove it
Write a one-page brief for an analysis you have not yet done: the decision, the population, the metric, the window, the comparison, your expected answer, and how long it will take.
Send it to the person who asked, before doing the work. Their reply — even if it is "no, I meant something else" — is the proof. That correction is the entire value of the exercise.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned turning a vague data request into a specific answerable question. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood turning a vague data request into a specific answerable question. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at framing an analysis question before touching data — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.