PMs who are good storytellers – how do you build this skill?

I keep reading how important is it for a PM to be a good “storyteller” but I’m very confused as to what it really means.

  1. PMs who excel at this – can you share real-life examples of the stories you used to present an idea/situation?
  2. How does one build this skill?

Practice, practice, practice is what it takes to build this skill. It’s a necessary one to succeed over the long term in product management.

If you can pull from direct quotes and customer research that you have first-hand knowledge of, from real customers, on pain-points that they have, which has been gathered within the past 12 months, you have the start of a story to tell.

The structure I would suggest is something akin to this:

  • We’re here to talk about X
  • Customers tell us that they have a problem with Y
  • Through discovery, we’ve investigated A, B, C, etc.
  • After discussions with the team, we hypothesize that X could solve Y
  • The outcome of doing X is Z
  • Here’s what we need to do X in {timeframe}
  • We’re looking for your support to start on X, any feedback?
  • By building X we solve problem Y which leads to Z

This isn’t a complete story template, but hopefully it’s enough of a primer to get you started.


Agree with this. This is something I help clients with a lot, and it really comes down to structure. Many PMs don’t consistently apply any kind of structure to their thinking. When they express themselves, their thoughts are all over the place. How they arrived at a decision isn’t clear.

Adding to your suggestions, a helpful exercise for any situation is Cole Nussbaumer Knaflic’s “big idea” framework. Asking:

  • Who do you need to convince?
  • What do they care about?
  • What do you need to convince them to do?
  • What will happen if they do/don’t do that thing?
  • Based on the above, what’s the one-sentence big idea/story you’re telling?

There are more specific frameworks for product strategy, etc., that I use with clients.

In terms of building the skill, and at the risk of being glib: practice is exactly right. Lots of putting something out there and seeing the kind of response it gets, then tweaking from there.


This is a really great pointer. Often we think that everyone cares about the same thing. Targeting each individual with what they care about is essential. It shows that the presenter thought this through.


The longer I work the more I am convinced this is not true as you pointed out. Everyone has their own agenda, incentives and sometimes juggling with the ones that are not in-line with others can get tricky, particularly if the product has 25 other team dependencies.


+1 to the framework. I would add after bullet point 2

  1. Problem Y impacts our top line org goal of Z.

  2. Solving Y will improve Z by ___ (assuming you can size the impact).


Terrible storyteller. I’m firmly in the “hurry-the-heck-up-we’ve-only-got-30mins-to-cover-2hours-worth-of-shiit” camp and somehow it works for my career. I present the context and explain the why. The time I spent in the construction industry has taught me to speak ELI5 in most situations. I sometimes forget to turn that off when I talk to engineers even though I have a tech background.


Love this response. I’m in the opposite camp. I usually drag things and end up taking so much longer. I hate it because no matter what I do, from preparing before hand. Creating outline, creating mini timers, I think it’s the ADHD. I admire people in your camp though and wish I can become more concise like that.


I was at a few orgs where my bosses and many of the higher ups either came from a consulting background or had the engineering mindset, by nature of the industry we were in, of no fluff just get to the point when it came to internal presentations. Tell me what you want to do and why; show your evidence.

I then moved to a different org where it seemed like my boss and other PMs would spend all day working on a deck then the next few days over analyzing it and making sure the “story” was just right. It was hell - they cared more about the looks than the substance; it was all word salad and fluff, but they always had a story.

It was jarring but I did learn that to some audiences all they care about is the “feels” they get from a presentation or deck - and I will never work somewhere like that again lol.

  1. It may make more sense if you substitute “storytelling” for “persuasion”. In most cases, the goal of your story is to persuade others to align with your approach
  2. I’d look at other people in your company who are very good at persuading others. See how they structure their presentations, talking points, approach to stakeholders, etc. There are also books on this topic, but no good ones off the top of my head.

There are courses out there on story telling, generally they focus on

  • get shareholders to be interested/care about you
  • demonstrate you understand the problem
  • understand what is important to your stakeholders and be clear on how what you are doing will help them
  • show clarity in how the value will be delivered
  • deliver (this will help with the first point next time)

This is the way.

I want to build on this a bit. I see a lot of people who struggle to actually listen to their stakeholders and ask the right probing questions to go deeper into their problems and motivations. Without this foundation, any story you tell will be superficial and vague at best.


A product is nothing more than an embodied story. If you don’t have a story you don’t have a product. If you can’t tell the story, you can’t fund the product, design the product, test the product, market the product or sell the product.

The product story takes many forms but a lot of the best ones go: group of humans want to do a thing, but that thing is hard/scary/expensive/risky because of this problem. Our product will/does make doing the thing easy/cheap/low-risk therefore group of humans can get what they want (and will give us money to get what they want).

When I tell the story I like to use the real details of the customers I observed having the problem in the course of my qualitative research (you are doing qualitative research as a PM right?) I talk about the pain point I saw, what it looked, smelled, tasted and felt like, what the weather was, what the consequences were for the humans involved. My goal is to make my audience feel the pain that the customers feel. If there is no pain, there is no product - go build something else. If you can’t tell the story, there is no way your sales and marketing teams will and the product will fail.

I practice my stories a lot - with my boss, with my stakeholders, with my sales and marketing teams, with my friends and family and I ask for blunt, brutal specific feedback: “what did you hear me say?”, “how could I have said that better?”, “what rang false or hollow “, “Did I use any jargon you don’t think customers will get” and most important “what do you think the customers feel about the pain point”

This takes a stupid amount of work to get right. I recently gave a 10 min talk at a customer confrence. By the time walked in stage I had over 100 hours of writing, editing, practice and prep into that talk - but the customers reaction to that talk sold my sales and marketing teams on the product and gave them the stories and language they needed to go sell.

To get better at story telling focus on the people and their pain - that’s the plot. If you need examples of how words create emotion you can study master short story tellers: Hemingway, Chekov, Conrad, Dhal … Study cognitive bias, behavioral economics, but most importantly practice. If you can pitch your idea, tell your story to just one customer a week and reflect and iterate
after each, you’ll be much better very soon.


Know your listeners. Everyone learns differently: some visually, some verbally, some need both.

Story telling depends on your audience and your objective. 1:1’s prior to a presentation or storytelling conversation can give you insight on how people prefer to receive data, ideas, results, discovery, etc. This will also help you prepare for inbound questions.

What is the outcome you want? Approval? Resources? Work backwards from there. Break out the simple problem up front, and if there are multiple problems finish with one section before introducing any less related problems as they will distract. Speaking of distractions, practice with trusted coworkers on pivoting from random questions back to your goal/topic.

Provide simple statements up front, have additional slides if people need to dive in more. You can skip, or move quickly over those if you get your goal up front. There’s a good article on this style I’ll link to later.

Write out a script, practice, and eventually work on ad lib. You got this!

1 Like

Thank you so much to all of you for such detailed explanations and insights. :pray:
Really was very helpful and informative…

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.