Story Mapping¶
Definition¶
A story map arranges a product's stories in two dimensions instead of one flat list. Read left to right along the top, the "backbone," you get a narrative flow — the sequence of things a user does, told as a story ("first they do this, and then this"). Read top to bottom beneath each backbone step, you get decomposition and priority — the details, alternatives, and edge cases nested under each big step, with the most important ones placed higher. Patton's core claim: "story maps are for breaking down big stories as you tell them," and building one surfaces gaps that a prioritized backlog hides.
In the Book¶
Chapter 1 grounds the technique in Patton's day with Gary Levitt, founder of Mad Mimi, who had been told by an Agile coach to write a flat, prioritized backlog and build items off the top one at a time — and had "hemorrhaged cash" for months with almost nothing shippable to show. Patton instead has Gary "talk and doc": narrate a day in the life of a band manager using the future product, writing each step on a card and laying cards left to right in the order they'd happen ("mile wide, inch deep" — get to the end of the story before chasing detail), then dropping supporting detail cards beneath each step. The resulting map — Signing up, Publicizing a show, Working with my audience, and so on across the top, with cards like "Upload an image" and "Attach an audio file" nested under "Customize the promo flyer" — let Gary see, for the first time, that almost none of the software he'd already paid for was actually on the map of what a launch needed. Chapter 2 extends the pattern to a multi-team map built by eight teams at Globo.com (Brazil's largest media company) to plan a shared content-management-system rebuild: because no single team's backlog made sense in isolation, they built one shared map with a backbone spanning all their systems, which immediately exposed dependencies and missing steps between teams — what Patton calls playing "What-About" ("what about when this goes wrong?", "what about these other users?").
Why It Matters¶
A ranked list can only ever answer "what's next"; it can't show you the shape of the whole thing, so gaps and missing steps stay invisible until they're expensive to fix. Laying work out along a narrative axis and a detail axis simultaneously makes holes visually obvious — a step with nothing beneath it, or a user type mentioned nowhere on the backbone — and lets people who disagree about priority still agree about sequence. The same move (separate "what order does this unfold in" from "how deep does each part go") applies to any domain where a flat backlog or checklist is hiding structure: curricula, onboarding flows, research programs, org rollouts.