Stakeholder Translation: Turning Vague Asks Into Shippable Analyses

The Slack DM hit at 4:47pm on a Friday. "Hey, can you pull churn for me? Need it by Tuesday." Eight words. I closed my laptop, started my weekend, and Monday morning I wrote the cleanest cohort query of my career. Logo churn by month, last 18 months, segmented by acquisition channel. Twelve hours of work. Tuesday at 9am I dropped the chart in the channel.

The VP wrote back: "This is overall churn. I needed it sliced by tenure cohort within each ARR band. The QBR is in 90 minutes."

Three days. Wrong answer. The QBR slide stayed empty.

That was the most expensive lesson I learned in my first year as an analyst, and the one almost nobody teaches you. Most analyst burnout isn't from hard SQL. It's from re-doing work because the brief was 9 words long and you didn't push back. Translation (turning a Slack DM into a scoped, decision-driving analysis) is the single highest-leverage skill an IC analyst can build in year one. SQL is the easy part. Scoping is the job.

Here's the system I wish someone had handed me at week four.

The Intake Form: Five Fields, Non-Negotiable

Before you open your IDE, before you write a single SELECT, you fill out an intake form. I keep mine as a Notion template and paste it into the requester's DM the moment a vague ask lands. If they won't fill it out, the work doesn't start. This isn't gatekeeping. It's the only way you ship the right thing.

The five fields:

The actual problem behind the question. Not "we want churn numbers." The problem is "Q1 net revenue retention dropped 4 points and the board wants a story by Thursday." The question is the symptom. The problem is what you're actually solving.
The decision this analysis will inform. "We're choosing whether to invest $400K in a customer success expansion in Q2." If there's no decision attached, the analysis is theater. More on that later.
The success metric and the threshold. Not "we want to know churn." Specifically: "if logo churn in the SMB segment is above 8% annualized, we'll cut the SMB acquisition budget by 30%." Numbers and thresholds. If they can't give you a threshold, the analysis isn't ready to start.
Every stakeholder who'll see the output. Your VP of CS asked, but the slide is going to the CEO and the board. That changes the chart, the caveats, the level of polish, and the audit trail. Find out before you build.
The deadline and what happens if you miss it. "Tuesday EOD" is not a deadline. "Tuesday 10am because the QBR starts at 11" is a deadline. And the consequence of missing (the QBR slide stays empty, the board meeting goes ahead without it, the budget call gets pushed a quarter) tells you how much overtime is justified versus how much you should push back on scope.

Copy-paste this into your next intake DM:

Before I start, can you fill these in? Saves us both a re-do.

1. What's the actual problem? (not the data ask — the business problem)
2. What decision does this inform?
3. What's the success metric + threshold? (e.g., "if churn > 8%, we cut budget")
4. Who else will see this? (manager, exec, board, customer?)
5. Hard deadline + what happens if I miss it?

I'll spec the analysis once I have these. Usually 24-48 hour turnaround on a v1 prototype.

Send it once. Pin it in your team channel. Make it the first thing every requester sees.

The "What Would You Do With the Answer?" Question

This is the single most useful sentence in an analyst's vocabulary, and I owe it to a Senior Analyst named Jordan who asked me a version of it on day eleven. I'll script it for you because the wording matters.

When a stakeholder lands an ask, you reply: "Quick question before I start. If churn comes back at 4%, what changes? What if it's at 12%? What's the action either way?"

Three things happen.

If they have a clean answer ("at 4% we leave SMB CS staffing alone, at 12% we triple it"), you know the analysis matters and you know exactly what numbers will move the decision. You can scope tightly. You can ship a v1 in 90 minutes.

If they say "I'm not sure, I just want to see the number," you've found a theater request. The analysis isn't going to change anything. You can either decline (politely, with a queue trade-off conversation), or you can spec it as a 30-minute pull instead of a 3-day deep dive. Either way, you've saved yourself two days.

If they push back with "well, it depends on what the number says," you keep digging. "Let's walk through the scenarios. If it's high, what's the option? If it's low?" By the third "what would you do" you'll either get clarity or you'll find out the requester is using you to feel busy. Both outcomes are useful.

