Getting started with User Story Mapping – Jeff Patton on The Product Experience

37 min read
Share on

There’s nothing more useless to a product team than a big backlog. Bringing backlogs to life—making them usable, relevant, and getting value from them—is something that transforms ordinary teams into extraordinary ones. To guide us on how to do that, we asked Jeff Patton, creator of User Story Mapping, to join us on the podcast.

Featured Links: Follow Jeff on LinkedIn and Twitter | Jeff’s upcoming Training Sessions | Buy Jeff’s book ‘User Story Mapping’ | Alistair Cockburn’s book ‘Writing Effective Use Cases’

Support our sponsors

Give Sprig (formerly Userleap) a try for free by visiting Sprig.com to build better products.

Episode transcript

Lily Smith: 

Hey, Randy. So today I had a teamwork day I got up, got ready, had breakfast, picked up our CS manager from the station and then drove to a really cool paddleboarding place just outside bath.

Randy Silver: 

You know, really, as much as I’d love to hear about your day, where are you going with this?

Lily Smith: 

I’m just telling you the story of my day, you know, I’ve actually always been pretty bad at telling stories. But one type of storytelling that I love, probably because it doesn’t require much charisma to do it. Is user story mapping?

Randy Silver: 

Oh, yeah, you have a charisma problem. You’re the one of us everybody likes. But yeah, today we’re talking to the godfather of user story mapping, and possibly one of the nicest people in product. Although, you know, there are quite a few. We’re talking to the legendary Jeff Patton,

Lily Smith: 

legendary indeed, and also quite a spring jacket and I reckon, definitely, literally, write a book on user story mapping. And if you don’t currently use this technique in your own product development process, I can guarantee you’re going to want to after this chat. The product experience is brought to you

Randy Silver: 

by mind the product. Every week, we talk to the best product people from around the globe about how we can improve our practice, and build products that

Lily Smith: 

people love. Because it mind the product calm to catch up on past episodes, and to discover an extensive library of great content

Randy Silver: 

and videos, browse for free, or become a mind the product member to unlock premium articles, unseen videos, ama’s roundtables, discounts to our conferences around the world training opportunities.

Lily Smith: 

My new product also offers free product tank meetups in more than 200 cities. And there’s probably one for you.

Randy Silver: 

Jeff, thank you so much for joining us tonight on the podcast. It’s wonderful to have you here. I am super happy to be here. So for the three people listening who don’t already know your name, just give us a quick introduction. How did you get into product? What are you up to these days?

Jeff Patton: 

I’m sure there’s more than three. It could be? Well, yeah. All right. How did I get into product. I’m old. I’ve been in software development a long time, I think I started didn’t start till in my late 20s. There wasn’t even the concept of a product manager back then I don’t think the very first time I was actually called product manager was in 2000. And part of the reason I’m here is because I started a startup in 2000. That was using this new process called extreme programming that became an agile process. And in extreme programming, I was in the customer role or what in Scrum is called the product owner role. But my business card said Product Manager. So that makes me a very early Product Manager in this agile space. So the intersection of agile and product management. That’s where I’ve been playing for a long time. So I mean, I’ve always led teams in product companies that were building products that we built and sold from a lot of traditional it not until I got out of not into consulting in the mid 2000s.

Randy Silver: 

And is that what you’re doing now?

Jeff Patton: 

What do I do now? The what is the Peter Principle that you rise to your level of confidence. Now, because of written a book written written a book and I book, I worked for a consultancy called thoughtworks for a very long time really fabulous people. I started focusing more on the product stuff, and I’ve been an independent consultant for the last 10 years, which means I don’t really have a job or I do an awful lot of teaching both publicly and inside companies, and then some coaching and consulting inside of companies. But most of my focus these days is on helping organisations move into become more product centric, or use more product thinking in their process.

Randy Silver: 

So Jeff, one of the reasons we asked you to join us today is there’s a technique or a tool that you’re really well known for, called user story mapping. And we wanted to get into that because it’s incredibly useful. But before we really jump into it, can you just give us some background? What is a user story map and where did the broach come from?

Jeff Patton: 

