Writing user stories is a good practice, but for articulating business outcomes, they are not enough. Let’s talk about how to share a compelling product narrative.
Once upon a time, I thought writing a good set of agile user stories with specific Given/When/Then acceptance criteria was the most important part of a product person’s job. I had recently made the switch from software engineering to product and was committed to spelling out requirements in a user-centric way that engineers could understand. Every time I was presented with a new initiative, I rushed to expand it into a set of standard agile stories using the template:
As a _______, I want ______ so that _______.
I’d write pages and pages of documentation before the initiative was ever fully vetted, before I knew if the work was even going to stay on my roadmap. Often, I didn’t even fully understand the problem, but I had 37 user stories ready to go breaking down the work into my current understanding of the basic who, what, and why we were building for.
As the problem space was better understood and the requirements changed, I’d spend hours updating stories — rewriting, merging, deleting, recreating. Managing my backlog was a full time job, which left no bandwidth for discovery, launch planning, or team support unless I worked overtime. I was miserable.
Then, one day, my Director of Product asked me to summarize the work of an initiative. I sent him the links to the 37 user stories required. He looked at me and said, “There’s no way in hell I’m going to read through all of these. Tell me what you’re doing, why it matters, and do it in five minutes or less.” I couldn’t do it, and as a result, the project got canceled.
All that work was wasted. It didn’t matter how strongly I believed in the initiative or how shovel-ready the stories were. What mattered was how the work was going to help our bottom line, and I didn’t know how to tell that story effectively. In light of that experience I started thinking about my process of getting work ready for my team.
I started thinking about why my user stories weren’t enough. They were written for the wrong audience. They lacked valuable context. They didn’t inspire anyone to rally around my cause. They simply broke the work of a big potential feature into smaller, tangible, testable pieces. Because of that, no one cared about the work I wanted to do. I couldn’t explain how this work would move the most important metrics because I couldn’t articulate how it fit into the big picture. Finally, I realized I was approaching product work from the bottom up, but management cared about it from the top down.
I started focusing on how to tell a better product story — not a user story, but a true narrative of my product. There are many effective ways to write a narrative, and I experimented with many of them until finally I stumbled upon The Story Spine, an improv exercise made popular by Brian McDonald and included in Pixar’s 22 Rules of Storytelling.
“The Story Spine Tool uses the familiar elements of a story to provide a structured way to facilitate a deeper reflection and dialogue about an idea, issue or opportunity. It was originally created by playwright Kenn Adams, as a tool for creating well-structured stories. However, it is also a playful and effective tool that can be used either to guide structured reflection on a completed project; or, as a creative method for envisioning possibilities for a new initiative. Either way, it offers a structured way to deepen and share their insights about an issue, challenge or opportunity.”
Source: Tamarack Institute
A story spine distills narrative structure into the following seven sentences:
Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___. And ever since that day…
While there may not seem like much overlap between fairy tales and product management, utilizing this seven sentence narrative structure helps remind us to:
- Define the context of our users and our business.
- Outline the problem to be solved.
- Describe the proposed solution.
- Demonstrate how our solution impacts our users and metrics.
- Illustrate the long term value our solution provides.
Ever since stumbling upon the Story Spine, I’ve used it to tell compelling stories that get the company excited about the work my development team has lined up. For example, while working as a product manager at a tech-enabled delivery platform, I told this story in an all company meeting:
Once upon a time there was ___. Every day, ___.
(Once upon a time…) When I first got married, my sister-in-law was always late for family meals. Every Thanksgiving, she’d show up an hour late and either keep us waiting or get there after we’d finished, which meant no one enjoyed the dish she brought. There’s many reasons she was late, but the most common was that she loves to experiment with new recipes. Because it’s hard to estimate how long a new recipe will take, she often underestimated the time needed. She also lived in a part of town that was known for construction that snarled traffic, so her lateness wasn’t always her fault.
One day ___. Because of that, ___.
One holiday, she missed dinner entirely and another family member had to leave before she got there. We’d had enough. Because of this, the family sat down to brainstorm how we could help my sister-in-law be on time so we could enjoy all of the Thanksgiving dishes together when they were still hot. We decided to tell her that dinner started 30–60 minutes earlier than we actually planned to eat. Now, she’s almost always on time, and ever since that day we actually enjoy meals as a family.
Because of that, ___. Until finally ___. And ever since that day…
The problems that my sister-in-law had in getting to dinner on time are very similar to the problems that our independent contractor drivers have making it to a delivery on time — it can be hard to estimate how long a delivery will take, and sometimes traffic gets in the way. Just as we told my sister-in-law to get to dinner early, we can set expectations with our drivers to get there earlier than our customers need them. That way, when drivers run into unexpected traffic or underestimate the time needed, they have a better chance of still meeting our customers needs.
I then explained the solution’s workflow and estimated how more on time deliveries would increase our NPS scores, prevent churn, and improve our business bottom line. The story worked. Everyone in the company was excited about this fundamental shift in how we communicated expectations to our drivers. They understood the happily ever after that was possible if we built the feature.
This was a huge initiative that could have easily been put on the back burner for smaller incoming requests, but because everyone believed the outcomes of the story were achievable, saying no to distracting feature requests was easy.
Using the Story Spine has also kept me from building the wrong things. When I struggle to write the ending of a feature narrative, that means I don’t understand the impact the proposed feature will have on our users or our business. If I can’t explain the desired outcomes in a story, the feature isn’t worth building until the problem and solution is better understood. This means more discovery, which changes the trajectory of the initiative.
Similarly, Story Spines identify which story arcs have been left incomplete. I like to identify all the actors in the narrative before I start the rest. This includes different categories of users, as well as marketing, customer support, sales, finance, and HR, if needed. I then think about how their working narratives change before and after the feature launches. This personifies the work of launch and makes sure that everyone is well-informed about how the feature impacts their day to day.
I hope this article illustrates the power of creating feature narratives and you’ll use the technique to paint an inspiring picture of what your product workflow and your business can be.