Read most books, articles, blog posts or listen to a podcast about product management and the focus will almost always be on process (Lean! Agile! Design thinking!), methods (OKR! JTBD! ICE!) or deliverables (Roadmaps! Requirements! Backlogs!). These elements of product management are valuable and knowing what they are, when to use them and when to avoid them is a key part of being a successful product manager. Yet, none of these elements have any value if they don’t reach a receptive audience in a compelling way.
Product managers have no authority
Martin Eriksson (along with many other product management leaders) made it clear that most product managers, unless they’re also founders, don’t have much authority. They’re not the CEO’s of the product much less anything else. In fact, the biggest challenge to becoming a successful product manager is to influence – your team, leadership, customers – without any authority at all. Even the best combination of process, methods and deliverables falls flat if no one is paying attention (did that tree make a sound in the woods after all?).
Storytelling is the product manager’s secret weapon
The key to successful product management? Storytelling. I would go as far as saying that product management is 80% storytelling with the other 20% going to execution. I would go even further and say that every deliverable a product manager creates is a storytelling opportunity.
Every problem statement, competitive analysis, market sizing exercise, OKR and even user stories, hypotheses and (yep) JIRA tickets are storytelling opportunities. They must be compelling. They need to take the reader on a journey in a way that is meaningful to them. It has to make them want to care about your idea.
Let me give you an example. Let’s say you’re in charge of the authentication flow for your product. You’ve noticed recently that login failures are spiking. You head into iteration planning with your team and hand them the following user story:
As a user of our product
I want to log in
So that I can use the system
Arguably your team will agree that this is an issue, discuss various ways to solve this and place it in the backlog based on a subjective scale of importance and priority.
Now, consider this alternative:
Authentication failures have increased by 73% in the last 6 months. This has reduced active users in the product by 52% on a daily basis which costs the company close to $1MM per day.
From customer interviews and analytics reports we know that 90% of authentication dropoff happens at the password field. If we can reduce this to 10% we get close to $800k of that daily revenue back.
We are considering solving this by removing the password field completely and texting/emailing users one time passwords each time they sign in. Our early low-fidelity prototyping of this idea returned nearly 100% success rates.
What’s the difference between these two stories? Which one do you believe more? Which one do you care about more? Which one do you want to work on? Which one do you want to fund? Why?
The secret lies in specific storytelling. The first version simply says “we need to fix this.” The second version paints a much more specific and compelling picture with only a few more words. “We have this problem. This is the impact it’s having on the business. If we fix it, here’s the benefit.”
Who reads your stories?
As with any creative exercise, it is critical to explicitly determine who your target audience is for each of your stories. This helps you determine what information to include, what to exclude and how detailed the story should be. For the product development team the story should include more specific and likely technical details. For an executive, the story should focus more on the impact your work will have on the area of the business they care about. Understanding what your audience is trying to get from your stories increases the influence you have with that audience. Don’t know what they want to hear? Here’s a tip: ask them for feedback on the last thing they read from you. Iterate, then ask them again.
What makes a story compelling?
One of my favorite descriptions of storytelling comes from this TED talk from Andrew Stanton. Stanton breaks down storytelling into its core components – situation, complication, solution – while telling one of the best jokes I’ve ever heard (warning: joke is rated R).
Your stories won’t always be compelling. You have to learn how to write and tell them. This is design and it gets better with iteration. In this short video from Pete Docter from Pixar he shares how even their stories don’t always resonate right out of the gate and that, often, injecting your own personal experiences makes the story much more relatable. (The whole Pixar In A Box video course is amazing.)
Just like you would discuss with your team what outcome you’d want to see if your product was successful, ask the same question about your story. What outcome would you expect if your story found its target audience in a compelling way? How will their behavior change? If you don’t see that change when they read your deliverables ask them how they might be improved and iterate your story next time around.
Your first test, do you believe it?
As you begin to rewrite your product management deliverables in a more compelling way the first test of efficacy is yourself. Do you believe what you just wrote? Does it inspire and motivate you to take action? Does it paint a clear picture of what you’re trying to achieve? If the answer is yes, ship it. If the answer is no, go back and edit. If you can’t convince yourself with your story you’ll never influence somebody else in the organization.
Comments are closed.