Storytelling with Data

As a PM, if you're not already data-fluent, you'll get there very quickly. But you'll often be working with and presenting to people who don't share your background. Perhaps you need to persuade your engineer or designer of a course of action or give an update on your successes to the CEO. They're not in the product numbers every day like you are, so you need to not just share data with them, but use the data to tell a compelling story.

Understanding your audience

In all storytelling, your first task is to understand your audience. The point of sharing data is for your listeners to see/hear/read what they need (not what you need). Some questions you should ask about your audience when planning your story:

• Who will be in the room or on the email? (Your manager? The CEO? A team of engineers?)
• How much time do they have for this?
• Are they interested in the details, or mostly in the big picture?
• How much context do they already have on the product and situation?
• What preconceptions do they have about the product or situation? Will this reinforce or contradict those?
• What decision or action will they make or do as a consequence of seeing this data? (Will this drive their company strategy choices? Their product design choices? The content of their next update to an investor?)

You may not know the answers to these questions without doing research. In that case, doing the research is part of your storytelling process — and it's just as important as, e.g., picking the right data visualization. You can ask co-workers, assistants, and audience members themselves to learn more about them and tailor your story appropriately.

Let's imagine you're pitching a feature that you think will have a great impact on conversion rates at a tricky point in the purchase process.

If the CEO of the company has asked you to chat with him for five minutes about your idea, you probably want to bring him a visualization of the conversion funnel and early UX research results. You'll weave those together with a brief story about what stops users from converting now, why this could overcome that obstacle, and the revenue lift you expect to result.

If your UX designer has scheduled a 30-minute meeting to consider alternate design proposals, you may want to bring much more detailed data: segmented click data for different steps in the conversion funnel, eye-tracking heat maps and quotes from UX research rather than just a summary of results, and A/B test data or post-launch data for comparable features. You probably won't discuss revenue impact; the designer is more concerned with the user experience. Your story will focus on the user's feelings and challenges and how your feature could impact those.

Data storytelling principles

Structure. Good stories have a beginning, middle, and end. A simple, multipurpose data story structure is linear and moves from a description of the problem (past) to the proposed solution (present) and the anticipated results of that solution (future). You can use data to bolster any or all of these three components of the story.

Context. Data aren't very useful without context. "After launching X feature, DAUs grew 10% in the next month" sounds impressive but doesn't actually mean much. But "after launching X feature, DAUs grew 10% in the next month, compared to a previous month-over-month growth rate of 7%" or "after launching X feature, DAUs grew 10% in the next month compared to 5% for our similarly sized closest competitor" helps your listener understand the import and relevance of your data. When possible, provide baseline numbers and points of comparison.

Emotion. Sometimes PMs veer too far to the extreme of "letting the data speak for itself" and merely talking through the facts of the case. Audiences respond best to a mix of data and emotion. That's why you want to tell a gripping story supported by data. The best way to make the story emotional is to make it personal. Pick an (anonymized) user to discuss. Talk about that user's feelings and needs, and use data to generalize and quantify. (Do most users face this problem? An important subset of users? How much does this problem cost us in lost revenue potential?) Switch back and forth between the personal and the quantitative.

If your company or product has developed user research personas, this is a great use for one of those. Pick the persona this situation most impacts, and have that be your "user" for storytelling purposes. In fact, even if you don't use personas for user research, you may want to invent a few for storytelling purposes.

Balance. The point of telling a story with data is not to blindly persuade your audience; it's to make an honest case. You should be selective about what data you present in that you should only present relevant data, but you should not only present confirmatory data. If there exists data that runs counter to your analysis or conclusions, you should share that and explain why you think your analysis or conclusions are correct in spite of it. This creates a chance for you to learn from your audience (if they raise counterpoints) and gives you a reputation for fairness and honesty that will serve you well in your career. Companies want PMs who value finding the truth over being right.

Data visualization 101

Choosing the right data visualization. Different data visualizations display different patterns in data. You should develop your eye for visualizations through practice and by consuming others' data-rich presentations and blog posts, but here are some starter ideas:

• To show change over time: use a line chart (for many points) or a bar chart (to compare to a baseline, when you have relatively few points to graph)
• To show the composition of a whole: use a pie chart for static composition and a stacked bar chart or stacked area chart to show the change in composition over time
• To compare values between groups: use a bar chart or grouped bar chart (for multiple variables)
• To show data relationships: use a scatterplot (potentially with a regression line or curve) or a heatmap (particularly useful for non-numeric data)
• To display data geographically: use a geographical heatmap or bubble chart

Making the point. Use headers and data highlighting to make the conclusion that's supported by the data apparent. You can talk through the details (statistical significance, caveats on the methodology, etc.), or include notes about them if you're sharing your story in written form, but the visualization itself should make an obvious point. Compare these two graphs:

Keeping it simple. It's tempting to deploy the brilliant graph you generated that summarizes all of your findings in one data-dense image. But a graph that makes more than one point is a graph that will be partly lost on your audience. In addition to making the point of the graph obvious, keep it to a single point per graph.

Gathering feedback

You'll tell stories with data at all levels of your career as a PM, so it's a skill you should consciously strive to improve. Seek explicit feedback about how your attempts land. (You can also do a practice run with a manager or mentor and request feedback before a high-stakes presentation.) Some questions you might want to ask:

• What made sense, and what didn't? How could I have explained that better?
• Were the graphs/visualizations easy to read and quickly draw conclusions from?
• Did I give you enough context to judge the uniqueness/import of this?
• Was the level of detail appropriate to your needs?
• Did you find the story and data persuasive? If not, what would have persuaded you?
• Did you find the story compelling? What captured (or failed to capture) your interest?