Topic 10

Telling stories with data

18 min readPart 3 — Analysis & Visualization
By the end you'll be able to

Turn analysis into a clear story that drives a decision.

Communication Is The PayoffAnswer First StructureTie To A DecisionPlain LanguageQuantify Impact

Topic 10 — Telling stories with data

Goal: Turn analysis into a clear story that drives a decision.

Lesson 10.1 — The analysis nobody read

Nadia spends two days on her first real investigation at Perch. Marcus, the head of marketing, had asked why repeat purchases dipped in May, and she dug in. She cleaned the orders table, joined it to customers, checked her work twice with Priya, and built a tidy six-tab spreadsheet. She emails it Friday afternoon, proud of the workmanship.

Monday, Marcus replies: "Thanks — so what do I actually do with this?"

Her stomach drops. The analysis was right. The work was real. And it changed nothing, because the one person who needed it couldn't find the point inside it.

That gap is the whole topic. The last skill in this course is communication: turning numbers into a story a busy, non-technical person can grasp in thirty seconds and act on. It is not a soft add-on to the "real" work. It is the part that decides whether any of the real work mattered.

Here is the uncomfortable truth Priya tells Nadia over coffee that week. Plenty of analysts who are stronger than you at SQL will have less influence than you, because they hand people a wall of numbers and expect the reader to do the thinking. The analyst who does that thinking for the reader — and says it plainly — is the one who gets pulled into the decisions.

Your analysis is only as good as the action it causes. A correct answer no one acts on scores zero.

For a career-changer from a people-facing background, this is good news. Nadia ran weekly sales reviews for a chain of stores for years; she already knows how to stand in front of a tired regional manager and make a number mean something. That instinct is worth more here than she expected.

Lesson 10.2 — Lead with the "so what?"

The mistake hides in a feeling Nadia knows well: the work was hard, so surely the reader wants to see how hard.

They don't. Marcus does not care about her SQL, her join logic, or the messy customer_id field she had to clean. He cares about one thing: so what? What did you find, and what should I do?

So she rewrites the email. Instead of opening with "I pulled the orders table and filtered to completed purchases since January…", she opens with the finding itself: repeat purchases dropped because first-time sofa buyers aren't coming back for a second item. The method moves to the bottom, for anyone who asks.

The reframe is simple to say and hard to do: write for the reader's question, not your own effort. Every sentence earns its place by helping Marcus decide something, or it goes in the appendix.

A quick test Nadia starts using: if she deleted the first sentence of her summary, would Marcus still know the headline? If the headline only shows up on slide twelve, the story is built backwards.

Lesson 10.3 — Answer-first structure

An instinct alone won't carry Nadia; she needs a reliable shape. Priya gives her one that consultants and senior analysts use, sometimes called answer-first (or "bottom line up front"). You state the conclusion, then support it, the opposite of a school essay that saves the point for the end.

Four parts, in this order:

  1. The headline — the answer in one sentence. "Repeat purchases fell 12% in May because first-time sofa buyers rarely come back for a second item."
  2. The proof — the two or three charts or numbers that show it's true (the visualization skills from Topic 9). Two or three, not twelve.
  3. The recommendation — what you suggest doing. "Send sofa buyers a 'complete the room' email at week three, before they drift."
  4. The details on demand — methodology, caveats, the full data, tucked in an appendix for anyone who asks.

Why this order? Because a busy executive reads top-down and stops the moment they have what they need. Dana, Perch's VP of Operations, will read the first sentence, maybe glance at one chart, and move on. If the answer is buried under twenty slides of process, Nadia has lost her before slide three.

Burying the conclusion under your process is the classic way to lose the room. Put the answer where the reader's eyes land first.

This is the single highest-leverage habit in the topic. It costs nothing technically and changes how seriously people take you. Nadia's old retail self knew this without the name: nobody ever wanted the spreadsheet first, they wanted "are we up or down, and what's the move?"

Lesson 10.4 — Plain language and impact people feel

Two days later Nadia drafts a line she's a little proud of: "Churn velocity increased among the new-customer cohort." Priya reads it and asks, gently, "Would Marcus know what that means?"

He wouldn't. So they translate it: "Customers are leaving faster than before, and it's the new ones." Same fact, zero jargon. That's the rule — plain language: say the everyday version, and if you must use a technical term, define it the first time. The goal is the reader's understanding, not your vocabulary.

The second habit is to quantify impact in the audience's terms. "Error rate is 2%" is a number that floats; it gives Marcus nothing to hold. "This checkout bug is costing us roughly $20,000 a month in abandoned carts" lands, because now it's money he recognizes and a problem he wants gone. Whenever Nadia can, she converts a percentage or a rate into the thing the reader actually cares about — dollars, orders, customers, hours.

Watch the difference on one finding:

Weak (analyst's terms)Strong (audience's terms)
"Repeat-purchase rate down 3pp""About 400 fewer repeat orders this quarter"
"Mobile conversion is 1.8%""Mobile shoppers buy half as often as desktop"

