It’s been exactly one year since I became a full-time PM with Microsoft. Among the plethora of things I’ve learned about products, one of the most resonating piece is about storytelling: A good story must make sense to the audience.
This is harder than it sounds.
The first corollary of this is that you must take time to understand your audience. (“Does the story make sense for this audience?”)
For example, what does the audience know and not know? This is something I usually need to remind myself of, because as I prepare the story, I become somewhat an expert of the matter. While otherwise great, this fact does make me more vulnerable to the risk of forgetting what information I take for granted but the audience might not have. Imagine telling the story of the Little Red Riding Hood to a kid who doesn’t even know what a wolf is yet – shouldn’t you take your time to give them a Canine 101 first so they know wolves are bad and eat people (in this story)?
Another example I usually make myself consider, is what does the audience want and, if applicable, what’s preventing them from getting it. Is the audience looking for data and insights so they can make an informed decision? Then highlight the data that would be most relevant to that decision. If the audience has tried to obtain this data but didn’t complete that task due to time or other resource constraint, don’t forget to review the previous endeavors and talk about how were the constraints mitigated.
There is almost always more than one angle to tell the same story, and picking the right one based on the audience can make your message much better received. I have had times where I talk on and on about the technical details about a new feature proposal only to be asked to tell “why is this worth doing” first, and without exception those were the times that I forgot to remind myself of what does my audience care about in that situation.
Once you can think in your audience’s shoes, you can organize your story into the most natural way for the listener. (“Is this the easiest way for this audience to consume the story?”)
One thing to consider is the ordering of your narrative. Maybe you are trying to give a review of a product’s lifecycle from planning stage to its final implementation, and it might feel like a no-brainer to tell it chronologically. But if your audience is looking to learn the reason that some final design choices were made, it might be more natural for them if you call out the final design choices and their advantages first, then move on to the other options the team visited but decided against for various reasons. This way the audience has the reason they were looking for at the very beginning, and they can mentally validate it as you revisit each alternative.
Another choice you may need to make is with the visual vehicles (if you are presenting with slides), especially graphs. Data visualization is an extremely powerful storytelling tool – when used appropriately – and there are so much literature out there on this topic, so I am just going to call out the biggest learning of my own: each element of your graph needs to convey something to the audience, otherwise it shouldn’t be there. Just because Excel includes gridlines for line graphs by default doesn’t mean you have to keep them in all scenarios; if you are showing your audience the historical trend of a variable, feel free to remove the gridlines or even data labels.
It takes mental processing power to take in any information. Well-organized stories take up less mental processing power of the audience compared to less well-organized ones, even if they end up offering the same amount of information. As storytellers, we should aim to design our story in ways that enable audience to take in the information seamlessly and automatically.
A third piece that I sometimes have to remind myself of, is to know what NOT to tell. (“Am I including anything that makes sense to me but not the audience?”)
What do I mean by this is that we don’t have to share every piece of information we have in order to tell a complete story. Au contraire, too much information can become distraction.
An example I myself usually run into and must choose to steer away from is the urge to share the step-by-step story of how I uncovered a piece of interesting data. Maybe I had to take hours to construct a really complex SQL query to get it, or maybe I chased a lead for months before acquiring the full map of data. That is when I feel this urge to boast about the awesome job I did gathering data; this could blind me from the fact that the audience, more often than not, only cares about the data itself! Storytellers should know the difference between exploratory and explanatory analysis: the former we do to get the data/insights, and the latter we do to share them. Just because it was really fun to get that data doesn’t mean I should tell the story of how I got it; rather, the right focus here is probably on the data and insights themselves.
Understand the audience, organize the story naturally and know what not to tell: these are three things that should help make more sense of a story for the audience and result in a richer storytelling experience. Of course these aren’t the only things to keep in a storyteller’s mind. Storytelling is a long journey that I have only just got started on, and I can’t wait to share more discoveries that may come along the journey with you.