Why Most Product Managers Aren’t Great Storytellers
What if I told you that you’re already a great storyteller?
Well, more specifically, you already have a lot of great stories to tell.
Truth is, we all have loads of stories but where we struggle is packaging those stories up into something that drives impact.
It’s time to change that!
To explain how, we need to first rewind back 11 years to when I was at the Royal Military College training to be a commander in the Australian Army.
The army have a funny way of doing things. For example, they essentially re-teach you how to talk. Yes, that’s right - how to talk!
The army teaches you to speak in a very deliberate, specific, and structured way.
We are taught to use specific phrases and terms. Both because specific words carry specific meanings. For example, the word CLEAR (i.e. “clear that area”) has a different meaning to CAPTURE.
We are also taught to follow certain structures.
For example, mission statements would typically follow the same format: “Platoon X’s mission is to [do Y] in order to [support our higher commands mission in some way]” and giving orders had their own format too, known as SMEAC (standing for Situation + Mission + Execution + Admin/Log + Command/Signals). I could go on.
But two key things really stuck with me from that experience:
Being deliberate with your words can help facilitate clarity and;
Having a framework for communicating important information can help you be more influential.
Fast forward a handful of years, and I found myself doing the same as a Product Manager.
I would create frameworks and structures to communicate things like the roadmap or what we are currently focusing on and why.
Fast forward a few more years, and I now find myself coaching Product Managers around the world, and storytelling is a common theme.
We are told that great Product Managers are great storytellers but the preaching often lacks actionable guidance on how to become good at storytelling.
So I’m not going to sit here and preach. I think you’re all converted. Instead, I want to give you my way of being a great storyteller. And no surprise it boils down to having a structure for your stories to hang from.
Here are 4 structures that I use regularly to build influential stories as a Product Manager.
From Vision to Roadmap
I call this "Building a narrative top-down, bottom-up"
⬇️ Top-down:
Starting with your product vision you can create a story all the way down. It looks something like this:
To realise [VISION]
Our strategy is [XYZ]
We'll start by focusing on [OUTCOME X]
By solving [OPPORTUNITY Y]
Through building [X]
This can then be applied back up the chain.
⬆️ Bottom-up
We need to build [X]
To solve [OPPORTUNITY Y]
In order to move the dial on [OUTCOME X]
And achieve our strategy [XYZ]
To realise [VISION]
A simple, yet highly effective way to communicate the What, Why, and How. From How we're going to realise our strategy to why we need to build this capability.
Framing Opportunities
For communicating opportunities, I use the following formula:
Data + Problem + Diagnosis + Proposed Solution
For example:
Data: “5,000 users per month leave items in their shopping carts”
Problem: “Leading to X-pain”
Diagnosis: “I believe this is because of Y”
Proposed Solution: “I propose we do Z”
Putting it all together it can sound something like this:
“5,000 users per month leave items in their shopping carts… Leading to X-pain. I believe this is because of Y. I propose we do Z.”
Here you're telling a story from data to your interpretation, any assumptions you've made, and what your proposing the way forward be.
This structure can be highly influential as you're laying out a strong argument for a particular idea or solution. You've outlined the data, the problem you're solving, and why you believe this solution is best - that's a robust argument, it's hard to argue with that, and it's compelling! Why? Because it's a story!
Bonus: Carl Vellotti also shared his structure on X (Twitter) the other week.
Product Updates
Any time I give an update on the product or the progress of work, I always follow this PAST-PRESENT-FUTURE format.
This ensures I'm telling a holistic story about the product.
Past: What are the things we have shipped previously, and how are they performing? Are our experiments achieving what we hoped they would?
Present: How is our product health looking right now? What is the current sprint or work we should be doing today? What have we achieved this sprint and
Future: What’s next? What opportunities are next on the roadmap?
For example:
“(PAST) We are progressing well towards our OKR. We’ve seen a steady increase in uptake of the new feature Y. Customers have shared a lot of positive feedback about the new feature…. (Present) Right now we’re working to complete X… we’ve run into a few challenges such as…. (Future) once we’ve finished… we plan to move onto Z next…”
You can also see the same format come out in the way I structure my Sprint Reviews and Showcases below:
Finally, this format can also be used in day-to-day conversations with stakeholders.
Imagine a common dialog you might have with a key stakeholder - it could be a 1:1 or even just a quick ‘hallway-conversation’ - you can easily follow the same format.
Start with the past — explain how things are going, how the product is performing, how experiments are going, etc.
Next, the present — walk them through the key things that the team is currently focused on.
Finish with the future — what are you/the team plan to focus on next?
This style of storytelling is powerful because you're taking them through a journey. Starting with the context, perhaps a reminder of what we've done previously, then into the present, and finishing with the future.
Everyday Stories
The final scaffolding I want to give you for storytelling is for all those ad-hoc situations.
For example, say a major incident happened, or perhaps the team managed to achieve some kind of great success - how do you package that up into a story to tell others? - that’s what this format is for.
For this, I use the STAR framework. You might have heard about this technique before, I didn't invent it, although I was doing a similar version based on my experience with SMEAC.
STAR is a popular technique for job interviews. It's used to structure your experience or responses to questions into a compelling story.
However, STAR isn’t just for job interviews. It’s the perfect framework to use for those day-to-day stories and experiences.
STAR stands for:
Situation: Set the scene and give the necessary details of your example.
Task: Describe what your responsibility was in that situation.
Action: Explain exactly what steps you took to address it.
Result: Share what outcomes your actions achieved.
To give you an example of how I use this in practice:
Start by setting the scene, what was the situation/context? For example, say I wanted to brief a stakeholder on a recent incident, I might start with; “Last Thursday evening the day after Release X.X at approximately 4pm a customer attempted to…..”
Next is the Task and Action. I would then walk them through the specific event that lead to the response and the actions we took; e.g. “At first it appeared to be a routine error however as [team member A] started to investigate we realised….”
Finally I would close with the Result and anything that is still outstanding; “we rolled back to the previous version and are currently applying a hot fix….. which should be ready for a subsequent release by the end of this week”
Bonus: Build a Story Catalog
Have you ever heard someone tell a story and think, “Wow that was a great story”? What if I told you that you likely just heard a story that has been either rehearsed or, at the very least, been said before
This is the final tool I wish to add to your toolbox on being a great storyteller.
It’s worth identifying those golden stories - either in your past or about the product (perhaps it was a time when the product did something amazing or something unexpected happened) - and packaging them up into a story you can memorize to bring out at the right occasions.
I have built up many over the years:
A story about the first 0-1 product I brought to the market.
A story about my first company, why it failed, and how I’ve learned from it.
A story about an unintended outcome from a product feature we build.
A story on how I got into product.
etc…
These stories serve me well when situations come up where the story would be appropriate. I can use them to either influence, inspire, share lessons from, or answer questions in an effective way.
For example, I’ve recently created a new story about why I moved into Product Coaching and why I’ve created Product Pathways. This story is one that I can tell whenever I’m asked about what I do today, my career, or my purpose. The story has gone through a few iterations now, but having a story ready to go means that when I tell it I come across clear, concise and with maximum impact. All things that make for a great storyteller.
This is important because whilst the structure and contents of your story matter, your delivery arguably matters more.
As one of my speaking coaches once said to me; “Average content with amazing delivery will always beat amazing content with average delivery.”
So whilst the secret to great storytelling is having the scaffolding to create a story within, you still need to deliver on it.
If this is a space you struggle with. Here’s a short clip on some of the things that have helped me improve my delivery 👇
Hope that helps and makes storytelling more tangible for you.
It’s served me well over the years, and it’s helped dozens of Product Managers I’ve coached become better storytellers and in turn, be more influential in their organisations.
Thanks for reading and the support! ❤️
Need help with communication or other aspects of product management? I can help in 4 ways::
Level up your craft with self-paced deep dive courses on specific topics such as Prioritisation, Stakeholder Management and more.
1:1 Coaching/Mentoring: I work with product people and founders through 1 hour virtual sessions where I help them overcome challenges.
Private Workshops and Training: I frequently run private workshops and tailored training courses for product teams globally. Get in touch to talk about your unique training needs.
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…