Same data. The right column is the one Dana repeats in a meeting — which is how Nadia's work travels to rooms she's not in.

Lesson 10.5 — End on a decision, and be honest about uncertainty

Every story Nadia tells now ends the same way: by pointing at a decision. She asks herself one question before she hits send — "What should the reader do differently because of this?" If she can't answer it, the analysis isn't finished, however clean the numbers are. Analysis that changes nothing was, practically, wasted.

But there's a trap on the other side. The pressure to give a confident answer can push her to overclaim, and overclaiming is how an analyst loses trust in one shot. So she learns to be honest about uncertainty, out loud: "This is based on two weeks of data, so treat it as an early signal, not proof." Saying that doesn't make her look weak. It makes the next thing she says more believable.

She also learns to tailor the framing to who's listening. The same finding goes to two people very differently:

  • To Dana (operations, non-technical, busy): one sentence and the recommendation. No methodology unless she asks.
  • To Tom (the data engineer): the caveat about the missing returns column matters, because he can fix it at the source.

Marcus in finance-mode wants the dollar impact; the product team wants the user behavior behind it. Honesty about what the data does and doesn't prove, framed for the person in front of her — that's the move that turns Nadia from "the person who pulls numbers" into someone Dana asks before making a call.

Worked example — Nadia presents the May dip

Marcus asks Nadia to present the repeat-purchase dip to Dana in a five-minute slot. Old Nadia would have walked in with the six-tab spreadsheet. New Nadia builds three slides.

Slide 1 — the headline. One line, large: "Repeat purchases fell 12% in May. The cause is sofa buyers — they rarely come back for a second item." Dana now knows the whole story before slide two.

Slide 2 — the proof. Two charts only. A line showing the repeat-rate dip month over month, and a bar chart showing sofa buyers return at less than half the rate of desk and shelf buyers. No third chart, even though Nadia made five.

Slide 3 — the recommendation, with its honesty. "Recommend a 'complete the room' email to sofa buyers at week three. Early estimate: recovering even a third of these customers is roughly $15,000 a quarter. Caveat — this is one month of data, so I'd run it as a test, not a full rollout."

Dana's reaction: "Do the test. Loop in Marcus on the email." Decision made, in about ninety seconds.

What Nadia kept in her back pocket: the SQL, the cleaning notes, the cohort definitions, the month she had to exclude because Tom flagged bad data. None of it surfaced — and all of it was ready the instant Dana asked "how confident are you?" That's the answer-first habit doing its job. The depth is there; it just isn't in the way.

Key terms

  • Answer-first (BLUF) — state the conclusion before the supporting detail; the reader's eyes hit the point first.
  • Headline — the finding compressed into one sentence a non-expert can repeat.
  • So what? — the reader's real question: what did you find, and what should I do?
  • Recommendation — the concrete action the analysis points to; without it the story is incomplete.
  • Plain language — the everyday phrasing of a finding, with any necessary term defined once.
  • Quantifying impact — converting a rate or percentage into terms the audience feels (dollars, orders, customers).
  • Tailoring — framing the same finding differently for finance, product, operations, or engineering.
  • Honest uncertainty — stating plainly what the data does and doesn't prove (sample size, time window, caveats).

Try this

Take any finding you've produced (or invent one, like "mobile sign-ups are down"). Write it up twice. First, the way you'd want to show your work: method, then evidence, then conclusion at the end. Then flip it into answer-first: headline sentence, two pieces of proof, one recommendation, and one honest caveat — and translate every technical word into plain language. Read both aloud to someone non-technical and ask which one they could repeat back. The gap between the two versions is the skill this topic is teaching.

Common pitfalls

  • Leading with your process. Opening with "I pulled the table and filtered…" instead of the finding. The reader wants the destination first; the route goes in the appendix.
  • Showing every chart you made. Five charts dilute the one that matters. Pick the two or three that prove the headline and cut the rest.
  • Reporting rates instead of stakes. "Error rate 2%" floats; "$20,000 a month" lands. Translate into what the audience already cares about.
  • Overclaiming to sound confident. Stating an early signal as proven fact. One overclaim that turns out wrong costs more trust than ten honest caveats ever will.
  • Ending without a "so what." A beautiful summary that names no decision leaves the reader to do the hard part — and most won't.

Key takeaways

  • Analysis creates value only when it's communicated clearly; clear communicators routinely out-influence technically stronger analysts.
  • Lead with the answer/headline, then two or three proofs, then a recommendation; keep methodology for the appendix.
  • Use plain language and quantify impact in the audience's terms (dollars, orders, customers — not bare percentages).
  • Tie every story to a decision — ask "what should the reader do differently because of this?"
  • Be honest about uncertainty and tailor the framing to the listener; that trust is what turns a report-puller into a trusted advisor.
Loading SQL playground…
Score 100% to unlock the next topic

Preparing your quiz…