Like all good things, it was stolen. Anybody who is a user experience person would have heard of something like a journey map where you’re mapping customers journeys. If you’re a cx designer, customer experience designer, sometimes they’ll refer to this as a service blueprint. And the idea of doing a left to right flow that tells a story of what your customers or users are doing with your product isn’t a super new idea. But I came from working in an agile space and agile people have to build backlogs fill up full of stuff that they should build. Well, it turns out the easiest way to figure out what you should build is to map your customer’s journey and then sort of decompose that into stuff to build, I came up or I use came up again, borrow that technique of mapping experience, and used it as a foundation to build product backlogs and support planning. And it gives us more of an outside in customer user in perspective, and thinking about instead of just thinking of features that we intend to build, that’s, that’s what a story map is left to right tells a story top to bottom breaks it down into parts and pieces.

Lily Smith: 

And the way that you think about it today, has it changed much from the original concept that you came up with? Or that you borrowed a long time ago?

Jeff Patton: 

Yeah. The original originally was very, it was, it was really a utility. No, it actually that adapted from years ago, I’d learned some task analysis skills, and it was borrowed from some task analysis, things where I would start to do task analysis. And it turned out that those tasks could break down. You know, if a task is a short verb phrase, it’s easy to drop that into that silly user story format. As a user, I want to shorter phrase so that I can complete something. So it was an easy way to build a backlog. So yeah, back in the old days, I was squarely fixated on using the technique to think through products that we were designing, and testing and building. But more and more lately, in the context of teaching, I’m dropping back to what a journey map would be. If I start working with a product person or a product company, the first thing I want them to do is, tell me about the users you have today and map the experience you have today. That’s, that’s not a map about the future. It’s not a map about a feature I want to build or a new product. It’s a map without Well, it shows what you understand about the product today. Or an often what you don’t understand about your user centred product today.

Randy Silver: 

So before we jump into some of the specifics about it, one of the things I was curious about is, you mentioned that you use it in conjunction with backlogs and backlogs are often very flat things. What How does this enhance we’re working with a backlog or visualising it.

Jeff Patton: 

I hate the backlog concept. For me, there’s a couple kinds of backlogs. And yeah, if you’re in the Agile community, it’s a popular idea. say those are one backlog. And it’s always prioritised. However, we build backlogs filled with opportunities. And this is what my friend Marty Kagan refers to as an opportunity backlog. And it’s probably because we’ve worked together in the past, but we’ve got features, we’ve got ideas, we’ve got capabilities, sometimes we’ve got problems to solve, those are big, big rocks, big chunks. And we have it, we use our use strategy to prioritise those, we use target outcomes, or something wrapped into an OKR to prioritise those things. But those things are big. I can’t throw those things into the next sprint to build. So I might prioritise those things based upon strategy. But then I pull one of those things out, because it’s strategically important for me to focus on it. That’s when I start discovery work, I can build a map of how people do things, today, I can build a map of the solution, I can use the solution map to break it down into lots of different options, I can slice out what I want to release, it’s lots of little parts and those little parts that I decide, these are the things I’m going to actually release. That’s what I shovel into this more tactical day to day backlog. Now, those things, yeah, they flatten back out, because what they turn into at that point is a plan. What I’m going to build first what I’m going to build next and what I’m going to build next Yes, at some point in time, out of the outside edge, it was what’s strategically important next, and at the inside edge, it’s what I want to build next. And the map ends up being a bridging thing to help you move from one to the next. That makes

Lily Smith: 

it Yeah, it sounds a lot like you’re describing, you know, like a roadmap style document would show you what opportunities you have and where they might say it. And then your backlog is just like your very kind of tactical. This is what we’ve decided to work on. And these are the tasks that we need to get done. And probably like some sort of semblance of order in which they need to be done. But where does the where would a user story map, sit with those other

Jeff Patton: 

artefacts right in between there? Okay. First, let’s say you’ve got a roadmap and it has a big capability. It’s a feature. It’s it. That feature may be used by a couple different types of users. And it’s going to take weeks to build maybe a month or more to build. But if you’re using Scrum or some Agile process, we want it broken down to the things that take a couple days to build. So how do you take something that is going to take weeks or To build and break it down into something that takes days to build many things that takes days to build, sometimes hundreds of things that take days to build. And how do you do that with while keeping the user in mind? The way I unpack one of those things is say, Okay, we’ve got a feature telling me a story about the feature, who’s the person that’s going to use the feature. And now let’s tell a story if you give me a beginning and an end and tell the story end to end, okay, now I’ve got a narrative. And then let’s say every step, let’s break it down into parts, the things that we might build those parts, those become the pieces that go into that more tactical backlog. That’s, again, that’s where it fits. Yeah, you got a roadmap of big chunks, those strategically important things. That’s why they’re in the roadmap to begin with. And we have this need to have these little parts that we build the story map is the bridging is the glue between that.

