Skip to content
Back to Analytics & Experimentation

Data Storytelling

Structuring an analysis as a narrative —question, finding, so-what, recommendation —so a stakeholder acts on it instead of filing it.

Why

A dashboard with 40 charts generates zero decisions. The same data, structured as a 3-paragraph story with a recommendation, generates one. The gap is not the data —it is the narrative. Stakeholders are not analysts; they do not have the time or context to look at a chart of retention by cohort and derive 'we should email users in week 3'. The analyst's job is not to present data but to present a decision-ready conclusion, backed by data, in the language the stakeholder uses. Data storytelling is the discipline of doing this: leading with the question the stakeholder cares about, presenting the finding that answers it, drawing the 'so what' implication, and ending with a specific recommendation with a cost and a risk. The story is what makes the analysis actionable; without it, the analysis is a number in a spreadsheet that changes nothing.

When

Whenever an analysis needs a decision from a non-analyst (PM, exec, eng lead). Not needed for exploratory work or dashboards that analysts read themselves.

How

1. Start with the stakeholder's question, not your data: "Are we losing paying users?" is a question; "retention by cohort" is data that might answer it —lead with the question
2. Answer the question in the first sentence: "Yes, we are losing 8% more paying users than last quarter, and it started in week 3 of the cohort." —the conclusion goes first, the evidence second
3. Show the one chart that proves the finding, not the ten charts you explored —the stakeholder needs the answer, not your work product; put the other nine in an appendix
4. Draw the so-what: "This costs us $12k/month in MRR and, if unchecked, will compound to $48k/quarter by Q4." —the implication is what creates urgency
5. End with a specific recommendation: "Email users in week 3 of the cohort with a re-engagement offer; expected cost $2k, expected recovery 30% of churned users, net MRR save $3.4k/month." —specific, costed, with a risk
6. State the confidence and the caveat: "Confidence: high (n=2400, p<0.01). Caveat: this is correlation, not causation —recommend an A/B test before full rollout." —honesty builds trust
7. Fit it on one page (or one screen) —if the stakeholder has to scroll, they will not; the constraint forces you to choose what matters
8. End with the decision you are asking for: "Approve the $2k re-engagement experiment?" —make the ask explicit so the meeting ends with a yes/no, not "let's circle back"

Example

# Are we losing paying users?

Yes. Paying-user churn rose from 4.2% to 6.1% last quarter, concentrated
in users who hit the project limit on the Starter plan. This costs us
$11,800/month in lost MRR and is accelerating (+0.4pp/week).

[chart: churn rate by week, with project-limit-hit annotation]

So-what: at the current rate, Q4 churn will hit 9%, reducing ARR by
$340k. The root cause is that Starter-plan users who hit the 5-project
limit churn at 3x the rate of those who do not, and 38% of new paying
users hit the limit within 30 days.

Recommendation: raise the Starter plan limit from 5 to 10 projects
for new signups only (not existing, to isolate the effect). Run as an
A/B test for 4 weeks. Expected: 40% reduction in limit-hit churn,
net ARR save $4,700/month if it holds.

Confidence: high (n=2,400 churned users, p<0.001 on the limit-churn
link). Caveat: the link is observational; the A/B test will confirm
causation before we change the plan for everyone.

Decision needed: approve the 4-week A/B test raising Starter limit
to 10 for new signups?

Common Problems

  • ⚠Leading with the methodology instead of the answer —'we ran a cohort analysis using Kaplan-Meier' is how you did it, not what you found; the stakeholder's eyes glaze over before the conclusion, and the decision is never made.
  • ⚠Showing all 15 charts you explored instead of the 1 that matters —the stakeholder interprets this as 'the analyst could not decide' and makes the decision themselves, usually on intuition, defeating the purpose of the analysis.
  • ⚠Presenting a finding without a recommendation —'churn is up 8%' is a fact; the stakeholder is left to figure out what to do about it, and usually does nothing because the path from fact to action is not their job.
  • ⚠Omitting the caveat and confidence —the stakeholder treats 'churn is up' as certain, over-acts, and when the A/B test shows it was confounded, the analyst's credibility is spent and the next story is discounted.

Best Practices

  • ✓Put the conclusion in the first sentence and the evidence after —this is the 'inverted pyramid' of journalism, and it works because a stakeholder who reads only the first sentence still gets the decision-relevant information.
  • ✓Include a specific, costed recommendation with an expected outcome —'raise the project limit' is a direction; 'raise it to 10 for new signups, 4-week A/B test, expected $4.7k/month MRR save' is a decision the stakeholder can approve or reject.
  • ✓State the confidence and the caveat explicitly —'high confidence (p<0.01), but correlation not causation, A/B test recommended' builds more trust than a bare conclusion, and it protects the analyst's credibility when the caveat turns out to matter.
  • ✓Fit the story on one page —the constraint forces you to choose the one chart and the one recommendation that matter, and the selection is what makes the story actionable; a 5-page analysis is read by nobody.