I've killed roughly a third of incoming requests at this question over the last two years. Not by saying no, but by helping the requester realize they didn't actually need the work. That third of saved time is what lets you ship the analyses that actually matter.

Prototype-First: Ship Fake Numbers in 90 Minutes

Once intake is filled and the decision is real, you don't write the production query. You build a prototype with fake numbers, in 90 minutes, and you send a Loom walkthrough.

Here's what the prototype looks like. Open a Google Sheet. Mock the chart you think the stakeholder wants: bar chart with cohort buckets on the X axis, churn percentage on the Y, color-coded by ARR band. Type in plausible-looking fake numbers. Take a screenshot. Record a 3-minute Loom: "Here's the chart I'm planning to ship Tuesday. The shape is this. The cuts are this. The numbers are made up. I haven't run the query yet. Is this what you wanted? If not, what's wrong with it?"

That Loom is the most valuable artifact in your workflow. It costs you 90 minutes. It saves 2 to 5 days per project on average. I have data on this — across 47 projects in 2025, the median time-to-correct-spec dropped from 3.2 days to 0.6 days after I made prototyping mandatory.

The stakeholder watches the Loom and one of three things happens:

"Yes, that's exactly the chart." You write the production query, swap the real numbers in, ship it. No re-work.
"Almost, but I actually want it sliced by tenure not by ARR band." You've caught the misunderstanding before you wrote a line of SQL. Cost: zero. Adjust the prototype, send Loom v2, get sign-off.
"Hmm, now that I see it, I think I actually want a different question answered." Painful, but you've saved yourself the wrong analysis. Re-open intake.

The Loom plus mock-up is non-negotiable on anything bigger than a 30-minute pull. Yes, it feels weird to send fake numbers to a VP. Do it anyway. Frame it: "Quick gut-check on the shape before I write the query, saves a re-spin if I've misunderstood."

Scope-Creep Handling: Yes-But, Not Yes

Here's the trap. You're 60% through the v1 build. Marketing pings: "Oh, and can you also break it out by acquisition campaign? And segment by deal size? And add a YoY comparison?" Each request takes 20 minutes to add, in their head. In reality each one is half a day of new joins, new pivot logic, new chart real estate, new caveats.

You don't say yes. You don't say no. You say yes-but.

The script: "Happy to add those. They're each about half a day of work, and the v1 is locked for the Tuesday QBR. I can either (a) hold v1 to the original spec and queue the new cuts as v2 for the following week, or (b) push the v1 deadline to Friday to include them. Which do you want?"

Three things this does. It accepts the new ask without dismissing it. It surfaces the actual cost (your time is finite, and they need to know). And it forces them to choose, which means they own the trade-off, not you.

In nine cases out of ten they pick (a). Sometimes they pick (b) and that's fine. You got an extension and you got the new scope. The one case in ten where they want both, on the original deadline, is the conversation where you escalate to your manager.

Document the trade-off in writing. Always. Don't trust verbal agreements with stakeholders mid-flight on scope. They will, with full sincerity, forget by Tuesday. The change-control template below is how you make it stick.

The Change-Control Template

Four lines. Send it the moment scope shifts. Slack or email, doesn't matter, but written.

Quick scope-change recap so we're aligned:

ORIGINAL ASK: Churn by ARR band, ready Tuesday 10am for QBR.
NEW ASK: Churn by ARR band + by acquisition campaign + YoY, same deadline.
NEW ESTIMATE: I can hit Tuesday with v1 (original scope) and ship v2 (with the new cuts) by Friday EOD. Or push v1 to Thursday to include everything. Your call.
SIGN-OFF NEEDED BY: Today 5pm — anything later and I'm defaulting to v1 Tuesday + v2 Friday.

Four lines. Twenty seconds to type. Saves the "but you said you could do it" conversation that destroys analyst careers. The default-decision in line four is critical. It makes inaction itself a decision and means you're never blocked waiting for a stakeholder to reply.

I keep this as a Slack snippet. You should too.

Post-Delivery Validation: Did It Change the Decision?

You shipped the analysis. The QBR happened. Most analysts close the ticket and move to the next request. That's how you become the analyst who writes pretty queries that nobody acts on.

