User Story Mapping by Jeff Patton

The Telephone Game > Location 317 Shared understanding is when we both understand what the other person is imagining and why.

Building Shared Understanding Is Disruptively Simple > Location 328 The idea is that if I have an idea in my head and I describe it in writing, when you read that document, you might quite possibly imagine something different.

Building Shared Understanding Is Disruptively Simple > Location 330 However, if we get together and talk, you can tell me what you think and I can ask questions. The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using index cards or sticky notes.

Document to Help Remember > Location 364 story- driven process needs lots of documents to work. But those documents don’t always look at all like traditional requirements documents. It takes talking and sketching and writing and working with sticky notes or index cards. It’s pointing to documents we brought into the conversation and marking them up with Highlighter and scribbled notes. It’s interactive and high energy. If you’re sitting at a conference table while a single person types what you say into a story management system, you’re probably doing it wrong.

Document to Help Remember > Location 371 what’s most important isn’t what’s written down—it’s what we remember when we read it. That’s the vacation photo factor.

Document to Help Remember > Location 372 Talk, sketch, write, use sticky notes and cards, and then photograph your results. Even better, shoot a short video of you talking through what’s on the board. You’ll remember lots of details in a remarkable depth that you could never possibly document.

Build Less > Location 438 There’s always more to build than we have time or resources to build— always.

Build Less > Location 441 you will realize that your job is not to build more— it’s to build less. Minimize output, and maximize outcome and impact.

That’s All There Is to It > Location 473 Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.

That’s All There Is to It > Location 474 Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.

That’s All There Is to It > Location 475 Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.

That’s All There Is to It > Location 479 I hope you work together with others, telling stories about your users and customers and how you can help them. I hope you draw pictures, and build big sticky- note models. I hope you feel engaged and creative. I hope you feel like you’re making a difference. Because when you do it right, you are. And it’s a lot more fun, too. 1. The Big Picture

Telling Stories, Not Writing Stories > Location 522 Stories get their name from how they should be used, not what should be written.

Telling the Whole Story > Location 543 Story mapping is a pattern. It’s what sensible people do to make sense of a whole product or whole feature. It’s what they do to break down large stories into smaller ones. Don’t feel bad if you didn’t arrive at it on your own. You would have eventually. But reading this book will save you weeks or months of frustration. Story maps are for breaking down big stories as you tell them.

Talk and Doc > Location 582 Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.

Talk and Doc > Location 587 Think— Write— Explain— Place When working with a team to build a story map, or having discussions about anything, create a simple visualization to support your discussion. One of the things that goes wrong is lots of ideas vaporize— that is, we say them, and people nod as if they’ve heard. The ideas are not written down or referred to. Then, later in the conversation, the ideas come up again and unfortunately need to be re- explained because people didn’t really hear or forgot them. Bookmark - Talk and Doc > Location 590

Talk and Doc > Location 591 Get in the habit of writing down a little about your idea before explaining it. If you’re using cards or sticky notes, write down a few words about your idea immediately after thinking it. Explain your idea to others as you point to the sticky note or card. Use big gestures. Draw more pictures. Tell stories. Place the card or sticky into a shared workspace where everyone can see, point to, add to, and move it around. Hopefully, there will be lots of other ideas from you and others in this growing pile.

Frame Your Idea > Location 604 Frame Your Idea Our first conversation focused on framing his product idea. We talked about his business and what his goals were. Why are you building this? Tell me about the benefits for you and for the people who will use this. What problems does it solve for those people and for you?

Describe Your Customers and Users > Location 612 Describe Your Customers and Users Gary and I continued to talk and doc. The next conversation Gary and I had was about the customers who would buy, and users who would use, his piece of software. We listed the different types of users. We talked about what benefits they would get, and asked why they would use the product and what we thought they would do with it. What was in it for them?

