Review
I came to this expecting a book about a specific technique and got a broader argument about why written requirements fail, with the technique as the remedy.
Patton's contention is that documents are a poor medium for shared understanding. Two people read the same story and build different pictures, and nobody discovers the gap until the thing is built. Stories were meant to be a prompt for conversation and got turned into a format for specification, which loses the entire point.
The mapping technique itself is simple: lay the user's journey out horizontally in the order it happens, stack the details vertically underneath, then slice horizontally to decide what a release contains. What makes it work is that the map is a picture of a whole journey, so gaps and assumptions are visible in a way a backlog never makes them. I've run this with teams and the value showed up in the first twenty minutes, when two people who thought they agreed discovered they didn't.
The book is longer than the idea requires and the middle sags. Read the first third properly, then use it as a reference. The technique has outlasted most things I picked up that year.
Key Takeaways
The parts worth keeping:
The point of a story is the conversation
- Stories were designed as a reminder to talk, not as a specification format. Writing them more precisely does not fix the problem, because the gap is in shared understanding rather than in wording.
- Everyone reading the same sentence builds a different mental picture. The only reliable way to find the difference is to draw it.
- Shared documents create the feeling of agreement without the substance.
How the map is built
| Axis | What goes there |
|---|---|
| Across the top | The steps of the journey, in the order they happen |
| Down each column | The variations and details for that step, roughly by importance |
| Horizontal slices | Releases, each cutting across the whole journey |
- Slicing horizontally is the discipline. It forces every release to be a complete if thin journey rather than one finished step and six missing ones.
Output is not outcome
- Shipping everything on the map is not the goal. The goal is the change in what people can do, and most maps contain a lot that does not contribute to it.
- Minimising output while achieving the outcome is the actual optimisation, and it is the opposite of how backlogs are usually worked.
Build the map with the people who will build the thing
- A map produced by one person and presented to a team is a document again, with all the same failure modes.
- The argument that happens while making it is the deliverable. The artefact is a souvenir of it.