A Product Manager whom I mentor occasionally asked about getting a team in alignment about a product feature. I told him about story telling. Without further ado, here is how you tell a great PRD story:
Examples of great stories
Before we get started let’s look at two great stories.
Lucas and Noah
Meet brothers: Lucas and Noah. Lucas has Lissencephaly* (Pronounced Listen-Sif-a-Lee) Noah heard about a local triathlon and wanted to compete, but he wouldn’t take part unless Lucas could take part alongside him.
I love these kids and their story so much.
Dashrath Manjhi wife died because she couldn’t get to the hospital in time. So he cut through a mountain single-handedly for 22 years, day and night. He reduced the distance from 70 km to 1 km from his village to the hospital.
Both of these stories are compelling and will stick in your head. They are motivating and inspiring.
Let’s break it down a bit. Every story has a structure. See below
Orientation / Personas
In both stories, I started with the people. Who are they? For your PRD, you should make personas. I suggest using short “Sticky Personas“. Here are two examples
These personas are not over complicated. They are meant to give basic motivation and names to the players in the story. If they are too specific, they become hard to remember.
Lucas, Noah, Dashrath, and his wife all were good, easy to remember personas
Rising Action / Problem Statement
Don’t make this too complicated. The stories above were straight forward and simple. Boil down your problem to the raw essentials.
Both stories above clearly show the problem in just a few sentences. Here is an example of a problem Tony might having.
Climax / Situation
The situation is more context about the problem.
- What will happen if you don’t solve this?
- How much is it worth to the company?
- Answer all of the WHY questions here.
This can be more verbose, but again, try to keep it simple.
Falling Action / Plan
Don’t over do it . You don’t want to diminish the design and engineering teams creativity and contributions. They are supposed to come up with the solution. However, you can describe the general approach and who is going to work on the it.
- General approach
- Teams and responsible team members
- Rituals to plan for
- External people to include
Resolution / Goals
How will we know if it worked? You should describe metrics that can be used to tell if the work was successful.
- Usage stats
- Sales stats
- NPS scores
- Anything measurable
Its a good habit to make guesses on what the outcome will be so you can learn from the experience.
Telling a good story in your PRDs will help align the team and make everyone inspired to work. Stories aren’t magical, they have a structure which can be followed in your PRD. I ran through this quick, but the truth is that PRDs do not need to be overly verbose. You can have details available to people in separate documents. Start with the story and get alignment. It will reap more rewards in the long term.