Describe Your Customers and Users > Location 620 The goal is to minimize the amount we build. So the first question I asked Gary was, “Of all these different users and the things they want to do, if we were to focus on thrilling just one of those users, who would it be?”

Tell Your Users’ Stories > Location 627 Tell Your Users’ Stories I next said, “OK, let’s imagine the future. Let’s assume for a minute this product is live and let’s talk about a day in the life of someone who uses it and start telling the story. First, they would do this, and then this, and so on and so on.” And we told the story in a flow from left to right. Sometimes we backtracked and put things to the left of other things, and because they were on cards, we could easily rearrange them.

Tell Your Users’ Stories > Location 641 You’ll find that no matter how clear you are about your story, talking through it while you map will help you discover the holes in your own thinking.

Tell Your Users’ Stories > Location 643 Mapping your story helps you find holes in your thinking.

Tell Your Users’ Stories > Location 650 One card above another can indicate priority. But it can also mean decomposition, which is just a fancy word for smaller details that are part of a bigger thing. As Gary described the details, I’d record them on a card, and place them below the big user step above. For instance, when Gary described creating the flyer that band managers would use to promote their gigs, he was extra passionate and had lots of details to discuss.

Tell Your Users’ Stories > Location 657 It’s easy to get lost in the details, especially the ones you’re passionate about. But, when we’re trying to get the big picture, it’s important to get to the end of the story before catching all those details. Another mantra I use when mapping, at least at this stage, is “think mile wide, inch deep”—

Tell Your Users’ Stories > Location 661 Focus on the breadth of the story before diving into the depth.

Tell Your Users’ Stories > Location 674 Notice how what we wrote on every card are short verb phrases that say what the specific type of user wants to do. Bookmark - Tell Your Users’ Stories > Location 675

Explore Details and Options > Location 700 Story mapping is all about having a good old- fashioned conversation and then organizing it in the form of a map. 2. Plan to Build Less

Explore Details and Options > Location 760 There’s always more to build than you have people, time, or money for. Always.

Explore Details and Options > Location 764 But one of the coolest things about using a story map is that it gives you and other collaborators a space to think through alternatives and to find a way to get a great outcome in the time that you have.

Mapping Helps Big Groups Build Shared Understanding > Location 801 The Backbone Organizes the Map At the top of the map is the backbone, which sometimes has a couple of different levels. You might start with the basic flow of the story, which is one level. But, when it gets really long, it’s useful to go up one more level to summarize things further.

Mapping Helps Big Groups Build Shared Understanding > Location 826 Mapping

There’s Always Too Much > Location 858 Focus on what you hope will happen outside the system to make decisions about what’s inside the system.

This Is Magic—Really, It Is > Location 901 Many times I, and the teams I’ve worked with, have placed all our ideas about the perfect product into a map and been overwhelmed by the amount of work we’d have if we created it all. 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.

Why We Argue So Much About MVP > Location 951 The minimum viable product is the smallest product release that successfully achieves its desired outcomes.

The New MVP Isn’t a Product at All! > Location 982 A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption. 3. Plan to Learn Faster

Start by Discussing Your Opportunity > Location 999 They discussed: 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 what would they be using it for? Why would they want it? What problems would it solve for customers and users that they couldn’t solve today? What benefit would they get from buying and using it? Why are we building it? If we build this product and it’s successful, how does that help us?

Start by Discussing Your Opportunity > Location 1008 Your first story discussion is for framing the opportunity.

Validate the Problem > Location 1012 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 the Problem > Location 1015 Validate that the problems you’re solving really exist.

Validate the Problem > Location 1021 The important thing for you to take away is that the more they learned, the more the original opportunity was changed— eventually, a lot. It’s lucky they didn’t just get to work building what they were told to. That wouldn’t have served their customers or their organization.

Validate the Problem > Location 1023 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.

Prototype to Learn > Location 1028 Prototype to Learn 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.

Prototype to Learn > Location 1032 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.

Prototype to Learn > Location 1035 Sketch and prototype so you can envision your solution.

