I’m not really a book review kind of guy. I love reading, but I’m generally just not a reviewer, so stick with me. Note: the link to the book here is an affiliate link, but I am in no way affiliated with the author or publisher of the book.
Let’s be honest for a moment- there are lots of good books out there that talk about the stages of the product lifecycle and the theory of product management. There just aren’t that many that are really practical. Finally, in Jeff Patton’s User Story Mapping we have a real, practical book for product managers.
Patton does a fantastic job of walking the reader through each stage of the front end of product management and how user story mapping can help define a project/product for all interested parties. (If you’re a new product manager this is the stage of the process where you’re determining who you’re building for and exactly what you’re building.) The stages are clearly defined with lots of hints and tips, but most importantly they are practical and grounded in the reality of building products in software organizations.
This is the stage where you are defining for whom you are building a product. One thing that separates good product managers from great product managers is the level of specificity they can give about who their users are. I’m not talking about the general persona level (“We sell to developers" or “We sell to marketers"), but really getting down in to the nitty gritty. For example, the user is a marketer (We’ll call him Larry) who lives and dies by his digital ad spend and the leads created from that spend. They only get paid if those leads convert. They have infrequent sleep schedules and so they need to be able to access and self-serve on products at all hours without direct support. And so on. Patton does a really nice job of walking through some of the elements of building these personas and incorporating them into the product building process. He also points to a bunch of great resources for building on this. Books and books have been written on customer development, but Patton brings it down to a readable, concise version.
Discovery Side Note
If you want to be an authority in the room as a product manager then work on discovery. This is hard stuff. It requires patience, calling customers, digging through passive data (Start with your product and web analytics. If you don’t have access to user activity in your underlying databases make good friends with your DBA and DBE’s- sometimes they’re cranky but they can almost always be plied with beer and your desire for learning.) The more you understand and can talk about your user the better you will be in front of your executive team, your developers, your sales people and so on.
Story mapping is the heart of this book. I’m not going to spoil it too much for you because you should just go read this book to get all the details on it. That said, this is one of the most important concepts I’ve seen in product management to date. To put this into perspective, immediately after I finished this book I moved a lot of the pieces of the book into a PowerPoint for my boss, gave story mapping a shot with one of the teams I work with (it was a huge hit) and then sent the deck with pictures from the process to my boss and said, “We’re going to do this from now on."
The essence of creating a story map is creating a backbone that explains the major steps of the user journey- these are the big things that the user does in the system. These end up becoming your parent stories. Beneath each of these you put the details on index cards or post-its and these become the children stories. Creating the map is a way for everyone to see how each element of the build fits into the larger project. It just helps you make sure you write all the stories the first time.
Funny enough, though, writing the stories is not the focus of this book, and I’m glad it’s not. The focus here is on the process to build the map. The process isn’t so revolutionary, but the outcome of the process is. Here’s why: It forces the stakeholders into a room to have conversations about the whole of the product/project. These conversations make for the best builds as they create shared understanding of the project/product. Suddenly the writing for the user stories becomes less important as they’re no longer a contract between product and development, but reminders of the conversation and understanding. The acceptance criteria become not just a “throw it over the wall to make sure it works" thing, but a shared drive at working software.
It’s rare a book this good comes along for product managers. I strongly suggest that it’s on your shelf. As an aside, I’d suggest you get it in the paperback version over the electronic version because you’re going to want to write in it. Nearly every page of mine has notes about my organization in it, things I want to try, lessons I want to take away. Also the pictures are really helpful. Go read this book.