The power of storytelling
An important skill for every Product Manager
A common problem I have identified for Product Managers is the lack of proper communication on what value they want to create for the customer or the consumer. This ends up in two significant challenges:
The missing bridge - How to communicate an idea to decision makers to get buy-in without needing to build staff to prove their position.
The missing glue - How to keep a team engaged while building a product without delivering a broken experience or needing to define every detail early on.
The frustration on PMs’ faces was visible when I tried to explain that it was unclear to me where they were heading and why. The video below highlights how tough it is to communicate your ideas when there is not something tangible; it is tough to visualize it, or it is misinterpreted.
The quick answer I got was, “let’s build some wireframes,” but this is sometimes costly, tiring, and short-looking and some screens are not the whole customer experience. What I was advising them was to become storytellers, and they were pretty surprised when I asked about it.
A customer experience is a service and it is the superset of the product the team is building. Product leads, onboarding, back-office services and customer support is part of the experience and must be taken into consideration by every Product Manager.
When you build a product, you have to be in the position to communicate where the product is heading within the next 2-3 years without needing to build things that will cost you time and resources; no worries, everyone expects things will change, and learnings will alter the plan within this period.
Becoming a storyteller
Storytelling is the “superpower” for Product Managers to address many internal communication challenges. Building a good story raises questions about the user context and challenges the PMs to think with user flows and not static outputs, why users have decided to use their product, and how they get the value that will make them keep coming back.
The goal of a story is not only to describe the final state (i.e., a feature or a screen) but to describe all the intermediate steps to reach that point. A good story needs proper user context, a clear description of the struggle and the user's pain, and a spike, a wow moment that will impress the audience. A good story has to stick, and it has to escalate progressively. You can read a fantastic book about the power of storytelling here, it is worth it.
When creating a story, I don’t simply start writing a document; I need to include my team(s) to build a standard view and get our time to think. Thus, typically I start with building a user journey mapping or running a Design Sprint with the help of a product designer. From the multiple paths of a user journey, we highlight the most prominent scenario that clarifies the value the product creates, and this is the story we are building. With multiple iterations, and the lead of a product manager, the team can create and update their main story highlighting the value of the product they are building.
Communicating a story
What was more tricky than expected early in my career was to communicate a user story and scenario, even internally. I had noticed that stakeholders might be critical about not covering the scenario they perceive as most prominent, or they thought that the stories were oversimplistic or naive; when they were part of the process, it was easier to communicate it, but it is not always feasible to have every stakeholder in a design sprint.
What I found more helpful in communicating a story, even if it was written as a story arch with plain text, was the usage of two tools:
A Press Release (PR) document - or any relevant “working backward” document (e.g., customer letter) - allows communication of what the customer perceives and challenges you to share the whole product offering, including price and positioning.
A vision type for more strategic decisions allows the audience to start seeing what a PM has in her mind; it requires more time to be built, but it should be selected for strategic, long-term decisions that will cost even more if executed.
The final document could be a 6-pager, with additional details (e.g., tech details, market insights) and a list of the most common questions in a well-thought Q&A section. The PR document can be in the Annex, with a vision type, a live demo, or a link to a video. A 6-pager is something tangible that can be shared more efficiently, and feedback can be more thorough.
Having a good story is not enough.
The process of storytelling is iterative. A story creates a Press Release or a vision type, which initiates an action plan, and the team's findings may update the story. Thus, having a nice story doesn’t mean that you have taken approval.
What is needed is an action plan with a clear owner to start executing, and what is required to launch is the right time to ask. A PM has to work closely with the key stakeholders on that phase, and the story, of course, is a map but not the ultimate goal.
In the end, a product experience is something everyone should try; just ride the user journey as described in your story, and you can feel if it makes sense for you or if something feels weird and broken.