Vague stakeholder requests turned into a scoped analysis plan
"Can you pull some numbers on churn?" is where analyst time goes to die — an ambiguous ask that balloons into three rounds of rework because the real question was never pinned down. AI is good at turning a vague request into a scoped plan: the clarifying questions to send back, the metric definitions to confirm, the data needed, and an honest list of what the analysis can and cannot answer.
You are a senior data analyst who is careful about scope. Turn a vague stakeholder request into a plan I can act on. The raw request, as it came to me: {{request}} Data and tables I actually have access to: {{data_available}} Timeline and how the result will be used: {{deadline_context}} Produce: 1. Restated objective — my best reading of the real question in one sentence. 2. Clarifying questions — 4 to 6 specific questions to send back before I start (definitions, time window, segments, what decision this feeds). 3. Proposed metric definitions — each written as a proposal to confirm, e.g. "churn = ... (confirm with requester)". 4. Data and approach — which of my available tables I would use and the analysis method, at a high level. 5. What this can and cannot answer — plainly, including whether an experiment would be needed for any causal question. 6. Right-sized deliverable — the smallest useful output for the stated use and timeline. Rules: - Do not assume a business metric's definition — propose it and mark it for confirmation. - Do not promise causal conclusions from observational data; flag where a test is required. - Use only the data sources I listed; if the question needs data I do not have, say so.
Fill in your details and the prompt updates live — then copy.
Restated objective: Identify where and when highly active users disengage, and surface candidate drivers, to inform whether retention is a Q3 priority. Clarifying questions to send back: 1. Define "power user" — top usage decile, a feature threshold, or tenure? 2. "Dropping off" over what window — 7-day inactivity, cancellation, or downgrade? 3. Which decision does this feed, and what would change your mind either way? Proposed metric: churn = no product event for 28 consecutive days among users active in the prior 28 (confirm with requester). Can answer: where and when disengagement happens, and correlates in the event data. Cannot answer without more: why they leave — support tickets hint at it, but causal claims would need a survey or test.
The full workflow
- Drop in the request exactly as it arrived, plus the data you can realistically use
- Send the clarifying questions back to the requester before building anything
- Get the metric definitions confirmed in writing so the result is not disputed later
- Scope the deliverable to the decision and timeline, and flag any causal question that needs a test
Watch out for
Do not let AI define your business metrics. Churn, active user, and conversion mean different things to different teams — a definition the requester has not confirmed is rework waiting to happen.
An analysis plan is only as honest as its limits. Keep the 'cannot answer' section — promising causal answers from observational logs is the fastest way to mislead a decision.
Anonymize the request. Strip customer names, internal project code names, and any confidential context before it goes into a consumer AI tool.
Where this comes from
Every use case on this site is grounded in real reports from working data analysts — not invented by us.