User Story Mapping

01 Feb 2022

Book	User Story Mapping: Discover the Whole Story, Build the Right Product
Author	Jeff Patton, Peter Economy
Published	October 21, 2014

Importance of product ownership and decision-making. Don’t design by committee:

In my vision of good product development, the product owner is a critical leader. He keeps the product and whole team focused on moving the same direction. The alternative is design by committee—a seriously bad anti-pattern where everyone gets an equal say in what we do. In a committee, when we only have time and resources to do one thing, we compromise. My ex-wife and I would often do this when choosing a restaurant. She wanted seafood, and I wanted Mexican food, and we’d settle on something neither of us liked. When a committee isn’t constrained by time and resources, we do it all. You’ve used software products like this: the product with more features than anyone can count, and where your biggest problem is finding the feature or remembering how to use it. Effective product owners surround themselves with the people they need to make good decisions. They incorporate the expertise and opinions of many. But, in the end, when resources are constrained or the success of the product is at stake, they must make decisions. And there’s always someone who’ll be unhappy with that decision. My friend Leisa Reichelt puts it well: “Design by community is not design by committee…design is never democratic.”

Discovery is about learning, not about building software or a solution:

Discovery work isn’t about building shippable software. It’s about learning. It’s about building a deeper understanding of what we could build. It’s about asking and answering questions like: What problems are we really solving? What solutions could be valuable to our organization and to customers buying or adopting the product? What does a usable solution look like? What’s feasible to build given the time and tools that we have? It’s asking and starting to answer all these questions about an opportunity that starts your first round of rock breaking. All the details about the product or feature you discuss become the titles of smaller stories. And each of those smaller stories can result in even deeper discussions, and still smaller stories.

Four essential steps to discovery:

If I’ve got a big idea, or even a small one that needs some clarity, I follow this progression of discussions to move from the big idea to the details I’ll need to best understand if we’ve got a solution worth building:

• Frame the idea from a business perspective
• Understand customers and users and how you’re helping them
• Envision your solution
• Minimize and plan to identify the smallest viable solution and how you’ll build it.

Business goals > product features:

Prioritize specific business goals, customers, and users, and then their goals, before prioritizing features.

Essential steps of design thinking:

The first step of a design thinking approach is empathize. It’s not called research, which I’d normally expect from a design process. It’s called empathize because a critical outcome of doing the work is to understand how it really feels to be a user of your product. To do this you need to go to where users are, meet them, watch them work, and ideally work alongside them. Now, of course, if you build software for surgeons, no one expects you to become an amateur surgeon. But do your best to understand what it’s like to walk in their shoes. It’s important to remember that out of traditional research, especially the quantitative hands-off stuff, we get data and not always empathy. Talk directly to customers and users. Experience the challenges you’re helping them with firsthand.

The next step is called define. From the work we do during empathize, we learn a lot. But we need to make sense of it—to build shared understanding. And we’ll do this using lots of collaboration to tell stories, share, and distill what we’ve learned. Then we’ll choose specific people and problems on which to focus. Use story maps here to map the way people do things today. Include in them details of what you saw and learned. Focus on the pain points users have, and the rewards they seek. Use simple personas to build a good example user that synthesizes what you’ve learned. Choose specific problems to focus on. Really focus on one or a few problems. State them specifically.

The next step is ideation. If you were paying close attention in the last chapter, we talked about a simple practice called design studio. It’s an example of a good ideation approach. In common business practice where the first person to come up with a viable idea is the winner, it seems a waste of time to come up with lots of possible ideas. If you remember that your first obvious solutions are, well, obvious, then if really coming up with an innovative solution is important, think past that. I like using a story map as a backdrop for ideation. Use a map that shows pains, joys, and other information about users, and then brainstorm ideas directly into it. Write solution ideas directly on cards or stickies and inject them into the map where the solution is most relevant. Deliberately come up with multiple possible solutions to customer and user problems.

The next step is to prototype. Now, we likely all know what prototypes are, but we often neglect creating them in the rush to get working products built. It’s a pity, really. Small investments in simple paper prototypes help us think through our solution. They help us begin to experience it ourselves. Building simple prototypes out of paper, or the simplest of prototyping tools, helps us filter out a lot of ideas that just won’t work. Beginning to simulate the actual act of using a product helps you continue to ideate—to come up with ideas to make the solution even better. Build simple prototypes to explore your best solutions.