Lily Smith: 

So with that process, do you build a story map specifically to analyse and design and break down a large opportunity? And then once you’ve delivered it, do you throw the story map away? Or does it not change? Yeah, you just don’t waste

Jeff Patton: 

combustible process. It’s, it’s how you make sense of your you’re thinking about that product. Now, let’s, a lot of times people will start with a big capability. And they will map it out, it ends up being a pretty big map, and then they’ll decompose it into parts. And then we take that decomposition and say, okay, maybe we can’t really sell this capability at once. Maybe we need a first release, or set a second release and a third release. Or sometimes we do good, better best slicing. Let’s get the good enough one out there in a first release. Let’s make it better in a second least release. Let’s take a second release and move it out to a larger market market. And the story mount helps you think of the whole thing holistically. So yeah, in that situation, you might keep the story map around. And so a lot of people will use a story map and connected using tools like mural or mural or some plugins for JIRA, you can connect it to tickets in JIRA, let’s say. And as people start building tickets, in JIRA, you can see the map change colours or light up you can see what’s been built. And that’s it starts to expose your development strategy. Some people build left to right or this step, then that’s everything for this step and everything for this step and everything for this step. You know, what I’ll advocate is building in thin slices, let’s build it super thin end to end, slice, get it working, see it work, and then build it up from there. You can’t you’re in a flat backlog, you can’t see that kind of strategy play out. But in a story map, you can see I’m waving my arms wildly, and I realised you guys can see me, though the people listening can’t

Randy Silver: 

I can’t hear you waving or I’m so worried.

Jeff Patton: 

Again, the the map exposes so yeah, some people keep them around because they want to see how as I proceed through development, how am I working? am I working in thin slices? am I working the top the bottom in big chunks? What am I missing? Where what parts of this feature capabilities? Big capability? Have I worked on what parts have an idea touched? You again, if we’re talking about something big? And then if I slice it into multiple releases? I don’t know I’ve got enough for the first release. And what have I pushed down into second and third releases? Or usually find parts that you push down into? Probably never? Those kinds of things. Yeah, there’s all that accents a little bit.

Randy Silver: 

Yeah, but let’s dig into what a step is in the map. But what’s what’s what distinguishes one step for another? Is it purely from the users perspective? Or are we also looking at the back end actors? Are we looking at an entire system perspective? So how do we get started to do what is a step in a story map?

Jeff Patton: 

Perfect question. Now, if we’re building stuff that’s user facing, yeah, I want to start with users steps. There’s a concept that’s discussed in the story mapping book. And you know that apart from a guy named Alistair Coburn who wrote a book on use cases and when we talk about steps or actions that people take, he will divide steps into the into some basic levels or using an altitude level metaphor. In the middle is sea level or functional level. A functional level step is something you would do with the intention of completing it. Before moving on to do something else. I will do an exercise to teach people story mapping where I’ll ask them to tell me the story of getting ready this morning. It starts when you woke up and it ends when you arrive here. And in that story will usually be a step called take shower, take showers functional level because you don’t get halfway through it and say that the showers driving on I think I’m going to grab a cup of coffee and finish my shower up later. functional level stuff, but it must break down into smaller steps or sub functional level steps. Now, it so when you say step depends on like, if I’m just adding one small feature, sometimes a feature sort of feels like one functional level thing. And I will break it down into sub functional things that makes up the back the left the right flow, or the top of the map is the backbone. LCM map is like, if you rip the vertebrae out of an animal and threw it onto the ground, you’d see, you see the backbone and you’d see ribs hanging down. And the that’s the, that’s the decomposition of that there. So sometimes it’s the altitude level or goal level of that backbone might be functional level where each step is a distinct the users do this, and then they do this and they, and then it breaks down into sub functional things below. Or sometimes we’re just mapping one small feature where, you know, the whole thing is one step. And we decompose that left to right. And so the goal level varies, you know, map is a good metaphor of a globe as a way to see what countries are an atlas like? Well, a map of a country might let me see where states are and where big major highways are in the states and a city map will let me see how to get from one place in a city to another. And a map of the building will let me find your office relative to somebody else’s, you don’t use the same altitude level of map for the same thing. And

