Chapter 27: Writing About Data: Memos, Reports, and Dashboards That Tell a Story

"The commonality between science and art is in trying to see profoundly—to develop strategies of seeing and showing." — Edward R. Tufte, Beautiful Evidence (2006)

Chapter Overview

Dana Whitfield spent two weeks finding out why customers were leaving. She built a model, validated it, controlled for the obvious confound, and arrived at a result she was proud of: time-to-first-value was the dominant predictor of early churn. Then she wrote it up for her VP of Marketing, Renée Okafor, the way she had written it up for herself—starting with the data, the method, the model, the validation—and the result that took two weeks to find took Renée about nine seconds to skim and set aside. "Send me the bottom line when you have it," Renée wrote back. Dana had sent the bottom line. It was on page two, under a heading called "Results." Renée never got there. The analysis was right. The writing wasted it.

This chapter is about the last and most-skipped step of any analysis: turning what you found into writing that someone acts on. You have done the hard part—the data is clean, the chart is honest, the finding is real. Now a person who was not in your head, who does not care how you found it, and who will give your document a fraction of the attention it took you to produce, has to read it and do something different because of it. That is a writing problem, not an analysis problem, and it has its own discipline. The center of that discipline is one short, unglamorous question you must ask of every number you report: so what? A finding that cannot answer it is not finished. It is an observation looking for a conclusion, and you are the only person positioned to supply one.

You already hold both halves of what this chapter joins. Chapter 9 (Visuals and Data) taught you that a figure does not speak for itself—that the caption and the surrounding prose are what make a chart mean something, and that you lead with the finding ("Revenue fell 23% in Q4"), not the apparatus ("Figure 3 shows revenue"). Chapter 2 (Audience) introduced Dana and her churn finding, showed it rewritten for four readers, and made a promise: that her memo to the VP would return, to be rebuilt from method-first to recommendation-first. This is where that promise is paid. We will take Dana's churn memo and write it three ways—the version that fails, the version that works, and the version that works best—and from those three drafts pull every principle of writing about data. By the end, you will be able to write a data memo a busy decision-maker acts on, a caption that interprets, a dashboard label that guides, and an executive summary that leads with the insight instead of the machinery that produced it.

In this chapter, you will learn to:

• Structure a data-analysis memo so it leads with what the reader must decide, and carries only as much method as that reader actually needs.
• Apply the "so what?" test to turn every finding into an action—because a finding that recommends nothing has stopped one sentence short.
• Write an executive summary for an analysis that opens with the insight and the recommendation, never with the methodology.
• Write dashboard text—titles, labels, tooltips—that tells the viewer what a number means and whether it is good news or bad.
• Diagnose why a data write-up fails and rebuild it from method-first to recommendation-first, the move at the heart of this chapter.

📗 Software/Data track: This is one of your core chapters. The data memo (§27.2–§27.4), the "so what?" discipline (§27.5), and dashboard text (§27.7) are the difference between an analysis that changes a decision and one that gets filed. The Dana rebuild in §27.4 is the chapter—read it slowly and write your own version in the exercises. 📘 Business/Professional track: You are usually on the receiving end of these memos, which makes you the best judge of what works. The executive-summary-for-data section (§27.6) maps directly onto the standalone summary you learned in Chapter 20; §27.5 ("so what?") is the question you should be asking every analyst who sends you a number. Read those two sections first.

27.1 The Problem: Why Most Data Writing Fails the Reader

Here is the failure, in one sentence, before we slow it down: the analyst writes the document in the order they did the work, and the reader needs it in the opposite order.