Prototype to Learn > Location 1040 I’ve been in these situation lots of times, and I’m always surprised about what I learn from the people who’ll really use my solution. All I can tell you is, be prepared for surprises and bad news.

Prototype to Learn > Location 1044 Prototype and test with users to learn whether your solution is valuable and usable.

Watch Out for What People Say They Want > Location 1051 And if you show people all the cool ideas, of course they’ll love them. But Eric knows his job is to minimize the amount he builds and still keep people happy. How much could he take away and still have a viable solution?

Watch Out for What People Say They Want > Location 1058 He knows his customers and users can imagine the product would be great to use, and knowing that gives him the conviction to up his bet. But the real proof is when those people actually choose to use it every day. That’s the real outcome he’s looking for— and the only outcome that’ll get his company the benefit it really wants. And it’s going

Build to Learn > Location 1063 Eric and his team actually do get to work building software. But their first goal isn’t to build a minimum viable product. Actually, it’s to build something less than minimal— just enough that potential users could do something useful with it. Bookmark - Build to Learn > Location 1069

Build to Learn > Location 1078 Eric’s backlog is organized as a story map with the backbone in yellow stickies across the top. Those yellow stickies have short verb phrases on them that tell the big story of what his users will do in the product, but at a high level. Below it are all the details— the specific things they’ll do and need to really use the product. While the details he and his team work on change from release to release, the backbone stays pretty consistent.

Build to Learn > Location 1082 The top slice, above the tapeline, is the one Eric and his team are working on right now. This release will take Eric two sprints. He’s using a Scrum development process where his sprints are two- week time- boxes. So two sprints equate to basically a month. Below that are slices running down the board. The next slice contains what they think the next release might be, and so on. To the left of each slice, just as with the Globo.com team, hangs a sticky note with the release name and a few

Build to Learn > Location 1089 As the team members worked together to plan their work, they removed those sticky notes and placed them on a task board to the right of the story- mapped backlog. That task board shows the stories they’re working on now in this sprint, along with delivery task— the specific things that the developers and testers will need to do to turn the ideas in the story into working software.

Iterate Until Viable > Location 1099 Eric may have started this whole process with an idea about what the minimum viable product might be, but he’s purposely built something less than minimal to start with. He’s then adding a bit more every month. He’s getting feedback from his development partners— both the subjective stuff from talking to them, and the more objective stuff he gets from looking at data. He’ll keep up this strategy, slowly growing and improving the product, until his development partners actually start using the product routinely.

Iterate Until Viable > Location 1103 In fact, what Eric’s hoping for is that they become people who’d recommend the product to other people— real reference customers. When they do, that’s when he knows he’s found minimum and viable. Bookmark - Iterate Until Viable > Location 1106

How to Do It the Wrong Way > Location 1124 Treat every release as an experiment and be mindful of what you want to learn.

How to Do It the Wrong Way > Location 1126 Always keep your target customers, users, and the outcomes you’re hoping for in mind. It’s really tough to get the same great outcome from all types of users. So focus. Bookmark - Validated Learning > Location 1134

Validated Learning > Location 1141 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. It just so happens that building something to put in front of customers is one of the best ways to learn if we’re building the right thing. Bookmark - Really Minimize Your Experiments > Location 1160 4. Plan to Finish on Time

The Secret to Good Estimation > Location 1209 The best estimates come from developers who really understand what they’re estimating. Bookmark - The Secret to Good Estimation > Location 1213

