I once watched a good analyst spend eleven minutes of a fifteen minute slot explaining how she had deduplicated the customer table. The head of sales stopped listening around minute four. Her recommendation, which was correct and worth roughly 400,000 dollars a year in retained revenue, landed at minute twelve in a room that had already mentally moved on to the next agenda item. Nobody argued with her. Nobody acted either.

That gap between correct work and acted upon work is where most analyst careers stall. Everything in this series so far has been about producing a trustworthy number. This part is about the twenty minutes where that number either changes a decision or quietly dies. There is no code here, because nothing in this part is a technical problem.

What stakeholders are actually deciding

A stakeholder is anyone whose decision your work is meant to inform: a product manager choosing what to build next, a finance lead approving a budget, a marketing head deciding where to move spend. They are not in the room to evaluate your analysis. They are in the room because something has to be decided and they would rather decide it with evidence than without. Once you accept that framing, most presentation questions answer themselves.

So before you open a spreadsheet, get answers to four questions. What decision does this analysis feed? Who actually makes that decision, as opposed to who attends the meeting? When does it need to be made? And what result would change their mind, versus what result would confirm what they already believe? That last one is the most revealing. If no possible finding would change the decision, the decision has already been taken and you are being asked for cover, which is worth knowing before you spend two weeks on it.

There is a category of work that informs no decision at all, and it is larger than most teams admit. Monthly numbers that nobody acts on, dashboards nobody opens, refreshes that exist because they existed last quarter. These do not need a meeting. They need a short written summary in an email or a channel post, and the honest move is to say so rather than manufacture a presentation around them. Protecting the calendar is part of the job.

Write the one sentence first

Cole Nussbaumer Knaflic, whose book Storytelling with Data is the standard reference on this, teaches two habits that do more for a presentation than any chart. The first is the Big Idea: a single complete sentence that carries your point of view, states what is at stake, and commits to something. The second is the three minute story, which is what you would say if you had three minutes, no slides and no laptop, and had to leave the listener knowing what to do.

These sound soft until you try them, at which point they are brutally clarifying. Most half formed analyses collapse the moment you attempt the sentence, because you discover you have a description rather than a finding. Compare two attempts on the same work. Weak: churn varies by plan tier and is higher on the Basic plan. That is a caption. Strong: customers on the Basic plan churn at nearly three times the rate of Pro customers, which costs us about 41,000 dollars a month, and the pattern points at onboarding rather than price, so I want to test a guided setup flow for Basic signups this quarter.

The second sentence names the size, converts it to money, offers a cause, and asks for something specific. Every slide you build afterwards exists only to support one of those four claims, which is a filter that removes about a third of the deck before you draw it. If you cannot write that sentence, you are not ready to present, and the fix is more analysis rather than more design.

Rehearse the three minute version out loud, on your feet, without slides. It feels ridiculous in an empty room and it is the single highest return thing on this page. It exposes the sentence you cannot say smoothly, which is nearly always the one you do not fully believe, and it means that when your slot is cut from twenty minutes to five you have already practised the version you will actually give.

flowchart TD
  D[Name the decision and the decider] --> F[Finish the analysis]
  F --> B[Write the Big Idea in one sentence]
  B --> C{Does it name a number, a cause and an ask?}
  C -->|No| F
  C -->|Yes| T[Rehearse the three minute story out loud]
  T --> S[Storyboard on paper]
  S --> K[Build only the slides that support the sentence]
  K --> A[Move everything else to the appendix]

Structure that survives a shortened meeting

Analysts are trained to present chronologically: here was the question, here is how I got the data, here is what I cleaned, here is the method, and finally here is the answer. That order is correct for a thesis and wrong for a business meeting. Journalists call the alternative the inverted pyramid, and it puts the conclusion first, the supporting evidence second, and the method last, on the reasonable assumption that a reader may stop at any point.

Build in three layers. Layer one is the recommendation and its value, thirty seconds, one slide. Layer two is three to five pieces of evidence, each one slide, each with the message written into the slide title. Layer three is the appendix: definitions, sample sizes, caveats, the query, the rejected hypotheses. Most of your effort lives in layer three and most of your audience will never see it, and both of those things are fine. It exists so that when the sceptical engineer asks how you handled refunds, you turn to a slide instead of improvising.

The same finding also needs different framing for different rooms, and this is not spin. It is the recognition that people care about the piece of the outcome they control. The table below is how I plan the same churn analysis for three audiences before I build anything.

How much detail belongs on a slide?

One message per slide, and the message is the title. Not Churn by Plan Tier, which tells the reader nothing and makes them do your work, but Basic plan churn is three times Pro and it is getting worse. A title that states a finding turns a deck into something a person can skim in forty seconds and still get right, which matters because your slides will be forwarded to people who were never in the room.

Under that title, one chart, chosen using the rules from Part 13, with the point you are making marked directly on it. Grey out the bars that are context and colour only the bar that is the story. Add a short annotation next to the bar that matters. If a viewer has to consult a legend to find your point, the chart is doing half a job.