Randy Silver: 

do you add things to each step then, like, happy or sad face, or duration of how long a step takes? or things like that? Or is it purely functional and descriptive.

Jeff Patton: 

So the beginning of my book, and almost the beginning of every freaking talk, I give, I draw this super simple model that I’ve been calling them now and later model for a long time, or analyst by column as is in to be an eye in early you know, earlier in our conversation, I talked about making a journey map of the way it works, the way it works today. So yeah, I can map somebody experiencing my product today. And I can say how long a step takes today. And I can say if they’re happy or sad today. But at some point in time, I need to build this work of fiction, this map of what I imagined user will do in the future. Now I can label that with where I think they will be happy in the future, or I think there’ll be sad in the future, I hope they’re not going to be sad in the future in my future world. And I can label it with how long I believe each step should take. But the future is a fiction. There’s no evidence there of anything until we release it. And that’s the cool thing about the future is it doesn’t take very long before it becomes the present. And then we can actually measure that stuff. It rolls that way. So yes, when I’m building a journey map to really understand or unpack the way people work things today, the stuff you just mentioned, super important. Look on step. So look for frequency and duration, how long? How many times how often do people do these? How long does it take and then look for pain and rewards. If there’s something that’s done at a high frequency or takes a long time and has pain associated with it, that’s a problem you need to fix. That’s what makes this kind of map super valuable. But it is not the map you use to build a backlog. It’s the map you use to expose problems in your product so that you can figure out problems you should fix and you build a backlog out of those things you should fix

Randy Silver: 

usually makes it easy to build an embed micro surveys into your product to learn about your customers in real time. product teams at companies such as square, Adobe and Dropbox, use user leap to gather qualitative insights as easily as they get quantitative once and automatically analyse the results. So teams can take quick action.

Lily Smith: 

If you’re part of an agile product team that believes in building better products, and I sure hope you are by obtaining insights from users then give us a try for free by visiting easily calm, that is user leap.com. Where do you lie? I’m trying to imagine how you would add all of that additional contextual information on to the map without it becoming quite overwhelming. Is there is there a specific format that you advocate or is it very much a whatever works?

Jeff Patton: 

It’s very much or whatever works. Now that said there are people in companies that try and come up with formatting and do things I habitually I’ve colour coded a bit. Meaning if I’m trying to put a pain on there, I’m going to use Oh, I won’t put a frowny face on one sticky I’ll add a different colour I’ll draw out a red sticky for a pain and a green sticky for joy. reward, and then the different colours, stickies for different things. And then there’s another trick that if you’re working with sticky notes that you may not know, but every, every pack of sticky notes comes with two shapes. It comes with a square and a diamond for free. So if you twist it 45 degrees, now you got a whole nother set of sticky notes and use diamonds for other kinds of things. So I’ll use different colours for different channels. So yeah, it can become a chaotic mess. That’s why again, used to use sticky notes. Now we’ll use tools like neural or neuro and I’m pleasantly surprised at how you can do almost all the same things we used to do on walls. And the cool thing about mural mural is the wall is the sticky notes never fall off mural. And the wall is larger than any wall on the planet. So it can get really big. But yeah, you got to watch out for map shock. If the maps get too big or too bloated. And it usually you’re taking on too big of a problem.

Randy Silver: 

I am really curious about that. Because you know, one of the great benefits is walking into a team space and seeing that laid out in that ambient awareness that other people get Where’s whether it’s Miro mural is you have to be intentional to go there, you don’t get it by accident. And there is a fatigue around around being on video for too long. I’m just kidding. Over the last year and a half or so, how have you adapted to that? Have you seen teams adapted? Do they use it as well as as effective as a bunch of people being in a room with sickies?

Jeff Patton: 

