The ugly truth about product demo storytelling in data teams
Storytelling

The ugly truth about product demo storytelling in data teams

How to make data product demos more engaging and persuade people to care about the data
Bartosz Mikulski
Bartosz Mikulski – 10 min read

In one of my projects, we noticed fewer and fewer people attending our Sprint Demo meetings. The attendees were not asking questions. Nobody cared. We wanted to change that and make the meetings more engaging. I don’t remember who came up with the idea, but it was probably our Scrum Master. In his opinion, people want to hear a story. So we should try storytelling during product demos.

It was a brilliant idea, but it made our demos even more terrible. After a few months, anyone mentioning storytelling was shushed. When someone started telling a story during the demo, people were cringing and groaning, “Nooo.” Out loud. In front of stakeholders attending the demo. It wasn’t bad, though, because the stakeholders were bored too and didn’t listen anyway.

In this article, I tell you what went wrong and explain how to do it better. In the end, I’ll suggest how to tell stories in a data team.

The Narrative Arc

What is a story? Jon Franklin, the author of “Writing for Story,” defines stories like this:

A story consists of a sequence of actions that occur when a sympathetic character encounters a complicating situation that he confronts and solves.

However, a sequence of actions is not enough. It is not any sequence of steps. For an interesting story, we need a little bit more structure - the narrative arc. The story passes through a series of stages.

We begin with exposition. At this stage, we share the minimal amount of information required to set the scene and introduce the protagonist. The exposition tells who takes part in the tale, when and where it happens, sometimes it gives a hint on why it happens, but there is no action yet. Think of it as the first 15 seconds of a Friends episode. We see four people sitting in a coffee house. The fifth one opens the door, walks into the establishment, and looks very depressed. We anticipate bad news, but we don’t know what happened yet. We’ll learn what happened to the fifth character along the way. Those events are not a part of the exposition because such a long introduction would be boring, and we can’t delay the action line.

What happens next is the “Plot Point A” or “engaging the complication.” Something is wrong, and this is the first time we hear about it. Most importantly, Plot Point A starts the “rising action” stage. We describe the sequence of events to keep the audience interested. Every event in the series must be more intense than the previous one, but it does not mean that the situation cannot calm down for a while.

Have you read the book Martian? In every chapter, something almost kills the protagonist, he goes through a series of actions to solve the problem, and everything calms down. Then, the next chapter starts with an even bigger problem. The whole book has a narrative arc, and every chapter has its narrative arc following the same rules. That’s why you can’t put the book down until you finish reading it.

Eventually, the plot points get to a crisis, the top of the action, a situation that cannot possibly be worse. What happens during the crisis depends on the genre. In a tragedy, the problem destroys the protagonist. In an action movie, this is the scene where the bomb is about to explode. In romances, the most crucial part happens during the proposal. In war stories, the crisis is the final battle. The event resolving the problem is called the climax. The protagonist dies or succeeds.

After the climax, we don’t have much time to finish the narrative. After all, everything that was supposed to happen already happened. Now is the time for “falling action.” The soldier comes home and hugs his parents. The lovers get married. The police officer who defused the bomb drinks sits at a bar with colleagues and drinks a beer while talking about finally retiring from the service. And this is the end. We don’t see a follow-up story about the post-war career of the soldier. We don’t see the lovers raising children or the police officer going fishing. Those events could make good stories by themselves, but they are not a part of the story you are telling right now.

The Product Demo Narrative Arc

What about the typical product demo narrative arc? If we have user personas, the exposition is the easy part. The user sits in front of a computer and tries to solve a problem. We work in IT, so nothing exciting happens during the exposition (unless you try storytelling in an outage report).

After the exposition, we deliver Plot Point A, which is usually the only plot point and the crisis point at the same time. In product demos, the complication destroying the life of our protagonist is… a missing feature in the software he/she uses.

The disappointing climax occurs when the storyteller announces the solution. The development team solved all of the protagonist’s problems by… releasing a new feature. Does this look like a climax? Unfortunately, the feature the team has just released is not as big of a deal as they wish it were.

But it gets even worse!

The is no falling action. You can end a good story with one sentence like “They lived happily ever after.” However, a product demo story does not end quickly. The falling action stage turns into a laundry list of features, clicking around the interface to show the features “in action,” and nagging inquiry “Do you have any questions?”, “Questions?”, “Questions? Anyone?”