Forty-eight hours after delivery, you ping the requester. One sentence: "Quick follow-up. Did the analysis change what you decided to do?"

If yes, you've done the job. Note it in your impact log (you should keep one, with every analysis, the decision it informed, the dollar value of that decision). This is the file you bring to performance reviews. Not "I shipped 47 dashboards." Specifically: "I shipped the SMB churn analysis that drove the $400K Q2 CS expansion. ROI in Q3 was +$1.2M ARR retained."

If no, dig. "What ended up driving the call instead?" You'll find one of three patterns:

The analysis was directionally right but they had another data point that mattered more. Fine. Note it. Next time, ask in intake what other inputs are in play.
The decision got punted to next quarter. Often a sign that the original deadline was theater. Note that requester. Future asks from them get tighter scope and longer queues.
They never actually used the analysis. This is the theater pattern, and it's worth tracking. After three theater requests from the same stakeholder, you have a conversation with your manager. "Stakeholder X has asked for four analyses in Q1. Three didn't change a decision. I'd like to deprioritize their queue." Bring data, not feelings.

I started tracking decision-impact in mid-2024. By Q4 I'd identified two stakeholders whose requests routinely turned into theater and one whose every ask drove a six-figure call. Guess whose queue I cleared first.

Escalation Patterns: When the System Breaks

The intake form, the prototype, and the change-control template handle 85% of cases. The other 15% need escalation. Three patterns, three plays.

Pattern 1: The stakeholder won't fill out intake.

You sent the five fields. They reply "just pull the data, I don't have time for forms." You don't fold. You reply: "Totally hear you. I'll need answers to questions 1, 2, and 5 to start. Without those I'll likely ship the wrong cut and we'll both lose a day. Three sentences each is fine. I can hop on a 10-min Zoom if it's faster." If they still refuse, you escalate to your manager: "X is asking for Y but won't scope. Should I deprioritize or do you want to talk to them?" The escalation is not personal. It's a queue management call, and your manager owns queue priority, not you.

Pattern 2: Two stakeholders disagree on the metric.

Sales VP says churn should be measured by logo. CS VP says it should be by ARR. You're caught in the middle. Don't pick a side. Do both, label them clearly, and ship a one-paragraph note explaining when each definition is right. Then escalate to the most senior person in the chain (usually a CRO or COO) with a single-question Slack: "Sales is using logo churn, CS is using ARR churn for the same Q1 review. Want me to standardize? If yes, which one?" The exec picks. You document the call. From now on, you cite that decision in every future churn analysis.

Pattern 3: An exec overrides your manager's queue.

The CFO Slacks you direct: "Drop everything, I need this by EOD." Your manager has you locked on a different priority. Don't say yes. Don't say no. Reply to the CFO: "Happy to help. Let me sync with [manager] on the queue. Shouldn't take more than 30 minutes." Then ping your manager immediately: "CFO just asked for X by EOD. I'm currently on Y for you. How do you want me to play this?" Your manager either reshuffles or walks the conversation up to the CFO themselves. The cardinal rule: never silently reorder your manager's priorities for an exec. That destroys the trust that lets you push back the next time.

What This Actually Buys You

Two years of running this system, here's the math from my own ticket data:

Median time from request to correct-spec: 4 hours (down from 2.5 days at year one)
Re-work rate (analyses that needed a v2 due to misunderstood scope): 11% (down from 47%)
Theater requests killed at intake: 31%
Analyses tied to a measurable decision in the impact log: 88% (versus an estimated 30% in year one)

The analyst who scopes well ships three times more value than the one who writes prettier queries. That's not me being modest about my SQL. My SQL is fine. It's that the bottleneck on analyst impact is almost never the query. It's the alignment between the question asked and the question that needed asking. Translation is the job.

Your homework this week: pick the next vague Slack DM you get, paste in the five-field intake form, and don't open your IDE until it's filled. Watch what happens. Either the requester scopes properly and you ship something that matters, or they ghost the form and you've just learned which of your stakeholders are using you as theater. Both outcomes make you better at the job.

Data Analyst Playbooks