Know, they asked the same question you just did. Know it again, all the working is strictly remotely, that’s a new thing. And people are just adapting to it. And I’ve been asked the question, how do we how do we get that same ambient or, you know, with the people in the Agile community community refer to this as an information radiator, something that’s on the wall and like a radiator on the wall that radiates information and not just heat it or not heat, you walk by it, you see it you you can just like, you know, you’re in London, correct? You can, if I’m down the tube, I can walk up to the map and say I’m here and we’re trying to get there. And this is the train I need to grab and which track is it and the map is there, it’s there to help guide me you see that in teams, those teams faces, I will ask people to build a big map that shows the shape of their product as it is. So when we’re picking up something to work on one of these small tactical stories that’s in the backlog, we can walk up to the big map and see, okay, it’s about here. What I’ve asked people to do is build a big map. And if you’re using euro boards to have discussions, put it on every board, just it’s again, just like you the same map is it every tube stop. So that anybody at any time can look at it, take the big map and that big map of the way your product is today doesn’t doesn’t change, it doesn’t evolve. It’s a it’s a snapshot and where it is. So it’s an orienting map. So that and that’s Randy what you were describing. That’s the that’s the big map you kind of like to see on the wall to talk about.

Lily Smith: 

So who do you have in the team working on the map?

Jeff Patton: 

If the app cache, there’s a, as I teach, as I teach product management, one of the things I want product people to recognise is, you better not be doing this alone. Otherwise, the job is in Product Manager, it’s bottleneck, you need to surround yourself with other people that help you out. So a product manager should work closely with somebody who is strong technical person. And if you’re building something user facing something that is a user, someone who’s a user experience person, as a Kagan would call that a core product team, some sometimes goes by the jargon of the triad. So those are the people that I like to orchestrate a lot of discovery work and a lot of this mapping stuff. But whose best to have a map is the people that want to be there. It’s common when you’re trying to map the world as it is, it’s common to have subject matter experts there or user experience. People will do research and pour a lot of data they found into a journey map all those pains that they’ve observed and other things like that. So I’ll usually look for kind of a balanced team of somebody who understands technical stuff and business stuff and user experience stuff. I kind of want to have those ideas represented. And then people that know stuff. And then it’s always nice to have people that are observers that are there to learn stuff. They’re not building the map. They’re there to see the map built and observe and ask questions and say, why is this this way? And did you think what about this and sometimes they think of other things. But as a rule, you cannot build a map from scratch with a crowd. It usually goes best with a small group. But once it’s on the wall, a big group can talk about it. Ask questions, make changes, make improvement. But building a map from scratch with a big group does not work. So I look for a small, balanced team, a small cross functional team to build it.

Randy Silver: 

What are the mistakes you see people commonly making?

Jeff Patton: 

This single biggest mistake is one, I’ve already hinted out, I’ve had people mamita come in and help them. Learn how to build a story map. And I’ll say, Okay, first, tell me who your users are. And they scratch their heads. And they can tell me a little bit about that. And then I’ll say, tell me a story about how they would use the product. And then they scratch their heads a lot. And I’ll say, Okay, let’s, let’s get, let me give you a starting point, you know, they login, and then and then lots more head scratching. And if you cannot tell me a story about how people use your product, or how you think they will use the feature you’re about to build, you cannot build a story map, and you bloody well better not be building a feature at all. Again, if you can’t tell me a story about the way someone would use something you’re building, it’s a real risk to build it at all. So yeah, the biggest mistake is people trying to build a map or build a backlog and not really understanding their product, or the people who will use it. The other one is the one we talked about too many people in the room and not the right people in the room to start with. people struggle with this altitude level thing a lot. Sometimes they try and boil the ocean and map everything. Like they’re just building one feature. But they will say, okay, we need to build this one feature. So let’s start the story when they log in, and continue the story until they’re done using the product. And somewhere in the story, we’ll get to this little feature. Now just start the story in the middle start with using the feature you don’t need, like any action movie starts in the middle these days Anyway, you know, is started that the beginning of that, so I see people trying to boil the ocean or map way too much. What else do I see? People suffer from this, if they’re trying to build a solution map or a map of something that will turn into a backlog of things they get built, they get worried that everything they write down has become in scope or is a decision to make to build something. And I don’t want to write that down because then we’re going to be committed to building it. Now I feel mapped up with tonnes of options, I want it when I start to carve out things so I can figure out what I’m going to release, I want to carve out two thirds. So I’m super happy to pour all kinds of crap into it that we do not intend to build. With every part of the map I’ll always play I think I said this early in the conversation that good, better best game? What’s a good enough way to do this? What’s a better way to do this? What’s the best way to do this? And then we’ll make late decisions on which is which to go with. So yeah, some people make the mistake of being really anxious about what they write down or what they put down.