Plan to Build Piece by Piece > Location 1221 he’s got to decide which scenes should be shot first, and which scenes get shot last. He knows that in the end the entire movie needs to come together and look like one coherent whole. So Mike worked with his team to create a development plan. This is what they did: they sliced their map into three, crosscutting slices. The first slice cuts all the way through the functionality. Once they build all those pieces, they can see the functionality working from end to end. It wouldn’t work in all the situations it needs to, and if they shipped to users this way, those users would howl. But Mike and his team will be able to see the software running end to end. They’ll be able to put real data in it to see how well it performs, and they could apply some automated testing tools to it to see how well it scales. They can learn a lot about the technical risks that might cause them trouble later on. They can be more confident going forward that they will be able to release on time. Or, at least they’ll spot the unforeseen challenges that would slow them down. I call this first slice a functional walking skeleton— a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”

Manage Your Budget > Location 1308 It was later in life that I learned I’d benefit from sketching the whole composition first. From there I could get proportions right, and make changes to the pose of the creature. I’d maybe even reconsider what I was going to draw.

Iterative AND Incremental > Location 1326 Use iterative thinking to evaluate and make changes to what you’ve already made. Bookmark - Iterative AND Incremental > Location 1337 5. You Already Know How

Iterative AND Incremental > Location 1380 you’re already wired to understand all the basic concepts used to create a map. Let’s work through an example right now,

1. Write Out Your Story a Step at a Time > Location 1385

2. Write Out Your Story a Step at a Time

3. Write Out Your Story a Step at a Time > Location 1394 Tasks Are What We Do Take a look at all the sticky notes you wrote. Notice how all of them start with a verb? Well, almost all of them. These short verb phrases like “Take a shower” and “Brush teeth” are tasks, which just means something we do in order to reach a goal. When we describe the tasks people using our software do in order to reach their goals, we’ll call them user tasks. It’s the most important concept to building good story maps— not to mention writing and telling good stories. You’ll find that almost all the sticky notes in story maps about what people do using your software use these short verb phrases.

4. Write Out Your Story a Step at a Time > Location 1406 User tasks are the basic building blocks of a story map.

5. Write Out Your Story a Step at a Time > Location 1409 you may want to look back at your list and see if there’s anything you skipped writing down.

6. Write Out Your Story a Step at a Time > Location 1416 Keep that in mind when you’re thinking about people using your software. They may have different goals when using it. They may use it in different contexts that force them to take into account other people or things.

7. Write Out Your Story a Step at a Time > Location 1421 Tasks are like rocks. If you take a big rock and hit it with a hammer, it’ll break into a bunch of smaller ones. Those smaller rocks are still rocks. It’s the same thing with tasks. Now I don’t know when a rock is big enough to be called a boulder, or small enough to be called a pebble, but there’s a cool way to tell a big task from a small task.

8. Write Out Your Story a Step at a Time > Location 1427 Alistair uses an altitude metaphor where sea level is in the middle, and everything else is either above or below sea level. A sea- level task is one we’d expect to complete before intentionally stopping to do something else. Did you write “Take a shower” in your list of tasks? That’s a sea- level task because you don’t get halfway through your shower and think, Man, this shower is dragging on. I think I’ll grab a cup of coffee and finish this shower later. Alistair calls these functional- level tasks and annotates them with a little ocean wave. But I’ll just call them tasks. Tasks like “Take a shower” break down into lots of smaller subtasks like “Adjust water temperature” and “Wash hair,” and, if you’re my wife, something involving an exfoliating loofah thing. Remember, people are different, and you’ll see behavior differences in the way they approach tasks. Alistair annotates these with a little fish because they’re below the ocean.

9. Write Out Your Story a Step at a Time > Location 1435 Finally, we could roll up a bunch of tasks into a summary- level task. Taking a shower, shaving, brushing teeth, and all that other stuff you do in the morning after you get out of bed could roll up into a summary task. I’m not sure what I’d call it, though. “Getting cleaned up?” “Morning ablutions?” Ablutions is a silly word. Don’t use that. Use the goal- level concept to help you aggregate small tasks or decompose large tasks.

10. Write Out Your Story a Step at a Time > Location 1439 Use the goal- level concept to help you aggregate small tasks or decompose large tasks.

11. Organize Your Story > Location 1441

12. Organize Your Story