You did the work forward. You started with a question, gathered data, cleaned it, picked a method, ran it, checked it, and arrived—at the very end—at a finding. That sequence is how you earned the result, so it feels like the honest, complete, rigorous way to present it. Method first, then results, then (if there's room) what it might mean. It is the structure of a lab report, the structure of the analysis itself, the structure of your own thinking. And for one specific reader—a fellow analyst who wants to verify and reuse your work—it is exactly right, as Chapter 2 showed with Dana's memo to her peer Priya.

But most people who read your data writing are not that reader. They are decision-makers, and a decision-maker reads the way Chapter 4 (Structure) described all readers reading: they scan, they hunt for the bottom line, and they leave the moment they have it or conclude they won't find it. They do not want to follow your path to the finding; they want the finding, then—only if they doubt it—the path. Presenting method-first to a decision-maker is like answering "what time is it?" by explaining how a clock works. The information is all there. It is in the wrong order for the person asking.

This mismatch produces three recurring failures, and you should learn to recognize all three in your own drafts.

Failure 1: The methodology wall. The document opens with data sources, sample sizes, model choices, and validation statistics—a paragraph or a page the reader must climb over to reach anything they can use. By the time the finding arrives, the reader has either skipped to the end (and missed your careful caveats) or given up. The method is not wrong to include; it is wrong to lead with for a reader who isn't auditing you.

Failure 2: The finding with no "so what?" The document states a result—"churn is 9.3% and rising"—and stops. It reports the number correctly and leaves the reader holding it, unsure what they are supposed to do. A number without a recommendation is a problem dropped on the reader's desk; a number with a recommendation is a decision teed up. The whole of §27.5 is about closing this gap.

Failure 3: The uninterpreted exhibit. A chart or table is dropped in with a label ("Figure 2. Churn by cohort") and no statement of what it means—the exact failure Chapter 9 warned against. The reader sees shapes, not the insight you spent weeks earning. A scanner who reads only headings and captions leaves with nothing.

❌ Before — an analysis email that commits all three failures: Subject: Q3 churn analysis I pulled all account cancellations for the trailing two quarters (n=4,812 new accounts) and built a random-forest classifier (sklearn, 300 trees, 5-fold CV, ROC-AUC 0.81) to predict 90-day churn. Time-to-first-value emerged as the top feature by importance, controlling for plan tier. See attached notebook and the cohort chart (Figure 2). Let me know if you have questions.

✅ After — the same analysis, reordered for a decision-maker: Subject: We're losing 1 in 4 new customers—and the fix is onboarding We're losing nearly a quarter of new customers, and it's accelerating. The cause isn't price or product—it's onboarding. Customers who reach their first real "win" within a week churn at 3%; those who take longer than three weeks churn at 22%, seven times higher. Recommendation: move retention budget upstream into the first-week experience. I can put a one-page plan in front of you by Friday. (Method and the full model are below for anyone who wants them.)

Why it's better: The "before" leads with apparatus the reader cannot act on and buries the finding in jargon ("random-forest classifier," "ROC-AUC," "feature importance") that, for this reader, subtracts credibility rather than adding it—the curse of knowledge from Chapter 2, made visible. The "after" leads with the consequence (losing a quarter of new customers), names the cause in plain language, gives the one decisive number, and—critically—ends with a recommendation and a next step, so the reader finishes the first paragraph already able to decide. Nothing was dumbed down; the method is still there, demoted to where the reader who wants it can find it. Same facts. Opposite order. One gets read.

The rest of this chapter builds the skill that turns the first version into the second, reliably, on purpose. We start with the document that carries most data writing in the working world: the memo.

🔄 Check Your Understanding An analyst sends you a Slack message: "Finished the latency analysis—p99 went from 240ms to 890ms after the deploy, here's the dashboard link." What is missing, and what one sentence would you ask them to add?

Answer

The "so what?" and the action. The number is alarming but the message stops at the observation—it tells you what without telling you what it means or what to do. Ask for: "p99 latency nearly quadrupled after Tuesday's deploy (240ms → 890ms), which is over our 500ms SLA—recommend we roll back the deploy now and investigate before re-shipping." That adds the consequence (SLA breach), the cause (the deploy), and the recommendation (roll back). A number that breaches an SLA and recommends nothing is failure 2 in miniature.

27.2 The Data-Analysis Memo: A Skeleton Built for the Reader

A data-analysis memo is the workhorse document of applied data work: a short, written answer to a question someone asked of the data, addressed to someone who has to act on it. It is not a report (too long), not a paper (wrong audience), not a slide deck (no presenter to narrate). It is the thing you write when a stakeholder asks "why are customers leaving?" or "did the experiment work?" or "should we keep spending on this channel?"—and it lives or dies on whether the reader can act after reading it.

It has a conventional skeleton, and—as with the proposal in Chapter 20—the conventions exist to serve the reader, not to fill a template. Here are the four parts, each defined by the reader's question it answers.

Read that table top to bottom and notice the order: question, then findings, then recommendation, then method. That is almost exactly the reverse of how you did the work, and that reversal is the single most important structural move in writing about data. You did it method → findings. The reader needs it findings → method. (We will refine the exact order in §27.4, because there's a further improvement: leading with the recommendation rather than the finding. But start here.)

🧩 Productive Struggle Before you read on, try this. You analyzed three months of support tickets and found that 60% of them are about one feature: password reset. Write the first sentence of a memo to the head of Support. Don't draft the whole thing—just the opening line. Then keep reading and compare yours to the versions below.

Discussion

If your first sentence was "I analyzed 4,200 support tickets from the last quarter and categorized them by topic," you led with method—the most common reflex, and the one this chapter is built to break. If it was "60% of our support tickets are about one thing: password reset," you led with the finding—better. If it was "We can cut support volume by more than half by fixing one feature—password reset—which drives 60% of all tickets," you led with the recommendation and the finding together—best. We'll see why the third wins in §27.4. The point of this struggle: the method-first opening probably felt the most "complete" and "honest" to write, which is exactly why it's the trap.

Let's build each part, briefly, before we put them together on Dana's churn case.

The question. Open by naming the question the analysis answers, in the language of the person who has to act. "This memo answers: why has new-customer churn nearly doubled, and what can we do about it?" One sentence. This does two things: it tells a scanning reader instantly whether the memo is relevant to them, and it frames everything that follows as an answer, which is what they want. Resist opening with what you did ("I pulled the cancellation data and..."). The reader cares what you found, and they'll trust the finding more, not less, if you state it before the method.

The findings. State the answer as a claim, in the reader's units, leading with the most decisive fact. Not "the analysis identified time-to-first-value as the dominant predictor" (your units) but "customers who don't get value in their first week leave seven times as often as those who do" (their units). The skill here is the one from Chapter 9: lead with the finding and its consequence, not with the exhibit. If you have several findings, lead with the one that most changes what the reader does, and order the rest by decision-relevance, not by the sequence you discovered them in.

The recommendation. This is where data memos most often fall short, and it gets its own section (§27.5). For now: every finding must be followed by what to do about it. The reader is not reading for education; they're reading to decide. A finding that ends in a recommendation respects that; a finding that ends in a number makes the reader do the translation you were better positioned to do.

The method. Include enough to earn trust and to disclose the caveats—and size it to the reader. For Renée, that's two sentences ("Based on two quarters of cancellation data and a predictive model; the pattern is strong and holds after we account for account size"). For an analyst peer, it's the full apparatus. The method goes below the finding, not above it—available to the reader who doubts you, invisible to the reader who doesn't. And the caveats belong here, stated honestly: the confound you controlled for, the sample limitation, the thing you're not sure about. Hiding caveats doesn't make you more persuasive; it makes you wrong when someone finds them.

💡 Tip: A memo is short by definition. If yours is running past a page and a half, the method has probably crept up and swallowed the findings. Cut the method to what this reader needs to trust the result, and push the rest to an appendix or "details below" link. The studier can dig; the skimmer must not have to.

[📍 Good stopping point]

27.3 The Centerpiece, Part 1: Dana's Memo, Method-First (the version that fails)

Now we make all of this concrete with the example Chapter 2 promised would return. Recall Dana Whitfield's finding, stated precisely for herself:

Quarterly churn rose from 5.1% to 9.3% over two quarters, concentrated almost entirely in accounts younger than 90 days. A random-forest model identifies time-to-first-value—the days before a new customer completes a meaningful action—as the dominant predictor. Accounts that reach first value within 7 days churn at 3%; accounts that take longer than 21 days churn at 22%. The onboarding flow, not the product or the price, is the leak.

Her reader is Renée Okafor, VP of Marketing: low jargon fluency, high business context, a skimmer between meetings whose decision is whether to move retention budget upstream into onboarding. We are going to write Dana's memo to Renée three ways, each better than the last, and from the three drafts extract the whole discipline. This is the chapter's spine.

Here is the version Dana actually sent—the one that earned "send me the bottom line when you have it." Call it method-first.

❌ Version 1 — Method-First (the version that fails):

To: Renée Okafor (VP Marketing) Subject: Churn analysis — methodology and results

Renée,

Over the past two weeks I analyzed customer cancellation patterns to identify the drivers of our recent churn increase. Here is my approach and what I found.

I extracted all account cancellations over the trailing two quarters, yielding a cohort of 4,812 new accounts. I defined the target variable as churn within 90 days of signup and built a random-forest classifier (300 trees, max depth tuned via 5-fold cross-validation) to identify the most predictive features. Class imbalance was handled with balanced subsampling; the model achieved an ROC-AUC of 0.81 on held-out data.

The feature-importance analysis identified time-to-first-value (TTFV)—the number of days before a new account completes a meaningful in-product action—as the dominant predictor by a wide margin. Partial-dependence analysis showed a monotonic, steep relationship past approximately 14 days. I controlled for plan tier (which correlates with TTFV at r≈0.3) and the effect held.

Bucketing accounts by TTFV: those reaching first value within 7 days churned at 3%, while those taking longer than 21 days churned at 22%. Quarterly churn over the analysis window rose from 5.1% to 9.3%, concentrated in accounts younger than 90 days.

Figure 2 (attached) shows churn by TTFV cohort. The notebook and data dictionary are in the repo. Happy to discuss.

Read it as Renée would, on a phone, between two meetings. The first thing she meets is "my approach"—a promise of process, not answer. The second paragraph is a wall: extraction, cohort sizes, target-variable definitions, random forests, cross-validation, subsampling, ROC-AUC. None of it is wrong. All of it is in the way. Renée is not going to audit the cross-validation; she would not know an ROC-AUC of 0.81 from one of 0.61, and she shouldn't have to. Every sentence of method she reads before reaching the finding is a sentence that taxes her patience and—worse—signals that Dana doesn't understand what Renée needs. The actual finding, the seven-times-higher churn, doesn't arrive until the fifth paragraph, and the recommendation—what Renée should actually do—never arrives at all. The memo ends with "happy to discuss," which silently hands Renée the job of figuring out the implication that was Dana's to deliver.

Let's name the specific defects, because you will make every one of them:

1. Method-first ordering. The structure is the order Dana did the work, not the order Renée reads. Four of six paragraphs are climbed-over before the payoff.
2. Jargon that subtracts credibility. For a peer, "random forest" and "ROC-AUC" are precision. For Renée, they are noise that says this isn't written for you. (Chapter 2's curse of knowledge, exactly.)
3. The finding is buried and unframed. "Those taking longer than 21 days churned at 22%" is the whole analysis, and it's a subordinate clause in paragraph four, stated in Dana's units, not Renée's.
4. No "so what?". There is no recommendation. The most decision-ready analysis in the company ends by asking the reader to supply her own conclusion.
5. The chart is dropped, not interpreted. "Figure 2 shows churn by TTFV cohort"—the labeling caption Chapter 9 told you to never write. It points at the chart; it doesn't say what the chart means.

That's the diagnosis. Now the fix—in two stages, because the jump from worst to best is really two separate moves, and seeing them separately is how you learn to make each one.

🔄 Check Your Understanding In Version 1, which single sentence contains the actual finding Renée needs, and what's wrong with where it sits and how it's worded?

Answer

The sentence "those reaching first value within 7 days churned at 3%, while those taking longer than 21 days churned at 22%." Two things are wrong. Placement: it's in the fifth paragraph, after a methodology wall, so a skimming reader never reaches it. Wording: it's in Dana's units ("reaching first value," "TTFV buckets"), not Renée's—it states the mechanism, not the consequence. Reworded for Renée: "Customers who don't get value in their first week leave seven times as often as those who do." Same fact; the second version leads with the human consequence and the memorable multiplier, and belongs in sentence one, not paragraph five.

27.4 The Centerpiece, Part 2: Findings-First, then Recommendation-First (better, then best)

Move 1: Flip it to findings-first

The first move is the big one: turn the document over. Put the finding at the top, in the reader's language, and demote the method to the bottom for whoever wants it. Same content, reversed order.

✅ Version 2 — Findings-First (better):

To: Renée Okafor (VP Marketing) Subject: Why we're losing new customers — it's onboarding, not price

Renée,

We're losing nearly 1 in 4 new customers, and it's getting worse—churn nearly doubled over two quarters. The cause isn't price and it isn't the product. It's onboarding. Customers who reach their first real "win" in the product within their first week churn at 3%. Customers who take longer than three weeks churn at 22%—seven times higher.

In other words, the leak is in week one, not at renewal. The single biggest lever we have on retention is getting new customers to value faster.

How we know: this is based on every cancellation over the last two quarters and a predictive model that ranks what drives churn. Time-to-value came out on top by a wide margin, and the pattern holds even after accounting for the fact that bigger accounts onboard more slowly. I'm confident it's a real driver, not noise.

Full methodology, the model, and the cohort breakdown are in the attached notebook—happy to walk through any of it.

Feel the difference. The finding now hits in the first two sentences, in Renée's units (one in four customers, getting worse, it's onboarding). The decisive number—seven times higher—lands in plain language. The "how we know" paragraph still earns trust, but it's two sentences of reassurance instead of a wall of apparatus, and it sits below the finding where a skimmer skips it and a doubter finds it. Renée can stop reading after paragraph one and act correctly. That is the test of a findings-first memo: could the reader stop after the first paragraph and still do the right thing? Here, yes.

