Why to Tell a Story
The origin of this article is an often repeated experience when Product Managers are asked to give briefings and status updates. They often start talking numbers, figures and dates which leads to a lot of data and little information actually being transferred to the listener.
One specific example was a project which mission it was to take a decade old website and give it new functionality, mobile responsiveness and to fit it to a new company branding.
The development team struggled to understand what was expected from them and the project was started with a highly unrealistic schedule. In other words: A normal Tuesday. Only when the Product Owner started switching up her language and focused on creating a story for the development team, she started getting traction.
Allow me to take you on a brief journey on why storytelling helps the production cycle – and to try to give you ideas on how to create your very own story, fitting your environment and product.
A “story” in this context means a coherent narrative, which leads from the first moment of the situation (project/product idea), shows how all participants came to the place and status they are in and opens up the path towards reaching the goal. A stories life-force are the characters, conflict and resolution.
This way of looking at roadmaps, development procedures, conflict and your product has several advantages:
- It allows your audience to engage.
- It forces you to have a coherent plan and prevents hiding from figures and abstract assumptions (9 women; one month; 1.2 babies (due to expected synergy effects)).
- It gives tangible, believable goals (and if the story doesn’t, it needs to change).
- It links abstract plans back to reality, allowing the audience to understand what is being said.
- It opens the product and process to feedback, focusing on the goals and the distinct steps.
As you can see, a story does not replace your process of preparing and reacting – it is a way of conveying a plan. It is a tool to engage your team, sponsors and users.
To understand the obstacle and how your team and you help overcome it is not only a good way of understand your own message – you now have a direct link into their motivation:
No longer are they working on Story Issue-4711, they are helping their (!) users/clients/sponsors. You now make sure that they know that they are not only a cog in the machine, they are part of their own tale – and often, they are the protagonist.
Storytelling is a tool which can be used on topics of all scales – from a single, feature based topic to the product life-cycle. To find the main parts of the story is a good analysis of your topic at hand. Even if you never intend to tell it, just by compiling it you improve your communication skill set at any given time.
How to Create a Story
First off: To tell your story, all you need to do is convey information that you already have – all you need is to put conscious effort into altering the way you think about them.
The first question to answer is who’s the stories audience and how they connect to the story. To tell a story, you want to address the audience in way that they understand, use the language that they use – and make them the hero.
Who the audience is varies – but usually, there are at least two different ones:
On the one hand we have so-called sponsors and stakeholders: people who have an interest (an influence) in the results of your production and the production circumstances. “How long?”, “How expensive?” , “You sure you need that server?” are usual questions asked.
On the other hand you have a development team: A team which usually has an inherent interest in making awesome stuff happen. “What do you mean?”, “Why this way” and “What else depends on this?” are example questions that get asked from there.
Both sides have little in common – in some cases not even their employer. Yet, the same story can have different heroes, working towards a common goal.
In addition, thinking of how they became part of the story helps to create a personal touch.
Once you know to whom you’re telling your story, make yourself aware of what the conflict or obstacle is that your protagonist (audience) is facing. It’s only natural that different people have varying perceptions of a topic. Make sure that your audience knows what you are talking about by taking the time to reframe your story:
Find what makes you excited or what worries you and put it into context and words that your audience understands the nature of the issue.
“We need to release in Q3 to increase our gross margin” is something that your CFO might understand, but for your development team, it might be more engaging to focus on what has the potential to excite them:
They can learn instead that they are finally giving their users that one feature they asked for since 2007, on time before that big summer sale rush. Both perceptions are valid and both are reframed versions of each other. One important point: Stick to the truth. Every project has enough potential for good storytelling, there is no need to add dramaturgic effects. Storytelling is not about exaggerating, it is about conveying information in a way that your audience has the easiest time possible to process it and help you improve the product and project.
The last step is usually easy, because you’re permanently working on it: How is your audience helping to overcome the conflict or obstacle?
Your sponsor managed to unfreeze budget, which will make it possible for your team to realize the dire needed product in time. Or they managed to get that one person your team really wanted to work with.
Your development team worked on a feature which was deemed impossible to realize because the technology wasn’t there yet. Still, they have already proven that their way will work / have a novel idea which is testable / have found a workaround / found a substitute / etc / etc / etc.
If there is no approach yet, then a story is even more suited: Invite your audience to complete it together with you. When you activate their creativity and engagement you will either find a solution, a substitute or are forced to face the truth that the story needs to change.
When to Convey the Story
To tell a story is a strong tool to have in your arsenal. I recommend using it often. Train yourself to think in form of a coherent message – with a protagonist, a conflict and a resolution.
Even without ever telling the narrative to your audience – purely having it will put you in a position which allows you to talk about your product in an engaging way.
The opportunities to go full all-in on your story will present itself as well though:
- When you want to reinforce the self purpose within your development team
- When you need a sanity check from someone
- When you (re)activate the creativity of your team
- When you remind a sponsor on what your intention is
Presenting your story needs a lot of effort. When you decide to tell it make sure that your audience has the time to listen. Also make sure that they have the mental potential to follow. Close to a milestone release, there is usually little benefit in giving perspective or to try to get agreement – people’s minds are stuck in the moment and you’d have a hard time and little reason to shift the focus.
On the other hand there will be situations where there’s insecurity within your sponsors or where you see the need to align your team behind your product. This might be a good time to come together and take a look at how the story might end – just make sure it’s a happy one.
If, for any given event, you’re unsure if a spreadsheet or a story is the proper tool ask yourself: “What kind of feedback do I want?”. If you’re looking for creative or goal focused feedback, go for the story; if you’re looking for analytical or process feedback, it might be time to objectify the situation. Put together a sheet and create some flowcharts instead.
“Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn’t.” – Mark Twain