13. Organize Your Story > Location 1446 I’ll call this left- to- right order the narrative flow, which is a fancy way of saying “storytelling order.” We’ll call this whole thing a map and that narrative flow is its left- to- right axis. Wow, my flow got pretty wide. I started stacking things that happen in and around the same time. As I lay out the flow, I see I already missed a few details, and I’m trying to decide if they matter. Maps are organized left- to- right using a narrative flow: the order in which you’d tell the story.

14. Organize Your Story > Location 1451 Maps are organized left- to- right using a narrative flow: the order in which you’d tell the story.

15. Explore Alternative Stories > Location 1458

16. Explore Alternative Stories

17. Explore Alternative Stories > Location 1460 Take a minute and think about what you did yesterday morning. If there are different things you did yesterday morning than you did this morning, write them down and add them to your map.

18. Explore Alternative Stories > Location 1461 Think of mornings when things went wrong. What if there was no hot water? What did you do then? What if you were out of milk or cereal or whatever you normally eat for breakfast? What if your daughter flew into a panic because she forgot to do her homework that’s due today, which is what happens in my house every once in a while. Then what? Write tasks for what you’d do and add them to the map. Now, think about your ideal morning. What would make your morning perfect? For me, it would be getting some exercise and enjoying a long breakfast while I catch up on some reading. But then I’d have to get up a lot earlier and stop hitting snooze.

19. Explore Alternative Stories > Location 1466 Notice also that you’ll want to put some tasks in a column, both to save space and because they seem similar to other tasks you might normally do. For example, you might find that you’ve got tasks for making a really great breakfast that you can put in a column along with the tasks for making the quick breakfast you normally make. My friend David Hussman calls this “playing What- About,” a phrase you might remember from Chapter 2 and Chapter 3. Unfortunately, we could play What- About for a long time and make this map huge. I added a few more things to my map specifically for things I wish I’d done, like exercising or doing a bit of relaxing reading during breakfast. I also added a few more common alternatives that often happen in the morning. Details, alternatives, variations, and exceptions fill in the body of a map.

20. Explore Alternative Stories > Location 1474 Details, alternatives, variations, and exceptions fill in the body of a map.

21. Distill Your Map to Make a Backbone > Location 1498

22. Distill Your Map to Make a Backbone

23. Distill Your Map to Make a Backbone > Location 1501 If you step back a bit and look across your map from left to right, you’ll find there are bunches of stories that seem to go together— for instance, all those things you do in the bathroom to get ready, or all those things in the kitchen to make breakfast, or that junk you do to check the weather, grab a coat, and load your bag with your laptop or other stuff you’ll need before leaving the house. Can you see those clusters of tasks that seem to go together to help you reach a bigger goal?

24. Distill Your Map to Make a Backbone > Location 1517 Activities and high- level tasks form the backbone of a story map.

25. Slice Out Tasks That Help You Reach a Specific Outcome > Location 1522

26. Slice Out Tasks That Help You Reach a Specific Outcome

27. Slice Out Tasks That Help You Reach a Specific Outcome > Location 1527 Write “Get out the door in a few minutes” on a sticky and place it to the left of the map near the top. Now, imagine a line slicing through the middle of the map left to right— kinda like a belt. Now, move all the tasks below that line if you wouldn’t do them to reach the goal of getting out in a few minutes. Don’t move the activities down, even if there are no tasks left under them. Having the activity with no tasks in it lets you show that you aren’t going to hit that goal this morning. You’ll likely be left with just a few tasks in the top slice. Now go back through the flow and fill in tasks that are missing and that you would do if you were late. For example, you might normally take a shower, but when you’re late you instead add in tasks like “Splash water on face” or “Use a washcloth to wash the particularly stinky parts of my body.”

28. Slice Out Tasks That Help You Reach a Specific Outcome > Location 1539 Use slices to identify all the tasks and details relevant to a specific outcome.

