Product Story Telling

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:

This is what product managers do

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.

Lucas and Noah
How adorable is this

I love these kids and their story so much.

Dashrath Manjhi

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.

Starting the journey
in process
The end result

Both of these stories are compelling and will stick in your head. They are motivating and inspiring.

Story structure

Let’s break it down a bit. Every story has a structure. See below

Basic story structure

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

Personas that are know around the world
Pepper is less known, but works

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.

Rule fo thumb for personas

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.

Example problem statement

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
  • Timeline
  • 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.


Whatya think?