How to tell compelling stories: lessons from four product managers
Abraham Lincoln. Homer. J.K. Rowling. Walt Disney. Bruce Springsteen. Steve Jobs. Elon Musk.
None of these people were present for the Women in Product event hosted by Coinbase last week. Okay, so some of them aren’t with us anymore. But we were channeling the best of all of them as we listened to four product managers share their insights on how PM’s can, and need to be, compelling story tellers — in and outside of their organizations.
There’s lots of information around the power of story telling, including some biological evidence about how and why our brains are wired to be lying in wait for good stories. I’m partial to that view because I have roots in biology and when there is some scientific evidence that can explain my otherwise inexplicable sad feelings, behavior after a bad encounter, or why gnocchi makes me happy, then I glob on to it. Suffice it to say, during some stories, oxytocin and cortisol are dripping like an IV inside your brain, maintaining your interest and engagement; whether that story is only 5 words long, or three hours. As product leaders, we need to learn how to turn on the IV.
It’s easy to think stories are only verbalized. But people have used the medium of design, cartoons, speeches, books, comedy, theme parks, and music to tell powerful stories. In some cases, they fascinated us (and helped us part ways with our money) about otherwise mundane but highly sophisticated products like cars, phones, rockets and overnight vacation accommodations (giving you reason to go on vacation if only to STAY at that place).
With that, let me dive in and share a few lessons from those speakers at the WIP event.
Navya Rehani Gupta, Dir of Product, StyleSeat
Navya shared three different versions of the StyleSeat story, as an example of her Don’ts and Do’s list:
- Let your story get stale. It should be evolving, because how your product gets used evolves. And how do you know how it gets used? Ah. Get out of the building and talk to your users.
At StyleSeat, all of their team members were responsible for reading stylist messages. So if you can’t physically leave the building, personal stories from users were coming in, listened to, and considered for the brand’s own story telling.
- Create boundaries and clarity about the one problem you are solving, and the thing(s) your product does not solve.
StyleSeat started first with helping stylists build their online presence; then moved to allowing consumers an easier option for signing up for haircuts with their favorite stylists. Now, they are focused on serving both sides of the marketplace.
- By setting clear boundaries in your story telling, everyone understands what problem you are solving at the moment, for whom and why. It encourages and promotes focus from every place in the organization.
- Don’t do it alone.
In her example about gathering qualitative data from users, Navya pointed out the value of hearing and using data from every person involved in the product’s development.
She recalled a member of her team came to her with a customer story about one of StyleSeat’s professionals who went from being a flight attendant, to stylist, to salon owner, to multiple salon owner. This changed how they thought about who they were serving, the special needs of their customers now who were using their platform to grow their businesses, and that customers may require more tools for managing successful businesses that grew beyond one chair in a salon.
Anna Marie Clifton, Product Manager, Yammer
“Catching a Ball of Ambiguity and passing it on to my team”
Anna Marie recalled a time when minutes before a product kickoff meeting was to happen, where she was going to bring engineers onto a new project, her head of product pulled the plug and said “you can only test half of this.”
I walked into the engineers/designers…. and I passed all the ambiguity of what just happened to me, on to my team. I then proceeded to lose all the faith of the peeps in the room. It was my third week on the job.
But in that meeting, with the team, she decided to test the variant anyway.
What did she do to dig herself out?
- First — relay that information to the head of product. As terrifying as that was, it turned out to be fine.
- On to the larger task: she had to do something to restore the momentum of the team, and their faith in her ability to be decisive.
- Put extra energy into each scenario that might play out in the test, building a possible story for every story that might unfold.
- Build out ready responses for each of those narratives. If we see ABC changes in the test results, we’ll do X, if we see DEF changes, we’ll do Y… etc, etc, etc.
- She shared it with her head of product and her team to restore their trust and allow them to focus on their work with confidence.
Weeks later, in the project retro, she was concerned that team members would only remember the frustrating and ambiguous beginnings to the project. But, in fact, the team verbalized that it all ended well and noted that although there was ambiguity in the beginning, they worked effectively together towards an end result, and it was due in large part, to her ability to shed light on the multiple stories and how the team would react in each case.
Anna Marie called attention to an important thing about memory:
The remembering-self is different than the experiencing-self: What we remember after an experience, is a highlight and a low light averaged together, with an emphasis on how it ended.
Shruti Keerti, Advisor to early stage edtech ventures. Ex PayPal.
Leveraging her experience with early stage product teams at PayPal and startups like Hapara and Mu Sigma, Shruti asked us two questions to anchor our thinking about telling compelling narratives:
- What is the value, the real benefit, to the user?
Shruti told us a story, (yep, a story about telling stories) about when she was working with Microsoft at one point, helping them sell more computers to people in India, with the goal of selling more to a lower income customer segment.
She asked Why?!, and discovered that MS wanted to be more relevant to that population.
In studying this more, she learned of Sugata Mitra who randomly placed computers in the walls of village homes, and then watched what kids were able to do with the computers — completely self-taught.
With no teaching at all:
In 6 hours, kids learned how to click, how to browse and how to use a mouse. In 6 months, they could download music, play games, hard learnt English words and basic computer literacy. Shruti realized quickly that self-teaching is a “thing”.
So taking that narrative, she asked the kids, “What do you like about this?” “What does it mean to you?”
Self-teaching is a “thing”.
The kids response?
“This is amazing. I can learn anything. I can do anything.”
2. Why should somebody care about the narrative that you tell them?
Shruti challenged us again with a question: How did schools turn out like this? Meaning, classes where teachers stand in front, students write notes, and then memorize and regurgitate material from time to time?
She walked us through time — when there was no computers, no internet and the British just needed people that could read, handwrite really clearly, (so that pieces of data/information could be sent back and forth), and they could do multiplication in their head (no calculators). A school was meant to create an assembly line that produces the exact same product at the end. This “graduate” could then go to any one of their colonial empires in the world and perform the same tasks.
In listening to this story, we all began to see the sheer magnitude of the problem at hand in education. And this was her point.
In crafting our scripts, and telling our product’s stories, we should find ways that help others feel part of something big, something meaningful and significant.
When we as individuals, and teams, and companies, are made to see we are part of “something” towards solving a monstrously large problem, that builds a much bigger narrative from which a product starts to build. You as an individual, and a company, are part of something much bigger towards solving this big problem … and your product becomes the hero.
Kristin Stone, Head of Business Partnerships, Coinbase
Kristin focused on three separate lessons she has learned in her experiences at Coinbase:
- Reiterate the story, every day if necessary.
- Communicate complexities in a simple way.
- Communicate it in a transparent way.
1. Frequent messaging
Internally everyone in the company heard the vision — whether it was on internal boards, emails, or in verbal communications between team members in meetings.
She encouraged everyone to stay data driven in those communications, categorizing users into buckets and bringing those different customer segments and their data to executive’s attention frequently. This allowed for more objective questioning about which customer segments they were serving with that specific narrative she was hearing. This focus on data, helps you evolve that narrative based on the user.
(*This lesson is echoed in Navya’s “Do’s and Don’ts” above — DO create boundaries and clarity of who you serve.)
2. First, admit that it’s complex.
Create a feedback loop with their customer team. Listen to what customers’ problems are and then, if you can and it’s part of your company business value proposition, let customers collaborate with each other. This practice allowed Coinbase to see where problems were, and then allowed them to change the product story based on their learnings.
Groups of uber-enthusiastic consumers talk a lot on Reddit. Coinbase saw that they were being talked about poorly and looked to understand why. When they dug in and understood who was the most vocal and about what, they asked themselves:
“Are THESE the people we are serving?”
They noticed that some of those who were most vocal cared about anonymity, and Coinbase didn’t promise it as part of their product’s story.
So the CEO took to Medium and wrote a post with absolutely clarity about who they were, and who they weren’t. The narrative repeated “We are not anonymous. We are an exchange.” And the post was shared each and every time the company received questions from customers; current, or future, internal or external.
And so there it is… some lessons from those who practice the art of story-telling daily.
What great product managers do, and should do, has been written about extensively across the interwebs. People like Ken Norton, Matt LeMay, Andrea Goulet, Josh Elman, Christina Wodke, Kim Scott and whole swaths of other talented folks have been generously sharing their wisdom for decades (yep, decades, plural). For a more detailed look on the other important skills required of PM’s, start with those folks and you’ll feel your IQ go up while you read.
My POV on this is, on any given day, we are scientists (hello, scientific method!), psychologists, sales professionals, strategists, marketers, technologists, and customer support pros. It’s not unusual for us to be involved in investor relations, as business model advisors, or prototype designers and UX researchers. Consequently, a product manager’s emotional and social intelligence skills need to be high in order to craft stories in ways that resonate with each of these audience members and whose attention and skill the product requires for success.
The narratives, and “user stories”, we tell our coworkers, wherever we tell them — in Pivotal, the local coffee shop, at the park , on a bike ride — all serve to engage people’s emotional brain centers such that they “see” what is invisible, deeply understand what is expected, and then get engaged to DO the thing required to help make the invisible, visible.
What do you think? Have something to add? Please share your comments below, and if you enjoyed this post, tap on the heart and recommend it!
My thanks and appreciation go out to each of the speakers who took the time to share their stories and lessons learned, and be the inspiration for this post. Thank you again to Coinbase for being such a gracious and hospital host to this large audience of story-tellers.