Product.

User Story Mapping

5 min read·Apply by lunch

The question

Your team has committed to a release next: could one real customer start at the very beginning and get all the way through to the thing they actually came for using only what's above the line — or does it stop somewhere in the middle, polished at step one and missing entirely at step four? A backlog sorted by priority almost always slices the wrong way.

The idea

Jeff Patton spent years coaching teams who'd turned a product into a flat, prioritised list and then wondered why the first release felt broken. In 2008 he published a piece called The New User Story Backlog is a Map, expanded in 2014 into User Story Mapping for O'Reilly, and his fix is almost embarrassingly physical: stop sorting the backlog and lay it out. Across the top go the things a person does, left to right in the order they do them — the backbone of the story. Under each one hang the details, the variations and the alternatives, roughly best at the top. The list now has two dimensions instead of one, and a release stops being the first thirty cards. It becomes a horizontal line drawn across the whole map: everything above it ships, and it ships as something a person can get through end to end. Alistair Cockburn calls that thinnest working path a walking skeleton — ugly and unfinished, but alive along its whole length. Don't confuse it with the MVP you were taught earlier: an MVP is the smallest thing that tests a hypothesis, so it's a learning device; a walking skeleton is the smallest thing a real customer can get all the way through, so it's a release. A one-dimensional backlog can't show you either line, which is why sorting by priority so reliably builds the opening beautifully and strands the customer at step four.

The framework

01
Build the backbone before you touch a single card.
The top row is what a person does, in the order they do it — finds you, decides you're worth a try, gets set up, does the thing they came for, gets the result, comes back. Most products need somewhere between six and a dozen of these. Write them as activities rather than as features, and build the row with the whole team standing at a wall, because the argument about sequence is the valuable part and it only happens out loud. If two people order the steps differently, you've just found a disagreement that would otherwise have surfaced halfway through the build.
02
The body of the map — the variations, the exceptions, and what happens when it fails.
Under each step of the backbone goes everything that could be built for it, ranked top to bottom: the plainest version that works, then the better one, then the one you'd love to have. Include the unhappy paths, because thin releases usually die there — the customer who abandons halfway, the payment that fails, the file that won't upload. Then take the backlog you already have and pin every item to a step. What you notice is the whole point of the exercise: a pile of items sitting under steps nobody had named, and steps with nothing under them at all.
03
A release is a horizontal cut, and it will look crude.
Draw the line across the whole map so that every step of the backbone has at least one item above it, and accept how rough those items will look: a manual step, a hard-coded option, one supported case out of five. That's the walking skeleton, and it's worth more than three finished steps and a cliff, because it puts a complete working path in front of a real person and tells you which part of it they struggle with. Sorting down a list can never produce that shape. Only the two-dimensional picture can.
04
The map earns its keep as an argument, not as an artefact.
Patton's insistence is that the value comes from building the map together, because a document handed to people who didn't make it transfers almost none of what the room worked out. So build it with engineering, design and whoever answers the support email, keep it somewhere visible, and update it the day a release ships rather than at the next planning offsite. The practical dividend arrives when someone joins: the map orients them in ten minutes to a picture that a prioritised backlog couldn't give them in a week.

Members only · 4 principles + template + AI mentor

364 more frameworks are waiting.

User Story Mapping is Day 1 of 365. One framework every morning for a year — across strategy, sales, negotiation, leadership, and more.

$1 /day

Billed $365/yr · cancel any time

365 frameworks

12 topics · templates · AI mentor

Reserve your place — $365/yr →

One payment a year · the whole library · no auto-renewal.

More Product frameworks

All 22 product frameworks →