This is already a vastly better memo than Version 1. For many situations, findings-first is exactly where you should stop—when the reader's job is genuinely to understand the finding and decide for themselves what to do with it, leading with the finding and trusting them to draw the action is respectful and sufficient.

But Renée's situation is not one of those. Renée doesn't need to be informed that onboarding drives churn; she needs to decide whether to move budget. And Version 2, for all its improvement, still makes her take the last step herself. It tells her where the leak is. It doesn't tell her to pick up the wrench. Which brings us to the second move.

Move 2: Lead with the recommendation

The best version of a persuasion document—and a memo asking a VP to move budget is persuasion, as Chapter 2 and Chapter 20 both taught—does not merely lead with the finding. It leads with the recommendation, then supports it with the finding. The difference is the difference between "here's what's true" and "here's what we should do, and here's why it's true." For a reader whose job is to act, the second is what they came for.

✅ Version 3 — Recommendation-First (best):

To: Renée Okafor (VP Marketing) Subject: Recommend moving retention budget into week-one onboarding

Renée,

Recommendation: shift retention spend upstream—out of renewal-stage win-backs and into the first-week onboarding experience. I think this is the highest-return move available to us on churn right now, and I'd like your approval to scope it. I can have a one-page plan to you by Friday.

Why: we're losing nearly 1 in 4 new customers, and it's accelerating—churn nearly doubled over two quarters. The cause isn't price or product; it's onboarding. Customers who reach their first real "win" within a week churn at 3%; those who take longer than three weeks churn at 22%, seven times higher. The leak is in week one, not at renewal—which is exactly where our retention budget isn't.

