User Story Mapping: Discover the Whole Story, Build the Right Product

by Jeff Patton

“I understand that you’re different teams because you’re focusing on different areas, but it’s a major revision of one content management system. You’ll have to release together. You can’t plan a release until you can see it all together. You’ve got to visualize all these dependencies.”

Map for a product release across multiple teams to visualize dependencies.

When you read the backbone of the map from left to right, it tells a story about all the people who use the system and what they do in order to create and manage sites and content. The left-to-right order is what I call a narrative flow, which is an academic way of saying the order in which we’d tell the story.

When I talk with people who have built story maps, they’ll tell me, “Every time we do this we find holes. We find things that we thought another team should be taking care of, but it didn’t know. We find the necessary stuff in between the big important features that we’d forgot to talk about.” By mapping together, Globo.com found some of that.

Scope doesn’t creep; understanding grows.

Focus on what you hope will happen outside the system to make decisions about what’s inside the system.

Focus on outcomes—what users need to do and see when the system comes out—and slice out releases that will get you those outcomes. Slice Out a Release Roadmap The map contained innovative things that would improve all Globo.com’s web properties. But it really was going to take a long time to get all of it done. Hitting the market window that the

Focusing on specific target outcomes is the secret to prioritizing development work.

target outcomes are—the specific benefits you’re trying to get—then

Replacing the content management system is the output, the stuff they were going to deliver.

Doing that would result in lots of positive outcomes. The secret to breaking down that really big chunk of output was to focus on a smaller, specific outcome.

I may be easily impressed, but slicing is one of the coolest things about organizing software ideas into a story map.

But then we step back and think about the specific people who will use our product, and what they’ll need to accomplish to be successful. We distill that into a sentence or two. Then we carve away everything we don’t need, and we’re shocked at how small our viable solution really is. It’s magic.

Externalizing our thinking in a big visible map makes all these steps easier. It makes it possible for lots of people to collaborate to accomplish it.

The session helped facilitate a structured conversation to prioritize a large set of feature

ideas.

Differentiator

A feature that set them apart from their competition

Spoiler A feature that is moving in on someone else...

Cost reducer A feature that reduces the org...

Table stakes A feature necessary to compete in...

The story map with the prioritization model enabled conversations to happen that had not happened before. It helped guide the team to come to a shared understanding around priorities.

After labeling the stories, SEP used a voting system to help stakeholders converge the ideation

and discussion into the most meaningful set of outcome-focused features.

To everyone’s surprise, several stories were deemed postpone-worthy or unnecessary. Rough calculations revealed several hundred thousand dollars in sa...

Frank Robinson is credited with originally coining the term MVP, but these days definitions from Eric Ries and Steve Blank dominate. In spite of multiple smart people trying to define the term, everyone still seems confused—including me. Every organization I run into that uses that term means something slightly different. Even people in the same organization and the same conversation often mean different things.

The minimum viable product is the smallest product release that successfully achieves its desired outcomes.

Be specific about who your customers and users are, and what they need to accomplish. What’s minimum to them? I promise you, it’ll help the conversation hugely. It’s still a tough conversation.

The term I prefer these days is minimum viable solution. Most of the things I work with organizations on aren’t whole, new products. They’re new features or capabilities, or improvements on features already out there. So the term solution seems to make more sense. So let me revise my definition:

The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes. Here comes the hard part… We’re just guessing. When we slice out a bunch of software functionality and call it a minimum viable solution, we don’t really know if it is. The problem with outcomes is that you can’t really observe them until things come out. When you slice out a release, you’re forced to hypothesize what will happen. You might have to guess about what customers will buy your

product, what users will choose to use it, if they can use it, and what’s feasible to build in the time you have. You’re forced to guess at how much will make them happy. That’s a lot of guessing.

The New MVP Isn’t a Product at All! I know that some of you may have been feeling progressively twitchy over the last couple of chapters. You may have thought to yourself, Jeff’s overlooking the most important thing of all! And you might be right. Some of the most important things you can discuss during story and story map conversations are: What are our biggest, riskiest assumptions? Where is the uncertainty?

Eric learned the hard way, as most of us do, that we’re just guessing. Eric worked for a company that released a product that it thought was viable, but it was wrong. Intelligently, he changed his strategy to focus on learning—to focus on validating all those assumptions the company had made in its first MVP release.

Eric makes the important point that we need to create smaller experiments,

prototypes that test our hypothesis about what’s minimal and viable. And if you adopt Eric’s way of thinking, which you should, your first product should really be an experiment—and the one after that, and the one after tha...

A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.

While it was pretty cool that the folks at Globo.com were able to create a plan to build less, they weren’t fooling themselves. They knew there was lots left to learn to prove their assumptions were good. From here they and everyone else need to create a plan to learn more.

And that’s where we’ll pick up our story in the next chapter.

One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.

Your first story discussion is for framing the opportunity.

He first spent time talking to customers and users directly to really learn about them. Along the way he validated that there really were customers who had the problem, and they really were interested in buying a solution. Eric talked to the people who’d likely use the product. They didn’t have the product today, and had only poor workarounds to address the problems the new product idea would solve. Validate that the problems you’re solving really exist. While Eric’s been talking with customers and users, he’s been building up a pool of people he thinks are good

By now Eric and his team, after talking to customers, had specific ideas for the type of solution they could build that users could use, and by doing so get the benefit their employers wanted. Now, here’s where Eric and his team could have gone “all in”—where they could have bet it all. They could have built a backlog of stories that described their solution and set a team to work building it. Because they’re smart people, they’d have used a story map to move from the big idea to the specific parts to build. But, because they’re really smart, the last thing they’re going to do at this point is to build software.

It’s around here that Eric began to act as the owner for this product. He moved to envision his solution first as a bunch of simple narrative stories—user scenarios. Then he moved to envisioning the idea as a simple wireframe sketch. And then he created a higher-fidelity prototype. This wasn’t working software. It was a simple electronic prototype, created with a simple tool like Axure, or maybe even PowerPoint. All of these are learning steps for Eric. They help him envision his solution. Ultimately, he wants to put his solution in front of his users to see what they think. But he knows he first needs to feel confident it solves their problems before he puts it in front of them.

Sketch and prototype so you can envision your solution.

Eric was actually an interaction designer. He’s the kind of designer who’s used to spending time with customers and users, and

used to building these simple prototypes. But, for this new product, he’s also the product owner—the one ultimately responsible for the product’s success. There are other product owners in Eric’s company who don’t have his design skills, and they very sensibly pair with designers to help with both interviewing users and envisioning solutions.

Prototype and test with users to learn whether your solution is valuable and usable.

After iterating his solution many times and showing it to his customers, Eric was confident he had a pretty good solution idea. Surely now he could get that backlog built, and get his team of developers to work turning that prototyped

solution into real working software. But Eric’s not going to do that. Well, not exactly that. That’s a bigger bet than he’s willing to take.

When we describe the tasks people using our software do in order to reach their goals, we’ll call them user tasks.