Lily Smith: 

And is there a time when I use a story map isn’t appropriate.

Jeff Patton: 

When you’re soft? You know what I can’t think as a user story map not appropriate. Now, first, I’m not religious about how they need to be built or how they look. You know, now, and it may and it certainly isn’t the only map or the only model. But it’s something has steps. If you can tell a story about how the product is used. A map is just a way to communicate that story. If it’s something you could write a use case for, you can map it if it’s something you can build a workflow model for, you can map it. Any model that has boxes and arrows is just as just a map. Now, and again, I’m not religious about the way that they’re structured or organised. Randy, you asked earlier in this, are they always just functional? Or do they go from the users perspective? And I didn’t all I didn’t all the way answer that question. If we were building something that is a back end service, I will ask people to anthropomorphize the service. And tell me a story about what the service does. The service gets called the work with companies building stock trading applications that the trader submits trade and then the the engine gets to work and runs different strategies are meant to do the buy things. First, the engine does this, then this, then this, then this. And I can tell a step by step short story where the short verb phrases aren’t what people did that what that what that service does without trading. And Yep, that’s a map to I’ve had people say, Oh, I can’t map it because it’s a back end service. If you can write a use case. If you can do something as a sequence, you can map it. And if it helps, don’t call it a story map. Just on the wall in the order that and tell me a story about how someone would use it and go with whatever flow that works best for you.

Randy Silver: 

That’s actually one of my favourite things to teach people is it doesn’t matter what we call it. We don’t have to call it agile. We don’t have to call it anything. We just have to convince other people to act In that way, yeah,

Jeff Patton: 

yeah, that really don’t matter of, you know, the foundational concept I tried to help people understand it, people get hung up on the concept of stories and how they write good stories and how to write good acceptance criteria and all those mechanical things. remind people that the concept of stories is about they’re called stories because of the telling stories of collaborating. And I’ll use this phrase we’re striving for shared understanding. The most retweeted phrase from the story mapping book is that shared documents aren’t shared understanding. And previously, everybody has worked really hard to figure out some perfect communication mechanism, some, some way to model some way to explain or document something so that people will understand perfectly, and going with a story driven approach is an acknowledgement that you ain’t going to get there that we focus on collaboration and the best way to build one of the best ways to build shared understanding is with this shared visualisation, something that we can see and point to, and I don’t care if it’s something you hand drew on a whiteboard. I don’t care if it’s sticky notes. It’s just a lot easier to move sticky notes around than it is to erase things and redraw them on a whiteboard. That’s that some visualisations something you can point in gesture. Help people organise their thoughts in a shared visual space versus everybody organising separately in their head. That’s the that’s the big point. That’s why we do the mapping is to build a shared understanding.

Lily Smith: 

Jeff, you must have worked on a gazillion maps your time have you got like a favourite story yourself of a mapping exercise that really kind of transforms the way that everyone was thinking about the product or uncovered something new and insightful?

Jeff Patton: 

By trying to think of a favourite thing. You one of the most unusual things I’ve had to map is working with a company that builds we were mapping the behaviour of a chip inside of a thing on a cell tower, where pockets of information came in and prioritised packets came out, that was the only job this chip had was to prioritise packets of cellular data. And I said, well, it’s it’s, it’s, it can’t be math. And I said, Well, okay, well, tell me how it works. Well, packets of information come in. And then we do this. And we do this. And as that person is telling me the story, I’m slowly putting sticky notes down by the end of the, by the end of him telling the story, there was a map on the wall. That’s how you map out what you said, You told the story, I could map the story that you tell me that does those are the times when it’s most revealing to people is when people say you can’t map this? And I will ask them, How does it work? And they will tell me how it works. And I will write down what they said, on sticky notes and and I will walk them back through it and ask them more questions and the light. That’s when the lights go off? Oh, my gosh, it is a member it is. All you did was tell us visually represent the story. Think of specific things. But it always happens that when we start mapping the whole story, suddenly people realise these big gaping holes, things they hadn’t forgot about, or that they’d forgotten about. How is it not really clear how people get from this point to this point, then, always, always, gosh, I’ve had people tell me that I really hate story mapping. Every time we do it, we find all this crap that we didn’t know. And that happens all the time. No favourite anecdote about that.

