Storytelling with Data: How Dev Leaders Make Metrics Matter

Let’s be honest: in most game and software teams, data gets visualized but not understood. Dashboards get built. Charts get shared. But insight? Alignment? Action?

Too often, they get lost in the noise.

That’s the gap Cole Nussbaumer Knaflic addresses in Storytelling with Data. It’s not a book about building dashboards. It’s about building clarity. It teaches you how to turn raw charts into compelling narratives that drive decisions—without overwhelming, confusing, or losing your audience.

For dev leaders—whether you're running sprint reviews, pitching a roadmap shift, or escalating a live ops issue—this book offers a practical, visual playbook for making your point stick.

Here’s what you need to know—and how to apply it.

Start with the Message, Not the Metrics

If you only take one idea from this book, make it this: decide what you want to say before you build the chart.

Too many updates begin with “here’s what the data shows.” But great communicators begin with: “here’s what this means.” In game and software development, where stakeholders come from wildly different domains—engineers, creatives, marketing, product—you can’t afford to make them guess.

Before you build a slide, ask yourself:

• What’s the one thing I want my audience to remember?
• What action or decision should this insight support?
• What’s the story I’m trying to tell?

This forces prioritization. It helps you strip away clutter. And it sets you up to design visuals that serve the story—not compete with it.

Dev Application: Before your next sprint review or OKR update, write your insight in one sentence—without opening Excel or Power BI. Build the chart after you’ve framed the message.

Understand Your Audience—Then Guide Them

Knaflic emphasizes this truth: your chart doesn’t speak for itself—you do.

That means your job isn’t just to show the data. It’s to lead your audience through it. You do that by tailoring your message to their needs, and removing anything that gets in the way of understanding.

Ask:

• What do they already know?
• What context do they need?
• What decision are they here to make?

If you’re presenting crash rate trends to an engineering team, dive into details. But if you’re briefing executives, focus on risk, player impact, and what needs to change.

Dev Application: Don’t build one “master” chart for every audience. Version it. Exec version. Team version. Partner version. Guide each one differently.

Declutter, Simplify, Highlight

The biggest enemy of clarity is visual noise. Knaflic walks through how most charts include way too much: unnecessary borders, tick marks, colors, gradients, labels, shadows.

Her advice is simple: declutter aggressively.
Then: highlight intentionally.

Strip away everything that doesn’t support your point. Then use color, size, and positioning to direct attention.

Example: If you’re showing DAU by platform and want to emphasize a drop on mobile, don’t give each bar a different color. Make all bars gray. Make mobile bold red. Boom—now the message is visual.

Dev Application: Use a “1-Color Rule.” Everything in your chart is gray—except the thing you’re drawing attention to.

Choose the Right Visual for the Job

Not all charts are created equal. And not all fit every story.

Knaflic offers a practical breakdown of which chart types are best for different kinds of data relationships:

• Line chart = change over time
• Bar chart = comparison across categories
• Scatter plot = relationships or clusters
• Stacked bar = composition (use sparingly)
• Slope graph = before/after change
• Bullet chart = performance vs. target

Don’t default to the tool’s default. Don’t pick a pie chart because it looks pretty. Pick the chart that makes your message clearer.

Dev Application: Ask “What’s the relationship I want to show?” before you touch the chart type dropdown.

Use Text and Annotation to Anchor Meaning

This is one of the most powerful lessons in Storytelling with Data: label your chart like a headline, not a filename.

Instead of titling your slide “Retention,” title it:

“Retention dropped after onboarding change—especially among new console users”

That’s a takeaway, not a topic.

Then annotate directly on the chart:

• Use callouts.
• Use arrows.
• Highlight inflection points or clusters.
• Use shaded areas to mark critical ranges.

Your audience shouldn’t have to work to find the insight. Show them. Guide their eye.

Dev Application: Add a sentence above your chart. Not “DAU Trends.” But:

“Mobile DAU fell 11% after patch—rooted in login bug now resolved.”

Design for Scanability—Because You Have 5 Seconds

Most people spend 3–5 seconds looking at a chart before deciding if it’s worth understanding.

That means:

• Don’t cram multiple charts onto one slide.
• Don’t use dense labels or tiny fonts.
• Don’t show decimals unless they matter.
• Don’t force your audience to cross-reference legends.

Build for scanability.
Make the chart readable in five seconds. If they want more detail after that—great. But the first read should give them the gist.

Dev Application: Before showing a chart to your team, close your laptop. Count to five. Then ask: “What’s your first impression?” If it’s not clear, simplify.

Tell a Story—Not Just a Sequence

This book is titled Storytelling with Data for a reason. Knaflic doesn’t want you just to polish your charts. She wants you to craft a narrative.

Your update—whether it’s a one-slide dashboard or a 10-slide quarterly review—needs a beginning, middle, and end.

Think:

• What’s the setup?
• What changed?
• What’s the implication?
• What should we do?

Without that arc, you’re presenting data. With it, you’re leading a decision.

Dev Application: Try using the following narrative frame in sprint reviews:

“Here’s what we expected, here’s what happened, here’s what we think it means, and here’s what we’re doing about it.”

Test, Iterate, and Ask: Did It Land?

Great storytelling isn’t one-and-done. It’s iterative.

Knaflic encourages storytellers to get feedback early. Show drafts. Ask teammates what they take away. Watch where they get confused. Then tweak.

In dev settings, this means workshopping your updates the way you’d workshop a feature. Test it in safe spaces before going to high-stakes reviews.

Dev Application: Before your next studio update, grab a peer. Walk through your 3 slides. Ask, “What’s your takeaway from this?” If they don’t nail it, neither will your VP.

Final Thought: This Is a Leadership Skill, Not a Design Skill

Here’s what makes Storytelling with Data so useful for dev leaders: it treats communication as part of the work—not as an afterthought.

It’s not about fluff. It’s not about design.

It’s about clarity. Direction. Impact.

In software and game development—where you’re managing ambiguity, aligning cross-functional teams, and pushing toward bold outcomes—that’s the whole game.

Tell stories with data. Make them land. And lead with clarity.