With Software It’s Harder > Location 1609 If you’re a software professional, it may take you a while to stop talking about features and screens, and to start writing short verb phrases that say what people are really trying to do.

With Software It’s Harder > Location 1611 This will be really hard if you don’t know exactly who your user is, what she’s trying to accomplish, or how she goes about it. Sadly, trying to build a map in this situation will just point out what you don’t know. If that’s where you are, then you’ll need to learn more about people and what they do. Better yet, work with them directly to create a map.

With Software It’s Harder > Location 1614 Six Simple Steps to Story Mapping I can boil down the last four chapters into just six steps. You might be thinking, Why didn’t he do that in the first place? But then I’d have skipped telling you the stories, and just given you the requirements. And that just doesn’t work. While I know there are lots of right ways to build up and use a story map, I have found that the following six-step process works well for me: Frame the problem. Who is it for, and why are we building it? Map the big picture. Focus on breadth, not depth. Go a mile wide and an inch deep (or a kilometer wide and a centimeter deep, for my friends in the rest of the world). If you don’t have a clear solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have. Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can (and likely will) go wrong. For extra credit, sketch, prototype, test, and refine solution ideas—changing and refining the map as you go. Slice out a release strategy. Remember: there’s always too much to build. Focus on what you’re trying to achieve for your business, and on the people your product will serve. Slice away what’s not needed to reveal minimum solutions that both delight people and help your organization reach its goals. Slice out a learning strategy. You may have identified what you think is a minimum viable solution, but remember that it’s a hypothesis until you prove otherwise. Use the map and discussion to help you find your biggest risks. Slice the map into even smaller minimum viable product experiments that you can place in front of a subset of your users to learn what’s really valuable to them. Slice out a development strategy. If you’ve sliced away everything you don’t need to deliver, you’ll be left with what you do need. Now slice your minimum viable solution into the parts you’d like to build earlier and later. Focus on building things early that help you learn to spot technical issues and development risks sooner. 8. It’s Not All on the Card

We’re Gonna Need a Bigger Card > Location 2013 But I don’t think even Kent and the folks who perfected the concept of stories actually thought that all these conversations between all these different people could be contained on just a single card, and in fact, they usually aren’t. The metaphor that works for me is a card in a library card catalog, for people who are old enough to remember when libraries actually had card catalogs. Stories written on cards work a bit like those. If I pick up a card from a card catalog, it’s going to have just enough information for me to identify the book. 13. Start with Opportunities

Dig Deeper, Trash It, or Think About It > Location 2769 Here’s the flow of spaces in the Opportunity Canvas. 1. Problems or Solutions Ideally, we should start with a clear problem we’re trying to solve. However, the world is rarely ideal. We’re often given a feature or enhancement idea and then need to work backward to understand the problem. Start with what you have. Solution ideas List product, feature, or enhancement ideas that solve problems for your target audience. Problems What problems do prospective users and customers have today that your solution addresses? If you’re building a product for entertainment like a game or tool to share fun stuff on a social network, they may not have a real “problem” to solve, just a desire to be entertained. 2. Users and Customers What types of users and customers have the challenges your solution addresses? Look for differences in users’ goals or uses that would affect their use of the product. Separate users and customers into types based on those differences. It’s a bad idea to target “everyone” with your product. 3. Solutions Today How do users address their problems today? List competitive products or workarounds your users have for meeting their needs. 4. User Value If your target audience has your solution, how can they do things differently as a consequence? And how will that benefit them? 5. User Metrics What user behaviors can you measure that will indicate that they adopt, use, and place value in your solution? 6. Adoption Strategy How will customers and users discover and adopt your solution? 7. Business Problem What problem for your business does building this product, feature, or enhancement solve for your business? 8. Business Metrics What business performance metrics will be affected by the success of this solution? These metrics are often a consequence of users changing their behavior. 9. Budget How much money and/or development would you budget to discover, build, and refine this solution? 14. Using Discovery to Build Shared Understanding