Randy Silver: 

That’s all right. Jeff, we could go on with you about this all night. And it’s been really fantastic. But we’re running out of time. So I’m going to ask one more totally practical question. You talked earlier about mapping it all out and then going from beginning to end in good, better best slices and dealing with it. How do you What’s the practical thing that we need to know about removing, taking that everything up on the wall and making it into releasable chunks?

Jeff Patton: 

First, this is why this is the superpower of maps for me. I get really ticked off when people talk about prioritising backlogs and backlogs are filled with little things. I need to think of a holistic release of things. Now, the trick for prioritisation is to stop prioritising things. Now I give people an exercise to learn how to map I’ll tell them to map what they did in the morning this morning. And then I will I will tell them okay pretend you woke up late and you woke up at 842 and you have to be out of meeting at nine o’clock you have to be sitting down in front of zoom at nine o’clock. Now, rearrange your morning so that you are and people like you and your group can get ready in about, you know, less than 10 minutes or so. Now what that is, is a target audience and target outcome, the target audience is the people in your group, the target outcome is getting ready in 10 minutes or less. Now, if we can agree on target outcomes, or what the general benefits who are the things we’d expect to observe at the end of the release, and who that release is for? Now, we can make prioritizations decisions. Now we know what’s good enough. It’s not a subjective decision about what I think is best. It’s it’s what, what do we need to do to get that outcome? It what’s interesting is to look, yeah, that’s what I’ll focus people on. I don’t know if that’s crystal clear from here, but if you know who the release is for and what outcomes you’re striving for, you can prioritise. And then back to that silly example, when I have people do this in a class, they will carve out a getting ready fast routine. And, and I’ll say, it’s got to satisfy everybody in the group. There’s invariably people in the group that have kids or pets, and so they have to leave steps in there to take care of their kids or take care of their pets. And then I tell them, Look, you can make this really smaller are kicking those people out of your group. This is the way privatisation works. You don’t pull features out of your product you pull feature people out of your target market. This is the evil part about product management. The hardest decisions you will make are not what features go into your product. It’s what people you’re going to help them what people you’re not going to help. That’s the wedge that makes privatisation work.

Lily Smith: 

Jeff, it’s been so interesting talking to you this evening about user story mapping. Thank you so much for joining us and for sharing your wisdom. I love user story mapping. And you’ve just reminded me how much I love it. So I’m going to get back on x seven demo for a while. So. But yeah, it’s been really fantastic. Thank you. Real pleasure to talk about. Thank you very much for having me here.

Randy Silver: 

You know, I’ve seen Jeff talk about how to do all this stuff before. I’ve done this stuff plenty of times. But hearing him talk about it. It’s that that reminds me just how powerful that story mapping can actually be.

Lily Smith: 

I know and it’s refreshing to talk to someone who has such a great perspective on what the real value of the technique is. Their shared context and understanding and knowing what to do next

Randy Silver: 

is the power of chat. And if you’re still listening, you know what to do next tweet about this episode or tag us on LinkedIn. Tell us what you’ve learned from creating a story map. We’d love to hear about it.

Lily Smith: 

Hey, it’s me, Lily Smith and me Randy silver. Emily Tate is our producer. And Luke Smith is our editor.

Randy Silver: 

Our theme music is from Humbard baseband power that’s p A you thanks to our Nick Hitler who runs product tank and MTP engage in Hamburg and plays bass in the band for letting us use their music. Connect with your local product community via product tank or regular free meetups in over 200 cities worldwide.

Lily Smith: 

If there’s not one Nagy you can consider starting one yourself. To find out more go to mind the product.com forward slash product tank.

Randy Silver: 

Product tech is a global community of meetups driven by and for product people. We offer expert talks group discussion and a safe environment for product people to come together and share greetings and tips.