What should I do if the requestor does not know what decision they are making?

If the requestor cannot identify the decision the data will drive, it indicates they are on a fishing expedition. Instead of running a query, suggest a quick five-minute call to discuss what they are actually trying to figure out, which often results in a revised request that is significantly less work than the original.

How do I ask clarifying questions without sounding like I am second-guessing the requestor?

Frame your questions as being focused on the deliverable rather than auditing the person's competence. Instead of asking what decision the data is for, ask about the format, such as whether it is going on a slide, a one-pager, or in an email, which provides the necessary context without implying the requestor is unsure of their needs.

Should I use these clarifying techniques with senior stakeholders?

Yes, it is even more important to use these techniques with senior stakeholders because the stakes are higher and rework is more visible. Senior leaders are generally more accustomed to being challenged on their requirements and are often grateful for the clarity, whereas junior requestors may occasionally be more prone to becoming defensive.

How can I handle a manager who expects a fast answer?

You can frame your clarifying questions around scheduling to manage expectations. By asking if the request is needed immediately or by the end of the day, and whether they prefer a slide-shaped or email-shaped version, you gain necessary insight into the required level of polish without appearing to slow them down.

Why is it important to confirm the deliverable before starting work?

Confirming the deliverable in one sentence allows the requestor to correct you before you have invested time in the wrong analysis. This approach turns potential friction into a five-second conversation, preventing hours of rework and protecting your reputation for reliability.

Excel Analysis: Asking Better Questions is Key

Q: Doesn't asking clarifying questions make me look slower?

In the short term, clarifying may seem slower, but it prevents the need for multiple revisions. Over time, you build a reputation for speed because your first answer is the correct one, whereas the person who turns around a request in twenty minutes without clarification often ends up doing two days of rework.

The message arrives at 4:47pm on a Thursday. "Hey, can you pull customer counts by region for last quarter? Need it for my 9am meeting." It's twelve words. It looks like a request for a number, and the obvious move is to open the data, run the query, and send the number.

Two hours later you've sent the number, and the next morning you get a follow-up. "Sorry, what I actually meant was new customers, not total. And by region, by their region, not ours. Can you redo it?" You redo it. Another follow-up arrives by lunchtime. "Also, can we see the quarter before that for comparison?" By the third revision, the person you're working with has clarified that what they really wanted was a churn analysis, and the customer count was a proxy for something they didn't quite know how to ask for.

You weren't slow at pulling data. You were fast at it. The problem is that the person sending the request didn't actually know what they were asking for, and "give them what they typed" was the wrong response to "give them what they need." The career-limiting move here isn't being slow. It's being a fast vending machine, every time.

Why this is structurally harder than it looks

The reason this isn't a personal failing is that no one trains for it. Data work gets framed as a technical job: learn SQL, learn DAX, learn pandas, learn the tools. So that's where the energy goes. The interface skills - how to receive a request, how to translate it, how to clarify it without sounding like you're being difficult - are treated as something you'll pick up by osmosis.

The other reason is incentives. A request answered in twenty minutes feels good for both sides. The requestor got something back fast. You look responsive. The fact that the answer was the wrong answer surfaces hours later, by which point the original transaction has already been logged in everyone's heads as a fast turnaround. The slow, "wait, can I ask you three things about this before I start" response feels worse in the moment, even when it's the version that produces the right answer.

And then there's the social cost. Asking "what decision is this for?" can sound like you're auditing the requestor's competence. Asking "what would change in the meeting tomorrow depending on what number you see?" can sound like you're being obstructionist. Both questions are the right ones. Both are uncomfortable to ask the first hundred times.

The skill, when you watch good analysts do it, is making the clarifying conversation feel useful, not pedantic. That takes practice.

What actually helps

Two things. Both are simpler than they sound and both take a year of repetition to get right.

Ask one question that exposes the decision underneath.

Not five questions. One. The shape that works is: "What changes for you depending on what this number says?" Or: "If the answer is 12,000, what do you do next? If it's 4,000?" The requestor either has a clear answer, in which case you now know exactly what shape the deliverable needs to be, or they pause and realise they hadn't thought it through, in which case you've just saved both of you the two-hour detour. Either way, you learn more in one question than you would in twenty minutes of guessing.