Convert to money wherever you honestly can. Nobody has an instinct for what a 6.8 percent monthly churn rate feels like, and everyone has an instinct for 41,000 dollars a month. Do the arithmetic yourself and show it in the appendix, because the moment you present a revenue figure someone will ask how you got it, and the answer needs to take five seconds. Here is the underlying table for the example running through this part.

Illustrative figures from a worked example. Note the trap in the last column: Basic loses the most revenue, but Enterprise and Pro together lose almost as much from a fraction of the customers, which is exactly the kind of thing a percentage only chart hides.

Explain uncertainty without hedging everything

New analysts tend toward one of two failures. They either present every number as settled fact, which eventually blows up in public, or they qualify so heavily that the room concludes the analysis says nothing. The second is more common and does more career damage, because a stakeholder who cannot extract a position from you stops inviting you.

The way out is to give a verdict and attach your confidence to it, in that order. Say the range in ordinary words rather than reciting the interval: the fix is likely to cut Basic churn by somewhere between one and three percentage points, I would plan the budget on one, and if it lands at three we will have underspent. That sentence is honest about the uncertainty from Part 18 and still tells a finance lead what number to put in a spreadsheet.

Sort what you are about to say into three buckets and use different language for each. Things you measured directly and would defend under scrutiny get flat declarative sentences. Things you inferred, where the data is consistent with your explanation but does not prove it, get the word likely and a stated reason. Things you do not know get named as open questions with a plan attached. Saying we cannot separate price sensitivity from onboarding friction with the current tracking, and here is the one event we would need to add, is a strong contribution, not an admission of failure.

What you must not do is let uncertainty become a hiding place. Phrases like the data is directional or this is early signal are sometimes true and are more often used to avoid committing to anything falsifiable. If you find yourself reaching for them, ask whether you actually lack evidence or simply lack nerve. Those need very different fixes.

Handling pushback and the awkward question

Challenges come in three flavours and they need different responses. A data challenge disputes the number itself: that is not what my report says. A method challenge disputes how you got there: did you exclude trial accounts? A conclusion challenge accepts the number and rejects what you want to do about it, and it is usually about budget, ownership or history rather than analysis. Identifying which one you are facing, before you answer, prevents the common mistake of responding to a political objection with a technical explanation.

For data challenges, go to the appendix slide and compare definitions. For method challenges, answer plainly and say what you tested: yes, trial accounts are excluded, and I checked that including them does not change the ranking of the tiers. For conclusion challenges, stop defending the analysis, because it was never the problem. Ask what would need to be true for the recommendation to be worth doing, and you will usually surface the real constraint within a minute.

Run a pre-mortem the day before. Write down the three questions you would least like to be asked, then prepare a slide or a sentence for each. In my experience the questions you dread are the questions you get, roughly two times out of three, and having a prepared answer converts the worst moment of the meeting into the moment you look most in command of your work.

And when you do not know, say so. I do not know, I will check and come back to you by Thursday is a complete, professional answer, and it costs you nothing provided you actually come back on Thursday. Guessing in front of a room is how analysts lose the thing they are hardest to replace on: being the person whose numbers hold up.

flowchart LR
  Q[Someone challenges you] --> K{Which kind?}
  K -->|My report says something else| D[Compare definitions on the appendix slide]
  K -->|How did you handle X| M[State the choice and the check you ran]
  K -->|I disagree with the plan| P[Ask what would need to be true]
  D --> O[Reconcile offline, reply with both definitions]
  M --> O
  P --> N[Name the real constraint, agree a next step]

Open with the ask and put your method in the appendix

If you change one habit after reading this, change the order. Start with what you want the room to do and what it is worth, then support it with three to five things, then stop talking and let the discussion happen. Your method, your cleaning decisions and your careful handling of edge cases go in the appendix where they are available on demand. It will feel like the work is being hidden. What is actually happening is that the work is being spent on the decision rather than on your reputation, and the reputation follows anyway, faster than it would have.

The second habit is the rehearsal. Three minutes, standing, no slides, out loud, the day before. Nearly every presentation problem I have watched a junior analyst have would have been caught in that three minutes, and it costs less time than tidying the chart formatting they usually do instead.

You can now find something true and get someone to act on it, which is the whole job in one sentence. Part 20 goes back under the hood to data modeling, and how analytics data gets organised into fact and dimension tables so that the numbers you present are consistent from one query to the next. Keep the Data Analyst guide as your map, and revisit Part 10 if finding the story is still the harder half for you.

This week, take the last analysis you finished and write its Big Idea as one sentence containing a number, a cause and an ask. If you cannot, you have found your next piece of work, and that is a more useful result than any slide you could have built.

References

• The 3-minute story, Cole Nussbaumer Knaflic, Storytelling with Data
• Data Storytelling: How to Effectively Tell a Story with Data, Harvard Business School Online
• Enhance storytelling in PowerPoint presentations with the Power BI add-in, Microsoft Learn

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts