A data scientist with five years in the job asked on r/datascience in May whether it is normal that most of the insights they deliver are ignored. The people they deliver to, they wrote, "Say 'thanks' and never use it", or cherry-pick the numbers that support what they already think. The thread has more than 570 upvotes. A few months earlier an analyst two years in asked for help because, when presenting, "I just end up reading the numbers off the slide like a robot".
Some of that is politics and you cannot fix it with a slide. A lot of it is how the work gets handed over.
The deck answered a question nobody asked
In our Data Storytelling 101 workshop on September 2, 2026, Hai Guan flipped through a 17-slide churn deck for a made-up B2B company: an executive summary, a methodology slide, then cut after cut of the data, key findings, and recommendations at the end. The chat said "TMI, lots of text, hard to digest." When Hai asked who thought it was a good deck for an executive, the reply was another question: "will an Exec read all that?"
The problem was the question it answered. The executive had asked how the numbers look. The deck answered "what data do we have?" The question behind the question was closer to "what should I do about this?"
Three slides: the problem, what you found, the ask
Week 5 of our AI Analytics for Everyone course teaches a readout with three slides and an appendix. The first slide says what is broken and how big it is. The second says what you found, with one chart. The third says what you want done, what it costs and what you expect back. The whole thing takes about five minutes to present. Everything else, all the other cuts you ran, goes in the appendix, where you can open it when someone asks.
Each title is a full sentence that states the finding. In the workshop example, "Q3 revenue overview" became "we lost $10 million in ARR, and most of it was preventable." Read the three titles in order. If they tell the story without the slides under them, the deck works.
If you cannot write the third slide, you do not have a recommendation yet. "We recommend further investigation" is not an ask. A real ask is something a person can approve: two engineers for three weeks, or a fixed budget for a quarter.
Put a price on waiting. The example in the course ends its ask with what each month of delay costs, because the room tends to treat spending the money as the risky choice.
Say what you would do
Hai called "continue to monitor the trends" a non-action that looks like an action. Nothing changes because of it, and people forget it. His point in the workshop was that a specific recommendation starts a discussion even when it turns out to be wrong: "you don't have to be right, you just have to be the person that ... gets people to talk about and care about this topic."
Fear of being wrong softens everything to "the data suggests" or "it might be worth considering." Say how sure you are and why instead. "I am 70% confident because..." gives a decision-maker something to work with. "It might be worth considering" does not.
Write down the hardest questions first
Write down the questions you will get before the meeting. Is this causation or correlation? Why should I believe this number? What happens if we do nothing? Who else has looked at this? Answer the hardest ones in the appendix, so when they come up you turn to the page.
In the workshop, Hai had Claude Code rank the findings in a finished churn analysis by how much each should change what the CFO does next, then write the outline and the deck. His last prompt began "Now be my toughest reader. You are the CFO." It asked for the five hardest questions, the thinnest evidence and the strongest case for doing nothing, with a drafted answer to each using only what was in the analysis. The first question it came back with was causation: the deck recommended a fix for a cause the analysis had not proven.
Hai's warning: the drafted answers will sound sensible whether or not they fit your business, so read them as drafts and check the numbers yourself. How to check them is on how to check an AI data analyst's answer.
Talk to engineering before the VP
The order of the conversations before the decision meeting matters: your own team first, to catch mistakes; then engineering, to confirm what it will take; then a champion who will argue for it when you are not in the room; then leadership. If the VP says yes to three weeks and engineering then says twelve, you have a credibility problem you made yourself. "Engineering confirmed three weeks" is a much stronger sentence to bring into the room than "I estimate three weeks."
Write down how you will know it worked
Once a decision is made, write down four things: what was decided and when, the success metric and its target, the date you will check, and who owns the check.
An example: release the simplified mobile checkout in sprint three of Q2, measure mobile checkout completion, target two percentage points higher within 60 days of launch, read out at day 30 and day 60, owner you. Without the follow-up, you never learn whether the analysis was right, and six months later nobody remembers that it drove the decision. Five to ten of these a quarter is a list of decisions you drove, with what happened after each, and that list is useful in a promotion case and in an interview.
It also helps with the person who ignored your last analysis. A written target and a date make the next conversation about what happened, and the analyst who wrote them down gets to report it.
If you are a product manager doing this analysis yourself, the same rules apply, and should product managers do their own analytics covers the split between your work and the data team's.