Let them go! If they cared, they would have questions. But, probably, they are not the real stakeholders. How is that even possible? Answer a simple question: do the people who pay for the project attend the demo, or do they send their assistants instead?

Let me tell you a story

What is the best way to start a story? Start telling it! What is the worst way? Giving a heads-up: “Let me tell you a story.” There is only one good story starting with “Let me tell you a story…” and it is an Iron Maiden’s ballad.

The idea of announcing what will happen before telling what you want to say reminds me of Pavlov’s dog experiment or reinforcement learning. You give the audience a cue by saying, “Let me tell you a story,” they make an action and get a reward. To be precise, they make an action that maximizes their reward.

In this case, the action is opening Facebook in the browser, looking out the window, or checking a news website to avoid paying attention to your lousy story. Thus, they avoid discomfort and boredom. Escaping a punishment (a bland narrative) is a good enough reward.

If you can’t tell an engaging, action-packed story, don’t give hints when the audience does not need to listen.

A fake story is worse than no story

What is the biggest problem? Almost all the product demo stories are fake. Even if a customer has a massive problem because of a missing feature, your team delivered the feature, and the customer is happy and forever grateful, you don’t know about it. You don’t know because nobody talks with the users. The team delivering the feature hides behind the product owner, stakeholders, and the UX team. They never see the actual user.

We know the story is fake, and it is hard to tell an interesting fake story. First of all, our expectations are higher. If it did not happen in reality, the narrative must be perfect. In non-fiction, we don’t have such expectations. We know that real life is different than novels. The lousiest real testimony is going to be received better than the best fake tale.

How to tell a story in a data team

Let’s start with the most critical part: “Data storytelling is supposed to be non-fiction”. So if there is no real story about your data, no story about the users, no story about people who use the data, don’t try storytelling.

That being said, how do we incorporate data into the narrative? First, I’ll show you an example of a story told terribly from the book “On Writing Well” by William Zinnser. William Zinnser shows a travel memoir whose author has no control over the structure of the narrative:

“My wife, Ann, and I had always wanted to visit Hong Kong,” the writer begins, his blood astir with reminiscence, “and one day last spring we found ourselves looking at an airline poster and I said, ‘Let’s go!’ The kids were grown up,” he continues, and he proceeds to describe in genial detail how he and his wife stopped off in Hawaii and had such a comical time changing their money at the Hong Kong airport and finding their hotel. Fine. He is a real person taking us along on a real trip, and we can identify with him and Ann.

Suddenly, he turns into a travel brochure. “Hong Kong affords man fascinating experiences to the curious sightseer,” he writes. “One can ride the picturesque ferry from Kowloon and gawk at the myriad sampans as they scuttle across the teeming harbor, or take a day’s trip to browse in the alleys of fabled Macao with colorful history as a den of smuggling and intrigue. You will want to take the quaint funicular that climbs…” Then we get back to him, and Ann and their efforts to eat at Chinese restaurants, and again all is well. Everyone is interested in food, and we are being told about a personal adventure.

Then suddenly the writer is a guidebook: “To enter Hong Kong it is necessary to have a valid passport, but no visa is required…”

I admit it is tempting to intertwine the story with the data. It even seems like a great idea. The listeners, however, cannot pay attention to the plot and the data at the same time. Because of that, I suggest starting with storytelling to make people interested. Then, when you finish telling the story, the audience is ready to see the data.

You may begin the data part by saying, “We found out about the user’s problem when we looked at the {metric name} dashboard. We saw this strange looking value. It was unusual because {an explanation}. We reached out to {the user} and find out {the summary of the story}. But there is more! Let’s look at this chart… {continue showing the data}.”

Beware of a trap. If a lot happened between seeing the data point for the first time and getting an explanation from the user, shorten the chain of events. Of course, if you speak to the data-interested audience, describing the whole investigation in detail may be the most exciting part. In such a case, make the analysis your entire story.

This observation leads to the last part: know your audience and know what you want to tell. Nothing is worse than a gripping story told to the wrong audience. They may enjoy hearing it, laugh at the right moments, and have fun, but they don’t care.

Older post

Multimodel deployment in Sagemaker Endpoints

How to deploy multiple models in a single Sagemaker Endpoint?

Newer post

How writing can improve your programming skills

How writing texts for people makes you a better programmer

Related Posts