Four Essential Steps to Discovery > Location 2891 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.

Four Essential Steps to Discovery > Location 2898 1. Frame the Idea If you really use an opportunity backlog, and really had an opportunity discussion to make your decision to begin discovery, then you’re most of the way there. Use framing discussions to kick off focused discovery. Involve the people who’ll work together to better understand this opportunity. Use framing discussions to set bounds for the work you’re doing. If you’re clear on why you’re building something and who it’s for, you and your team will be better able to stop discussions about solutions that don’t solve the problem you’re focusing on, or aren’t for the users you’ve targeted.

Four Essential Steps to Discovery > Location 2903 2. Understand Customers and Users

Four Essential Steps to Discovery > Location 2906 Sketch simple personas

Four Essential Steps to Discovery > Location 2908 A persona is an example of your target user assembled from the facts and sometimes the assumptions you have about your users.

Four Essential Steps to Discovery > Location 2926 Build lightweight personas together to build shared understanding and empathy within the team.

Four Essential Steps to Discovery > Location 2931 Create organizational profiles or orgzonas If you’re building a product that organizations might buy—for example, an accounting product—take the time to list different types of organizations and record some details about them. These are your customers—the people with cash in hand who need to get some value from your product.

Four Essential Steps to Discovery > Location 2936 Map how users work today You can go one step deeper and map the way your users work today without your product, or with your current product.

Four Essential Steps to Discovery > Location 2943 The body of the map contains facts, observations, pains, and joys. When you map what you understand now, you’ll see “hot spots”—areas in the flow where there are lots of problems. You’ll also find rewards—the joys at the end of a set of steps that make your users’ efforts worthwhile. You can build valuable products by taking away pains, or magnifying joys. Use this map as a springboard for brainstorming solutions, or for validating that the solution you have in mind really does solve problems.

Four Essential Steps to Discovery > Location 2947 3. Envision Your Solution

Four Essential Steps to Discovery > Location 2951 Map your solution This is where story maps shine, at least for me. I use the story map to imagine the life of my users with the solution we’re building in place. 15. Using Discovery for Validated Learning

How to Mess Up a Good Thing > Location 3279 Here are a few great ways to mess up a design process: Start without framing the business needs and target customer well. This’ll make it hard to prioritize who to focus on, and hard to tell if you’re finding a good solution. Spend a lot of time doing thorough research and making sense of what you’ve learned. You’ll never run out of things to learn—so why stop? Time-boxing might have been a good idea. Don’t spend any time at all talking to people and learning from them. After all, we’ve got a lot of data, and really, our solution ideas are great. We just need to get going on designing them. Fail to focus on specific problem, and instead try to solve lots of problems for lots of people. The more problems you solve the better, right? Except that big problems often result in big solutions. And trying to solve a problem for people with conflicting needs can result in a solution neither person likes. Consider multiple solutions, but only ask real designers to contribute solution ideas, because they’re the only ones trained to have good ideas. Don’t waste time considering multiple solutions, because the idea we have is so good. Beautifully craft a prototype that really looks real, but doesn’t work well enough for customers and users to really use it. After all, when they see it, they tell us it “looks really lovely.” Convince yourself and then others that this well-researched, professionally designed solution will work. After all, you’ve followed a rigorous design process. What could go wrong? Don’t worry about how much it’ll cost to build. It’s the right solution, and any cost to build it is justified. When you deliver the solution to customers and users, and don’t see the outcomes you expect, find the breakdown in the process that’s at fault. Or better yet, find a person or group you can blame.

Stories and Story Maps? > Location 3404 We hope to build simple prototypes in hours, not days. Even the prototypes we build using code and live data we hope will take days, not weeks. We’re building to learn, and we expect most of our ideas to fail, or at minimum, need some adjustment to be successful. So we focus on working together quickly, agreeing quickly, and minimizing the formality.