User Story Mapping (by Jeff Patton) — Bullet Summary
Hello! I’m @Ivan Landabaso, Partner at JME Ventures. Welcome to Startup Riders, where we share emerging tech waves you should surf. Get these stories in your inbox for free — 👉 SUBSCRIBE HERE
Note: This bullet-point summary is part of a startup & product book series, take a look at the full list here.
What is Story Mapping and what are User Stories?
Put simply — user mapping is a technique used to tell “user stories” through words and pictures, with the goal of building a common understanding. The idea is NOT to gather a set of written requirements, but rather help teams build consensus, a common understanding of user problems, to ultimately help build a better product.
When you think about story mapping / user stories, you probably think of a group of people writing on post-it notes covering the walls and/or floor of a meeting room. Just remember, the goal is not to build a roadmap — rather it changes people’s mindsets from “gathering requirements” to “shared understanding”.
What does a Story Map look like?
Building a Story Map
A story map is a representation of all user stories created. A team typically maps user stories on wall using Post-it notes, stickies, and pens.
At the top of the page we find activities. Under each activity, we find user tasks and stories. The map flows from left to right following the user journey.
The narrative flow (activities) is the backbone of the map. It allows team members to tell stories about users. The basic formula for building user stories = As a…, I want to…, so that…
The author suggests running a story-mapping exercise in 6 steps:
- Frame the problem — who is it for and why are we building it
- Map the big picture — focus on the breadth, not the depth.
- Explore — go deep and talk about other types of users and people, how else they might do things and the kind of things that can go wrong
- Slice out a release strategy — focus on what you are trying to achieve for your business and on the people your product will serve
- Slice out a learning strategy — use the map and discussions to find your bigger risks, slice your map into minimum viable product experiments
- Slice out a developmental strategy — focus on building things early that help you learn to spot technical issues and development risks sooner
A few additional tips from the author:
- Make sure to invite people from different disciplines
- Focus on the breadth of the story before diving into the depth
- Plan to build less, plan to learn faster, and plan to finish on time
Getting to a Minimum Viable Product (MVP)
Prioritize the MVP— The book defines an MVP as a product that works, but without any additions / distractions that would not serve a fundamental and/or basic user need. You should derive the MVP from the story map by drawing a horizontal line below the backbone, or narrative.
Tips on prioritizing for the MVP — the author suggests using 4 variables:
- differentiator — what sets the organization apart from the competition
- spoiler — a feature moving into a competitor’s differentiated space
- cost reducer — a feature that results in cost savings for the organization
- table stakes — a feature that is absolutely necessary to compete