This is also the question that surfaces the assumption that was hiding inside the request. The 4:47pm message above contained at least three: "customer" means active accounts (or does it?), "region" means our internal sales region (or does it?), "last quarter" means the financial quarter (or the calendar one?). The decision question forces those into the open without making the requestor feel cross-examined. They're not being asked to defend their request. They're being asked what they're going to do with the answer, which is a fair question.

Confirm the deliverable in one sentence before you start the work.

Once you've heard the answer to the decision question, paraphrase what you're about to build, in one line, in the requestor's own vocabulary. "So you want active accounts as of 31 March, broken down by the customer's billing region, compared to the same date last year, for the QBR slide tomorrow morning." If you got it right, the requestor says "yes, exactly." If you got it wrong, they correct you in the same message, before you've written a single line of SQL.

The reason this matters is that the correction comes for free at this stage. After you've delivered the wrong thing, the correction costs a re-run, a re-send, and a small but real hit to how reliable you look. Up front, the correction is just a sentence: "actually, billing region is the wrong cut, do it by the rep's region instead." Five seconds of friction prevented an hour of rework.

This week

Pick one request, this week, that you'd normally just answer. When it arrives, write back with the one decision question - "what decision does this number drive?" - and watch what comes back. You'll get one of two reactions. Either you'll get a useful answer that reshapes the work, or you'll get a slightly delayed reply that starts with "good question, let me think about that." Both are wins. The second one means the requestor is doing the thinking that was always going to happen at some point, and now it's happening before you've spent two hours on the wrong query.

That's the close of this month's arc on the work nobody trains you for. Earlier in the month: why nobody knows what you do (May 1), how to talk about your work without bragging (May 8), getting credit for work that looks easy (May 15), and saying no to data requests that aren't really data requests (May 22). Asking good questions is the load-bearing one underneath all of them. The other four are easier when you've got this one.

Frequently Asked Questions

Doesn't asking clarifying questions make me look slower?

In the moment, slightly. Over a quarter, the opposite. The analysts who get a reputation for being fast are the ones whose answers don't need to be redone. The ones who get a reputation for being unreliable are the ones who turn the first thing around in twenty minutes and the third revision in two days. The cumulative speed is what people remember.

What if the requestor genuinely doesn't know what decision they're making?

That's the most useful version of this conversation. It means the request was a fishing expedition, and the right response isn't a number, it's a five-minute call to talk through what they're actually trying to figure out. Those calls almost always end with the requestor saying "actually, what I really need is..." and the new ask is half as much work as the original one. The decision question is the way you find this out without having to schedule a meeting.

How do I ask without sounding like I'm second-guessing them?

Frame the question as serving the deliverable, not auditing the requestor. "What decision is this for" can come across as a challenge. "What's it going on - a slide, a one-pager, an email?" or "Who's the audience for this?" gets you most of the same information without the implicit "are you sure you need this." Both forms work; pick the one that fits your relationship with the person.

Does this work upward, with senior stakeholders?

Yes, and it's more important upward, not less. Senior stakeholders are the ones whose follow-up questions cost you the most time because the stakes are higher and the rework is more visible. The clarifying conversation usually goes better with senior people, not worse, because they're more practised at being challenged on what they actually want. Junior requestors are sometimes the ones who get defensive; senior ones are usually grateful.

What if my manager is the one asking and they expect a fast answer?

Same shape, slightly different framing. "Quick check before I start - want this by 9am or by end of day? And is the slide-shaped version or the email-shaped version more useful?" That's two clarifying questions disguised as scheduling, and you've already learned the most important thing: how much polish does this need. Most "I need it fast" requests need less polish than the default, not more.

Is there a script for this?

No, and the analysts who try to use one always sound stilted. The shape stays the same - one decision question, one paraphrased confirmation - but the words come from your own relationship with the person and your own way of talking. The script you'd build would be brittle. The pattern, internalised, holds across people.