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

by Jeff Patton

Mapping Helps You Spot Holes in Your Story

One of the criticisms people sometimes make about story mapping is that every time they sit down and create story maps, they end up with way too much. But it’s my belief that we’re just finding the stuff now that would have bitten us later on, and that’s a good thing.

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.

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

Don’t Prioritize Features—Prioritize Outcomes

behind outcomes are specific behavior changes for specific people engaged in specific activities.

It all seems important. 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.

Differentiator A feature that set them apart from their competition

Spoiler A feature that is moving in on someone else’s differentiator

Cost reducer A feature that reduces the org...

Table stakes A feature necessary to compete in...

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

“HiPPO” method—the “highest paid person’s opinion.”

The term I prefer these days is minimum viable solution.

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

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.

your first product should really be an experiment—and the one after that, and the one after that, until you really prove that you’ve got the right product.

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

Start by Discussing Your Opportunity

What is the big idea?

Who are the customers? Who are the companies we think would buy the product?

Who are the users? Who are the types of people inside those companies we think would use the product, and w...

Why would they want it? What problems would it solve for customers and users that they couldn’t solve today? What benefit woul...

Why are we building it? If we build this product and it’s successful, ...

Your first story discussion is for framing the opportunity.

Validate that the problems you’re solving really exist.

customer development partners.

Sketch and prototype so you can envision your solution.

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

people who said they’d like it and use it are just guessing, too.

build something less than minimal—just enough that potential users could do something useful with it. This is a product that wouldn’t impress too many people, and they might even hate it. It’s definitely not a product you’d want your marketing and sales people out there pitching.

They’re his development partners. They’re the ones who gave feedback on early prototypes.

The complaining is good, too, because it gives Eric ideas about where his next improvements should be.

Iterate Until Viable

This is a simple visualization made by my friend Henrik Kniberg.

Treat every release as an experiment and be mindful of what you want to learn.

build-measure-learn loop

I like referring to Ries’s MVP as a minimum viable product experiment—or

I like using the term product discovery to describe what we’re really doing at this stage. Our goal isn’t to get something built; rather, it is to learn if we’re building the right thing.

my definition of discovery includes Lean Startup practice, Lean User Experience practice, Design Thinking practice, and loads of other ideas.

If we recognize that our goal is to learn, then we can minimize what we build and focus on building only what we need to learn.

If you don’t get beer, or an equivalent reward, for solving tough problems where you work, you should have a talk with someone about that.

Map only what you need to support your conversation.

The best estimates come from developers who really understand what they’re estimating.

they’re likely to learn some things they couldn’t predict. They may have overlooked some characteristics this feature should have—finer points that weren’t explored in the prototype. They may have found that the system just doesn’t perform the way they expected and some extra work will need to be done to get the speed they want out of it. These are the “predictably unpredictables”—a

Donald Rumsfeld’s “unknown unknowns.”

estimates are…estimated.

we knew exactly how long things would take, then we wouldn’t have called it an estimate, would we?