I think every product manager and eager-to-learn agile team member should read this book, or at least the first half, which efficiently explains the product design/analysis tool of a User Story Map. More importantly, he frames its utility not as a silver-bullet for anything, but as a great tool to catalyze the formation “shared understanding” amongst a development team. As part of this process of creating shared understanding, the whole team can help generate and constructively criticize a product plan. It’s this whole-team effort that results in the best ideas and kicks off projects that solve real problems and are delivered enjoyably and on-time. I definitely look forward to putting this product development artifact into use in every product I work on.
I found insightful the author’s distinction between ‘output’ and ‘outcomes’. Development teams produce measurable ‘output’ (of code, stories, bugs, whatever). But the actual goal of a product is to produce valuable ‘outcomes’ for the customer and/or user. A high-output team building a solution no one ends up using is probably better than a low-output team producing along a plan that really help customers achieve their goal. And any feature output that very few customers use costs a lot when you consider the total cost of ownership rationalizing and maintaining that output for the lifetime of your product. Thus Patton encourages teams to “minimize output, and maximize outcomes”
The second half of the book is a little more generally about agile development with incremental releases, and breaking down big epic stories into multiple little sprint-sized stories in a just-in-time fashion. In my opinion it could have been shorter, as some ideas were repeated several times without meaningful further development, but it wasn’t unreadable by any means.
In case you’ve never really worked with a User Story Map, the author of this book actually has a blog post describing the concept: “The New User Story Backlog is a Map”