How confident: this is based on every cancellation over the last two quarters and a model that ranks churn drivers; time-to-value is the top driver by a wide margin and holds after accounting for account size. Strong enough to act on.

The ask: approve a two-week scope of the week-one onboarding flow. Full analysis attached if useful.

Now Renée has, in the first three lines, everything she needs to say yes: what Dana wants (move budget upstream), framed as a recommendation she can approve, with a concrete next step (a one-page plan by Friday) and a dated ask. The finding is still there—it's the "why"—but it now serves the recommendation instead of standing alone waiting for Renée to act on it. The method is one sentence of "how confident." The whole memo is built so that the busiest possible reader, reading only the bold lead, can make the decision.

Put the three side by side and the lesson is unmistakable:

🔍 Why Does This Work? Why does recommendation-first beat findings-first for this reader, when both contain the identical finding? Think about what Renée actually has to produce at the end of reading, then read on.

Answer

Because Renée's output isn't understanding—it's a decision. A findings-first memo optimizes for the reader's comprehension; a recommendation-first memo optimizes for the reader's action. When the reader's job is to decide, the recommendation is the thing they're reaching for, so putting it first means they get what they came for in line one and everything after is justification they can take or leave. Findings-first makes them assemble the recommendation themselves from the finding—a small step, but one Dana is better positioned to take, and one a busy reader resents being handed. Note the dependency: recommendation-first is best because the reader's purpose is to act (Chapter 2's purpose dial set to "persuade"). For a reader whose purpose is to understand and judge for themselves—a peer reviewing your analysis, a regulator—findings-first is correct, and leading with a recommendation would feel like you're pushing a conclusion past their scrutiny. The order follows the reader's purpose. Always.

🚪 Threshold Concept: A finding is not a conclusion until it answers "so what?" Before this chapter, you likely thought of "the finding" as the endpoint of an analysis—the thing you worked toward, the answer, the deliverable. After it, you should see the finding as the next-to-last step. The number ("22% vs. 3%") is an observation. The conclusion is what the reader should do about it ("move budget into onboarding"). An analysis that stops at the number has stopped one sentence too early and silently handed its hardest interpretive step to the person least equipped to take it. Once you cross this threshold, you stop asking "what did I find?" and start asking "what should they do because of what I found?"—and every memo, caption, and dashboard you write changes shape.

We'll spend the next section on exactly that interpretive step—the "so what?" discipline—because it is the muscle this whole chapter is training.

27.5 The "So What?" Discipline: Turning Findings into Actions

Here is the single most useful question in all of data communication, and you should ask it of every number you ever report: so what?

Not cynically—earnestly. You found that 60% of support tickets are about password reset. So what? You found that p99 latency rose to 890ms. So what? You found that the experiment lifted conversion by 0.3 points. So what? Each "so what?" is a demand that you take the finding one step further—from what is true to what we should do—and that step is the one your reader cannot take as well as you can, because you're the one who understands the number.

The discipline has a structure. A complete finding moves through three levels, and you should be able to feel which level a sentence stops at:

Most data writing stops at Level 1, occasionally reaches Level 2, and rarely arrives at Level 3—which is the only level the reader can act on. The "so what?" test is simply the habit of pushing every finding from wherever it stopped down to Level 3.

Watch it work on a finding that has nothing to do with churn, so you can see the move is general:

❌ Level 1 (observation only): "Mobile users have a 40% higher cart-abandonment rate than desktop users."

So what? (Push it down.)

✅ Level 3 (recommendation): "Mobile users abandon their carts 40% more often than desktop users, and mobile is now 60% of our traffic—so this is our single largest revenue leak. The drop-off concentrates at the payment step, where the mobile form has 11 fields. Recommend we cut the mobile checkout to a single-screen flow and test it; even closing half the gap would recover an estimated $340K a quarter."

Why it's better: The Level 1 version is a true, interesting fact that recommends nothing—the reader nods and moves on. The Level 3 version interprets the fact (largest revenue leak, because mobile is now most of traffic), diagnoses it (the 11-field payment form), recommends a specific action (single-screen checkout), and quantifies the prize ($340K a quarter). The reader doesn't have to wonder whether the finding matters or what to do; both are answered. That quantification—translating the finding into the reader's currency, here dollars—is often what turns a Level 2 interpretation into a Level 3 recommendation worth approving, exactly the cost-of-inaction move from Chapter 20.

A caution, because "so what?" can be misapplied: the recommendation must be supported by the finding, not smuggled past it. If your data shows that mobile abandonment is high but says nothing about why, then "recommend we cut the form to one screen" is a guess wearing a recommendation's clothing. The honest version flags the gap: "the data shows the drop-off concentrates at the payment step; the most likely cause is the 11-field form, though we'd want to confirm with session recordings before committing." A recommendation the data doesn't support is worse than no recommendation, because it spends your credibility on a hunch. The "so what?" test demands an action; it does not license one the evidence can't carry. (This is the accuracy obligation we'll treat directly in Chapter 38.)

✏️ Try This Take this finding and push it to Level 3: "Customers acquired through paid search have a 25% lower lifetime value than customers acquired through referrals." Write one sentence that interprets it and recommends an action. (Assume you also know that paid-search customers churn faster in their first 90 days.)

One possible answer

"Paid-search customers are worth 25% less over their lifetime than referred customers—largely because they churn faster early—so we're overpaying to acquire our least durable customers; recommend we shift acquisition budget toward the referral program and tighten paid-search targeting to higher-intent segments." It interprets (we're overpaying for weak customers), uses the extra fact (early churn) as the mechanism, and recommends two concrete actions. If you only wrote "paid-search customers are less valuable," you stopped at Level 1.

The "so what?" discipline is what makes the recommendation-first memo of §27.4 possible: you cannot lead with a recommendation you haven't bothered to form. Run "so what?" on your finding before you start writing, and the recommendation that belongs at the top of the memo will already exist.

🔄 Check Your Understanding Your A/B test result: "Variant B increased click-through by 0.4 percentage points (from 2.1% to 2.5%), p = 0.03." A junior analyst wants to write exactly that sentence in a memo to the head of Growth. What level is it, and what would you add to reach Level 3?

Answer

It's Level 1 (observation)—a statistically significant result stated with no interpretation or action. The head of Growth can't tell from it whether 0.4 points matters. Push to Level 3 by adding meaning and action in their units: "Variant B lifted click-through from 2.1% to 2.5%—a 19% relative gain that, at our traffic, is roughly 8,000 additional clicks a month. Recommend we ship Variant B to 100% and roll the winning pattern into the other two campaigns." Note the move: translate "0.4 percentage points" (a number that sounds small) into "19% relative / 8,000 clicks a month" (the consequence), then recommend shipping. The p-value belongs in a "how confident" line, not the lead.

[📍 Good stopping point]

27.6 The Executive Summary for Data: Lead with the Insight, Not the Method

When an analysis grows past a memo into a full report—when there are five findings, three figures, an appendix of method, and multiple readers—it needs an executive summary: a standalone opening that carries the whole story for the reader who reads nothing else. You met this document in Chapter 20, where the threshold concept was blunt: the executive summary is not a preview of the document; it is the document. Most decision-makers read only the summary and forward the rest. Everything you learned there applies. This section adds the one rule specific to summarizing data.

The rule: lead with the insight, not the methodology. The single most common failure in a data report's executive summary is opening with how the analysis was conducted—the data sources, the time window, the analytical approach—as though the reader needs to be walked up to the finding. They don't. They need the finding, the implication, and the recommendation, in that order, in the first three sentences. The method has a place; that place is below the summary, in the body, where the reader who doubts the finding can audit it.

❌ Before — executive summary that leads with method: This report presents an analysis of customer churn conducted over the trailing two quarters. Using cancellation records for 4,812 new accounts, we developed a predictive model to identify the factors most associated with early churn and validated it against held-out data. The analysis examined a range of candidate predictors including plan tier, acquisition channel, support-ticket volume, and onboarding speed. This summary presents our key findings and recommendations.

✅ After — executive summary that leads with the insight: New-customer churn has nearly doubled in two quarters, and the cause is onboarding, not price or product: customers who reach first value within a week leave seven times less often than those who take more than three weeks. We recommend shifting retention investment upstream into the first-week onboarding experience, our highest-leverage available move on churn. A focused redesign of week-one onboarding could, on conservative assumptions, recover an estimated $1.2M in annual recurring revenue. The full analysis and methodology follow.

Why it's better: The "before" spends its entire first paragraph—the most valuable real estate in the document—on what the analysts did, and ends with a promise ("this summary presents our findings") instead of the findings themselves. A reader who reads only that paragraph leaves knowing a study happened and nothing about what it found. The "after" delivers, in four sentences, the finding (churn doubled, it's onboarding), the decisive comparison (seven times), the recommendation (shift investment upstream), and the prize ($1.2M in ARR)—and only then mentions that the methodology follows. A reader who reads only the "after" can approve the recommendation. That is the entire test, inherited from Chapter 20: could the reader decide from the summary alone? Method-first summaries fail it every time, because they spend the reader's attention on the apparatus before reaching the answer.

The same standalone test applies, with a data-specific sharpening:

• Open with the headline finding, stated as a claim in the reader's units.
• State the recommendation explicitly—don't make them infer it.
• Quantify the stakes in the reader's currency (dollars, customers, risk, time)—the "so what?" made numeric.
• Name your confidence in one phrase, not a paragraph ("strong and consistent," "directional—worth a deeper look"). Honesty about confidence belongs in the summary; the detail of how you established it does not.
• Mention method only by pointing to it ("the full methodology follows"). The summary's job is the answer, not the audit trail.

🔄 Check Your Understanding A data report's executive summary opens: "To assess the effectiveness of our onboarding intervention, we conducted a randomized controlled experiment over six weeks, splitting new users into treatment and control groups and measuring 30-day retention." It's a clean, accurate sentence. Why is it the wrong opening for an executive summary, and what should open it instead?

Answer

It leads with method (we ran an RCT, here's the design)—accurate, but it spends the most valuable sentence in the document on the apparatus rather than the answer. An executive reading only the summary learns that an experiment was run and nothing about whether the intervention worked. It should open with the result and its consequence: "Our new onboarding flow increased 30-day retention by 12 points (from 58% to 70%)—a result strong enough to roll out company-wide, worth an estimated $X in retained revenue." The RCT design moves to the body, where a skeptical reader can verify it. Lead with the insight; demote the method.

27.7 Dashboard Text: Titles, Labels, and Tooltips That Guide the Viewer

A dashboard is data writing too—it just hides the writing in small places people don't think of as prose: the title of each chart, the labels on axes and series, the tooltip that appears on hover, the little note under a number. Most dashboards are built by people who think carefully about the data and not at all about these words, and the result is a wall of accurate charts that leaves the viewer asking the question this whole chapter exists to prevent: so what? is this good or bad? what do I do? The writing is the difference between a dashboard someone glances at and a dashboard someone acts on.

The governing principle is the same one from §27.5, compressed into tiny spaces: wherever a number appears, help the viewer know what it means and whether it's good or bad. A dashboard can't deliver a full recommendation, but it can do far more than label. Three places carry most of the load.

Chart titles: make them say the takeaway, not the topic. This is the interpretive-caption lesson from Chapter 9, applied to dashboards. A title that names the topic ("Monthly Active Users") makes the viewer decode the chart to find the point. A title that states the takeaway ("Active users flat for three months after a year of growth") hands them the point and lets the chart support it. On a live dashboard where the data changes, you may not be able to bake in a specific finding—but you can still title for the question the chart answers ("Are we retaining new users?") rather than the metric it plots ("90-Day Retention Rate"). The first orients the viewer; the second makes them work.

❌ Before (topic titles): "Revenue," "Churn Rate," "Support Tickets," "NPS"

✅ After (question/takeaway titles): "Revenue: on track for target?" · "Churn: trending up—watch new accounts" · "Support load: where are tickets coming from?" · "NPS: recovering since the March fix"

Why it's better: The topic titles are labels—they name what's plotted and leave interpretation entirely to the viewer. The question/takeaway titles tell the viewer what to look for and, where the data is stable enough, what the answer is. A viewer scanning the dashboard in five seconds gets oriented instantly: they know which charts demand attention ("churn trending up") and which don't. The chart underneath is identical; the title is what turns a gallery into a guide.

Labels: name things in the viewer's language, with units and direction. An axis labeled "ttfv_days" is for the person who built the dashboard; "Days to first value" is for the person reading it. A metric labeled "4.2%" tells the viewer a value but not whether 4.2% is good; "Churn: 4.2% ▲ (target: <3%)" tells them the value, the trend, and the standard it's failing. Every number on a dashboard should answer, in the smallest possible space, "compared to what?"—last period, target, or benchmark. A bare number is an observation; a number with a comparison is an interpretation.

❌ Before: Conversion: 2.5%

✅ After: Conversion: 2.5% ▲ 0.4pt vs. last month · target 3.0%

Why it's better: "2.5%" alone forces the viewer to remember last month's number and the target to know whether to be pleased or alarmed. The annotated version carries its own context: up from last month (good direction), still under target (not done). The viewer interprets at a glance instead of going to find the context elsewhere—which, on a dashboard meant for quick scanning, they won't.

Tooltips: answer the question the chart raises. The tooltip—the text on hover—is your chance to add the interpretation, definition, or caveat that would clutter the chart if it were always visible. Use it to define the metric ("First value = the user's first completed project"), to explain an anomaly ("September spike: annual contracts renew this month"), or to state the "so what?" that doesn't fit on the face of the chart. A tooltip that merely repeats the number under the cursor ("Value: 4.2%") wastes the interaction; a tooltip that explains earns it.

💡 Tip: Before you ship a dashboard, do the five-second test Chapter 4 would endorse: show it to someone unfamiliar for five seconds, take it away, and ask "which metric needs attention, and is it good or bad?" If they can't answer, your titles and labels are naming topics, not delivering takeaways. Fix the words, not the charts.

⚠️ Warning: Don't let interpretive titles drift into dishonesty. A title like "Churn under control" baked into a live dashboard becomes a lie the moment churn climbs. For changing data, title for the question ("Is churn under control?") or use a status indicator that updates with the data (a red/amber/green dot), not a fixed claim that may be false next week. The interpretation must stay true as the numbers move—the accuracy obligation from §27.5, applied to a surface you don't rewrite daily.

🔄 Check Your Understanding A dashboard tile reads simply: Avg. response time: 4.3h. The team's SLA is 4 hours. Rewrite the tile's text so a viewer scanning for two seconds knows whether to worry, and write a one-line tooltip for it.

Answer

Tile: Avg. response time: 4.3h ▲ (SLA: 4h) ⚠️—the value, the direction, the standard it's breaching, and a flag that says "this one." Tooltip: "Average time to first response on support tickets, last 7 days. Above our 4-hour SLA since Tuesday—driven by the billing-question backlog." The tile delivers the "is this bad?" in two seconds (yes—over SLA); the tooltip delivers the "so what / why" for the viewer who stops to hover. A bare "4.3h" makes a viewer who doesn't have the SLA memorized unable to interpret it at all.

27.8 Annotations and Interpretive Captions in Data Documents

Between the memo and the dashboard sits the data document with embedded charts—the report, the analysis deck, the wiki page—and its characteristic skill is the one Chapter 9 named the most under-taught in technical communication: the interpretive caption, plus its close cousin, the annotation drawn directly onto the chart. This section is a focused application of Chapter 9 to data writing, because writing about your own analysis is where captions matter most and get neglected most.

Recall the levels from Chapter 9, now in the data-memo context:

• Level 1 — Label: "Figure 2. Churn by time-to-first-value cohort." (What it is. Where most writers stop.)
• Level 2 — Observation: "Figure 2. Churn rises sharply with onboarding time, from 3% to 22%." (What it shows.)
• Level 3 — Interpretation: "Figure 2. Slow onboarding, not price, drives early churn: customers who take over three weeks to reach first value churn seven times as often as those who get there in a week—pointing to week one as the place to intervene." (What it means, and the implication. ✅)

The Level 3 caption does the work of the memo in miniature: it states the finding, gives the decisive comparison, and gestures at the action. A reader who skims your report reading only the figure captions—and many will—leaves with your actual argument, not a list of topics. That is the whole point of writing captions that interpret: the caption-only reader should arrive at your conclusion.

Annotation goes one step further: it writes the interpretation onto the chart itself. The single most powerful annotation is a short text callout placed at the exact point on the chart where the story lives—an arrow to the inflection, a label on the outlier, a line marking the threshold—with a few words saying what's happening there.

Described example (the annotated churn chart). Figure 2 (described): a line chart with "Days to first value" on the x-axis (0 to 30) and "90-day churn rate" on the y-axis (0% to 25%). The line is low and flat near 3% until about day 14, then climbs steeply to 22% by day 21. A text callout with an arrow points to the elbow around day 14: "Churn stays low—until week two. After ~14 days without a 'win,' it climbs steeply." A shaded band marks days 0–7 labeled "Target onboarding window." Alt-text: "Churn is flat and low for fast-onboarding customers and rises sharply for those who take longer than two weeks to reach first value; the danger zone begins around day 14."

The annotation puts the interpretation where the reader's eye already is—on the chart—so even a reader who skips every word of prose absorbs the point. A bare version of the same chart (no callout, no shaded band, no interpretive caption) would show the same line and leave the reader to discover the elbow, name its significance, and infer the action entirely on their own. Most won't. The annotation does that work for them, in six words, at the exact spot it matters.

❌ Before (the chart dropped into the report): [chart] Figure 2. 90-day churn rate by time-to-first-value.

✅ After (interpreted and annotated): [chart, with the day-14 elbow called out and the 0–7 day window shaded] Figure 2. Early churn stays near 3% until roughly day 14, then climbs to 22%—so the highest-leverage intervention is getting new customers to their first "win" inside the first week (shaded).

Why it's better: The "before" is a label and a bare chart—it makes the reader do all the interpretive work, and the scanner does none of it. The "after" states the finding in the caption, marks the critical threshold on the chart, and names the implied action, so both the careful reader and the scanner leave with the same conclusion. The data didn't change. The reader's odds of grasping it went from "if they study the chart" to "at a glance."

🔄 Check Your Understanding Why is an interpretive caption especially important in a data report, more so than in, say, a novel or a marketing brochure?

Answer

Because data reports are scanned and skipped through, not read linearly, and figures are the first thing a scanner's eye lands on—so the caption is often the only text attached to your central evidence that a hurried reader processes. (Chapter 4: readers scan; Chapter 9: a figure doesn't speak for itself.) A novel is read sequentially, so meaning accumulates; a data report is raided for conclusions, so each figure must carry its own. If your caption only labels, the scanner takes away a topic and misses the finding you spent weeks earning—the worst possible outcome for the most important exhibit in the document.

📐 Project Checkpoint

This chapter builds Portfolio Piece 4: the data-analysis memo with visuals—and it's the piece where the whole book's central move, leading with what the reader needs, gets its most direct test.

Where you are. Back in Chapter 9, you produced or selected a chart with an interpretive caption, and you have been carrying a dataset and a finding since then. Now you turn that finding into a memo.

This chapter's increment. Write a one-page data-analysis memo to a specific, named decision-maker, built recommendation-first. Use a real analysis if you have one (a result from your work, a class project, a public dataset you've explored); invent a realistic stakeholder if you must, but name them and their decision. Your memo must contain, in this order:

1. A subject line that states the recommendation or the headline finding—not "Q3 analysis," but "Recommend we move X" or "Why we're losing Y."
2. A recommendation-first lead: the action you want, with a concrete next step, in the first three lines (or findings-first if your reader's job is genuinely to understand, not decide—and be able to say which you chose and why).
3. The finding as support, stated in the reader's units, with the one decisive number and an interpretive sentence (your "so what?").
4. One chart with a Level-3 interpretive caption (carry over and sharpen the one from Chapter 9), annotated if it helps.
5. A "how confident" line—two sentences of method sized to this reader, plus your honest caveats, demoted below the finding.

The test to apply to your own draft. Hand it to someone and ask them to read only the subject line and first paragraph, then tell you what you want them to do. If they can't, you buried the recommendation—rewrite the lead. Then run the "so what?" test on every finding: does each one end in an action, or did you stop at a number?

Self-assessment (rubric in exercises.md): Could a reader act after the first paragraph? Does every finding reach Level 3? Is the method demoted, not deleted? Is the caption interpretive, not a label?

Looking ahead. In Chapter 28 (Blog Posts and Science Communication), you'll take a technical finding—possibly this same one—to the opposite reader: the general public, who needs an analogy and a hook, not a recommendation memo. Same finding, the furthest audience yet. Keep this memo; you'll see how far the framing has to travel.

27.9 Common Mistakes and Practical Considerations

The principles are simple to state and hard to practice, because the pull toward method-first writing is strong—it's how you did the work, and it feels like rigor. Here are the mistakes that persist even after you know better, and the judgment calls the rules don't settle.

Mistake 1: Leading with method because it feels more honest. The deepest pull. Presenting the finding first can feel like you're skipping the proof, hiding the work, overclaiming. It isn't—the method is still in the document, just demoted to where the reader who wants it can find it. Leading with the finding is not hiding the method; it's prioritizing the reader. The honest move is to make the finding easy to reach and the method easy to audit. Method-first does the opposite: it makes the method unavoidable and the finding hard to find.

Mistake 2: A recommendation the data doesn't support. The over-correction to the "so what?" discipline. Once you're told every finding needs an action, you'll be tempted to manufacture one even when the data only supports an observation. Don't. If the analysis shows what but not why, your recommendation must say so: "the data shows X; the likely cause is Y, which we'd confirm before acting." A confidently-stated recommendation built on a finding that can't bear it is the most dangerous thing in this chapter, because clear writing makes a weak inference more persuasive, not less. (Chapter 38 treats this as an ethical obligation.)

Mistake 3: Burying or omitting the caveats. The mirror image. In the rush to lead with a clean recommendation, writers drop the confound they controlled for, the sample limitation, the period the data doesn't cover. The caveats don't belong in the lead, but they must be somewhere—in the "how confident" line, in a footnote, in the method section. A finding presented without its limits is a finding that will embarrass you when someone asks the obvious question. State your confidence honestly: "strong and consistent" when it is, "directional—worth a deeper look" when that's the truth.

Mistake 4: One memo for genuinely different readers. The Chapter 2 lesson, recurring. If your analysis must go to both the VP (who needs the recommendation) and the analytics team (who need the method), the instinct is to write one document that serves both—and it serves neither, because it's too technical for the VP and too thin for the analysts. First try to layer one document (recommendation-first summary up top, full method in an appendix), the way a good report does. If the needs truly conflict, write two: a memo for the decider, a technical writeup for the peers. Two right documents beat one compromised one.

Mistake 5: Precision theater. Reporting "churn increased by 4.237%" when the analysis can't support the third decimal, or "$1,243,887 in recoverable revenue" when the estimate is a rough model with wide error bars. False precision signals either that you don't understand your own uncertainty or that you're trying to look authoritative. Round to the precision the analysis actually supports, and where the number is an estimate, say so: "roughly $1.2M," "an estimated 8,000 clicks a month." The honest round number is more credible than the dishonest exact one.

The judgment call: findings-first or recommendation-first? The chapter's central technique has a boundary, and you should know which side you're on. Lead with the recommendation when the reader's job is to act—approve a budget, pick an option, ship or don't (Renée). Lead with the finding when the reader's job is to understand and judge for themselves—a peer reviewing your analysis, a scientist who'll draw their own conclusions, a regulator who would resent a pushed recommendation. The deciding question, as always, is Chapter 2's: what does this reader have to produce at the end? A decision → recommendation-first. An informed judgment → findings-first. When in genuine doubt, findings-first is the safer default, because it never feels like you're getting ahead of the evidence.

A note on tools. Whatever you used to make the chart—a notebook, a BI tool, a spreadsheet—remember Chapter 9's distinction: the chart you made to find the result (exploratory, cluttered, for you) is not the chart you publish to show it (explanatory, clean, for the reader). Don't paste your search. And the dashboard your BI tool generates by default labels everything in database column names; the interpretive titles and annotated labels of §27.7 are something you add, deliberately, after the tool is done.

Frequently Asked Questions

How long should a data-analysis memo be?

Short—one page, ideally; a page and a half at most. A memo is a memo because it's brief. If it's running longer, the method has usually crept up and displaced the findings: cut the method to what this reader needs to trust the result and push the rest to an appendix or a linked notebook. The discipline of one page forces you to lead with the recommendation and demote the apparatus, which is exactly the discipline this chapter teaches. When you genuinely have five findings and three figures' worth of material, you've outgrown a memo—write a report with a recommendation-first executive summary (§27.6) instead, and let the page-one summary do the memo's job.

Should I lead with the finding or the recommendation?

Lead with the recommendation when the reader's job is to act—approve, choose, ship (a VP, a client, a committee). Lead with the finding when the reader's job is to understand and judge for themselves (a peer reviewing your work, a regulator, a scientist who'll draw their own conclusion). The deciding question is what the reader has to produce at the end: a decision means recommendation-first; an informed judgment means findings-first. Both are vastly better than leading with the method. When unsure, findings-first is the safer default because it never feels like you're getting ahead of the evidence.

What exactly is the "so what?" test?

It's the habit of asking, of every number you report, "so what should the reader do about this?"—and not stopping until you have an answer. A finding moves through three levels: observation (what the data says), interpretation (what it means), and recommendation (what to do). Most writing stops at the observation; the "so what?" test pushes it to the recommendation, the only level the reader can act on. Run it before you write, so the recommendation that belongs at the top of your memo already exists. The one limit: the recommendation must be supported by the finding—if the data shows what but not why, say so rather than inventing an action.

How do I write about data without dumbing it down?

By translating, not deleting—the Chapter 2 distinction. Dumbing down removes information or condescends; translating keeps the full finding and changes the vocabulary and order to fit the reader. Dana's recommendation-first memo to Renée contains the same finding as her technical writeup for her peer; it just leads with the consequence ("seven times higher") instead of the mechanism ("partial-dependence is monotonic past day 14") and demotes the method. If your "simplified" version is missing the actual finding, you gutted it. Respect the reader's intelligence; just don't assume their jargon, and put the method where they can audit it if they choose.

How is writing a dashboard different from writing a memo?

A memo is read once, linearly, by a known reader making a specific decision—so it can carry a full recommendation. A dashboard is glanced at repeatedly, by viewers in a hurry, with data that changes—so it can't bake in a fixed conclusion, but it must still interpret. The dashboard's writing lives in tiny places (titles, labels, tooltips) and its job is to answer, at a glance, "what does this number mean and is it good or bad?": titles that state the takeaway or the question (not the topic), labels with units and a comparison ("vs. target"), tooltips that explain the anomaly or define the metric. And because you don't rewrite it daily, the interpretation must stay true as the numbers move—title for the question, not a claim that's false next week.

Chapter Summary

Key Takeaways

• Most data writing fails because it's written in the order you did the work, not the order the reader needs. You did it method → finding; the decision-maker needs finding → method. Reversing that order is the single most important move in writing about data.
• A finding is not a conclusion until it answers "so what?" An analysis that stops at the number has stopped one sentence too early and handed its hardest step to the reader least equipped to take it. Push every finding from observation → interpretation → recommendation.
• For a reader whose job is to act, lead with the recommendation; for one whose job is to understand, lead with the finding. Both beat leading with the method. The order follows the reader's purpose (Chapter 2).
• An executive summary for data leads with the insight, not the methodology, quantifies the stakes in the reader's currency, names confidence in a phrase, and points to the method rather than reciting it.
• Dashboard text interprets in tiny spaces: titles state the takeaway or the question, labels carry units and a comparison, tooltips explain. Wherever a number appears, tell the viewer what it means and whether it's good or bad.

Action Items

1. Before writing, run "so what?" on your finding until you reach a recommendation (or honestly conclude the data only supports an observation). The recommendation you find goes at the top.
2. Write the subject line and first paragraph last, after you know your recommendation, and make them carry the whole decision.
3. Demote, don't delete, the method—size it to the reader, put it below the finding, keep the caveats honest.
4. Caption every chart at Level 3 (interpretation), and annotate the chart itself at the point where the story lives.
5. Apply the standalone test: could the reader act after only the subject line and first paragraph (memo) or the summary alone (report)? If not, you buried the lead.

Common Mistakes

Decision Framework: Writing About a Finding

Spaced Review

A few questions reaching back, to strengthen retention.

1. (From Chapter 9) Climb the three levels of a figure caption (label → observation → interpretation). For a bar chart showing that enterprise customers renew at 95% and small-business customers at 70%, write a Level-3 caption.
2. (From Chapter 20) What is the "standalone test" for an executive summary, and how does it apply to the executive summary for a data report?
3. (From Chapter 26, bridging) A tutorial guarantees the reader a success experience; a data memo guarantees the reader a decision. How does the recommendation-first structure of this chapter serve the memo reader the way a tutorial's hand-holding serves the learner?

What's Next

You've now written a finding for the reader who has to act on it—a decision-maker who wants the recommendation first and the method demoted. Chapter 28 (Blog Posts, Articles, and Science Communication) takes the same finding to the reader at the far end of the spectrum: the general public, who owes you nothing, will leave the instant they're bored, and needs not a recommendation but a hook and an analogy. You'll meet Dana's churn finding one more time—as a blog post—and learn the jargon budget, the opening hook, and the analogy as the fundamental tool of explaining technical ideas to everyone. The finding stays the same; the audience moves as far from the VP as it can go.

Practice: Exercises · Quiz Go deeper: Case Study · Case Study 2 Review: Key Takeaways · Further Reading