Product thinking and user story mapping with Jeff Patton

Join hosts Murray Robinson and Shane Gibson in a conversation with Jeff Patton, an advocate of agile and lean ways of working and author of the book “User Story Mapping.” In this episode, we focus on the concepts of product thinking and user story mapping.

Key points in this episode:

• Jeff emphasises that product thinking should focus on outcomes rather than output.
• Jeff underlines that achieving product-market fit necessitates a deep understanding of customers and their problems, and the ability to balance customer desirability, business value, and technical feasibility.
• We explore how to construct a user story map and develop a release plan that minimizes risk while delivering as much value as possible within the allocated time and budget.
• Jeff talks about the limitations of requirements and the importance of prototyping. He advises IT teams to concentrate on delivering user outcomes rather than fulfilling requirements.

Tune in to gain valuable insights on how to leverage user story mapping to deliver exceptional products!

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: And I’m, Murray Robinson. 

Jeff: And I’m Jeff Patton.

Murray: Hi Jeff. We wanted to talk to you about user story mapping and beyond. Why don’t we start by getting you to tell us a little bit about yourself, your background and what you’re doing today.

Jeff: I’m in Salt Lake City, Utah where the Agile Manifesto was written and I’ve been in software development a long time. I started my career around 1990 building software for a small product company that made software for retailers. That company is now called salesforce Commerce Cloud after a couple acquisitions. They originally hired me to be a project manager, but it, as it turns out, I, ended up writing code mostly. And I got placed in charge of several different products. Right around in 2000, I got tired of the way my company worked and I left and joined this weird startup in San francisco trying this new process called Extreme programming. So I worked at that startup in San Francisco for 2000? 2001. The term Agile was coined in 2001. And I learned that I had been using an agile process. So I got an early start in agile development and my first job title at that company was product manager. So I’ll tell people I came into agile development from a product perspective. 

Now, all that said like a lot of people that are old, I’ve done every possible role and actually after the startup I work for imploded. I actually went back to the company I left and I focused a lot on this intersection of agile development and product thinking and good user experience practice. Went to work for a little consultancy called ThoughtWorks A long time ago. Just a few hundred people there when I started, but I know that ThoughtWorks is reasonably big presence globally. But worked with them a long time. And these days I work with companies and help them adopt good product practices. The story mapping thing, fits in there. It’s a big part of my toolkit. 

Murray: Okay, so what is the essence of Agile in your opinion? 

Jeff: The Essence of Agile is focusing on us as people and how we work together. Being responsive to what’s going on around us. Focusing on continuously trying to improve the product we’re building and how effectively we work together. 

Murray: You were saying before that Salt Lake City is a countercultural city. So I’m wondering, is Agile a counterculture movement?

Jeff: Hell yeah. I can remember going to the first Agile conference held in Salt Lake City and, we all felt like we were doing something new and edgy and different and we all felt like we had found something. While we might do things completely differently from each other. We were aligned on those values and principles. And there was a lot more tolerance in the early days for different ways of doing things. Now. You get a lot of people saying you’re doing it wrong. In the old days there wasn’t a right or a wrong way. 

Murray: You mainly worked in the product space, so is there a difference between Agile and product? Or is Agile always been about product?

Jeff: Agile’s never been about product. When you think of a great product, what makes it great? Gimme a couple things.

Murray: It’s better than anything else I’ve used before to do whatever I want. For example, when I first tried Google’s search, it was so much better than all the other search engines, it just really made it so much easier for me to find the information I wanted.

Jeff: It’s easier. It’s better than alternatives. Shane, you wanna add anything to that?

Shane: For me it goes back to simplicity. When it just works, It’s simple. You just get the job done, then it’s a great product. 

Jeff: So look, I ask people those questions and I record a whole bunch of answers, and then I’ll tell people, look, nobody said finished on time, or stakeholders love it, and nobody even says it has more features than other products. Because those things aren’t product qualities. 

And then I’ll ask people, what makes a good home remodeler? And they’ll say things like they turn up they do good quality work. They listen and they communicate well, they, take suggestions and they stand behind their work and things like that. So I’ll write down these two piles of adjectives, and I’ll ask, which pile of adjectives are you evaluated based upon? These listening and turning up and delivering things or the thing that we built gets used and people like it, and it solves a problem. 

In an agile context, I find that most agile teams focused on that second pack of adjectives. The choice about what to build isn’t theirs. It’s a business stakeholder. It’s a customer, it’s somebody else. And in most agile processes, when we stop and reflect, we look at what we built and we say, that was good work. The quality was good. We finished what we said we would on time. It meets our definition of done, but none of those things have anything to do with product success.

A successful product is something that gets used. The value comes from using it every day and enjoying it and having it solve a problem. 

So when I reread the Agile Manifesto phrases like, customer collaboration over contract negotiation. That’s exactly the kind of thing someone would write if they were a home improvement person who writes a contract with a customer to get something built for them. When you see agile principles, like our highest priority is to satisfy the customer through early and continuous delivery of valuable software. I could scratch that out and write valuable landscaping or valuable auto repair or valuable plumbing or anything else that’s a service business. But when I ask people what they love about a product, nobody says they deliver more features faster than other products. That’s not what makes a product valuable. That’s what makes a service business valuable. And if you hire somebody and pay them to write software for you, those are exactly the kind of value statements I wanna hear.

If I hired somebody to write software, I’d want them to collaborate with me and not going to contract negotiation. If I hire somebody to build software I’d want them to focus on early and continuous delivery. I’d want them to focus on working software as a primary measure of progress.

But hey, if you are a business and you’re building products and you’re trying to make money, your primary measure of progress are the number of customers using your product and loving it and paying you money. That’s progress for a business not working software. So there’s a big difference in my head between product thinking and agile thinking. Now, Agile’s an important foundation, but there’s some important principles missing for me. 

Murray: I agree with you. Agile’s clearly been developed by a group of software development consultants and it has an order taking mindset. It assumes the business and technical people will work together on a daily basis because the business people will tell us what to do and we are gonna do it. 

Jeff: Yeah. One of the core XP principles was customer on site. My role when I first started in an agile process was customer. And that freaked me out. It bothered me because I came from a product world. I worked with a team my job title was product manager, but they kept referring to me as the XP customer.

And I kept trying to explain to them, look, I will not buy this product. I won’t use this product. If I’m happy with this product, it isn’t gonna make our company any more money. The people who really are our customers are outside this building. They’re the people who really choose and use the product. I’m not the customer. And there’s this weird, mistaken identity in a lot of organizations where we mistake our business stakeholders for the customers. 

Murray: One of the most interesting thing I’ve seen happening recently is from people like Theresa Torres and others who say, every single week we should be meeting with three real customers and just showing them whatever we’ve got, talking to them about whatever we’re working on or whatever we’re thinking. 

Jeff: Yeah. I can almost guarantee the one thing that she does not say is let the customers prioritize the backlog, or let the customers decide what we’re going to build next. Because those customers, while they may be the ones that choose your product and use it and get value out of it, those customers aren’t accountable for your business’ success. That’s not their concern and don’t make it theirs.

One of the hardest choices we make from a product perspective isn’t what features go into our product. It’s what customers we’re gonna choose to satisfy and what customers we’re gonna not worry about. That’s the heart of product strategy is choosing the customers you want to help. And sadly, the customers we’re gonna choose are the ones that represent big groups of people with big problems we can solve and lots of money. 

Murray: Well, let me ask you another big question. How do we decide what to build? 

Jeff: The dirty secret most companies have is they didn’t actually deliberately decide what to build. Most founders who start a company do so because they have deep understanding and experience with a problem, and they launch a business to solve that problem. The founders of organization, they didn’t decide they felt the pain. They built a product company and solved that problem. Now the problem starts when you’re trying to grow past that. 

Once you’ve moved past the deep empathy and understanding a founder has, and you’re trying to grow a business, now you need to start solving problems for other people that aren’t like you.

You don’t grow a company by paying attention to the customers you have. You grow a company by paying attention to the customers you don’t. The people who don’t want your product, decided not to use it gave up on it because if you can figure out what their problems are and their unmet needs are and solve their problems, that’s how you grow. So how do you figure out what to build? Start by figuring out who you wanna focus on, and then you build some deep understanding and empathy for their problems, and then you find solutions to their problems. 

Shane: I went to a startup thing the other day and one of the founders of a startup that was insanely successful said, we had an idea. And we failed. And then something seemed to work. So we revised our idea and then we failed. And then, that experimentation got them to somewhere where they were successful. 

Jeff: The seed for that idea probably came also from the founders. Some personal insight, some deeper understanding of a problem. But they were self-referential. They understood the problem from their perspective, and so the only way to succeed was to get out and, understand it from somebody else’s perspective. You can expedite that process a little bit by building deeper understanding and empathy with those customers. But one of the things you get used to from a product perspective is we are wrong a lot.

You gotta get used to failing. 90% of startups fail. Most features we put into products don’t get used. You have to get used to failure a lot. You have to get used to trying and failing. And people gloss over that, but that idea that I was smart and I got it right, it’s more of a signal of naivety. And you especially see that in large corporations people still labor under the false belief that they can get it right the first time. And also under the false belief that getting it wrong the first time is a failure. I think some people have heard that old quote I never lose. I either win or learn and you’ve gotta build that learning habit. 

Murray: Can you tell the story of how you helped Gary Levitt? 

Jeff: Gary was a musician and he wanted to build a product that would help musicians market their bands. Called it a music industry marketing interface, or Mimi for short. He had a big vision, a big idea, and he hired Ruby on Rails team that was using Agile development. And they said, Hey let’s build a backlog and let’s start building things highest priority feature first. And they spent weeks building things, then months building things and things were getting built.

And Gary kept saying, this is good. You’re building things, but wow, this software development stuff takes longer than I thought how long before we’re done? And then the Agile person tried to explain to him that hey everything we built here is potentially shippable. You could ship any time and we could be done anytime you want. And Gary’s saying no, it’s not done. I got this big vision. It’s not gonna be ready until we get all this stuff done. It’s not really a useful tool for anybody. Yeah. And after getting super frustrated the person he was working with said, you really gotta talk to jeff. And I sat down with Gary and I said, okay, let’s talk about your vision. Tell me a story about what the big vision is, who this is for. Let’s talk about the people it’s for. Now, let’s start to focus a little bit here.

Murray: So then you helped him to focus on one particular customer and develop a map of what he wanted to do. So can we talk about this mapping process?

Jeff: So one of the fundamental models that I talk about in the story mapping book is the difference between output, outcome, and impact . Where output is what you build. Outcome is what your customers and users do and impact is the business benefit you get as a consequence. Return on investment, that’s an impact using the product that’s an outcome. And the product itself, that’s the output. Now what building a story map does when you do it right is to force you to think in outcomes. It forces you to tell a story about what your users will do after the product is released. They will do this then this, and what you’re doing with that story map is telling a story. I’ll tell a story beginning to end of what like in Gary’s case, what a band manager would do to promote a gig. and, then the story continued into what people would do to receive a message and respond to it and signal they were gonna attend and things like that.

Using a story map well forces you to think in terms of outcomes and value, where one is customer and user value and one is business value. It forces the discussion there. In early days when people would see a story map, they would say, jeff, that’s just a feature decomposition.

I go no, that’s not a feature decomposition. A feature decomposition is more mechanical. If I were to do a feature decomp, I might say, okay, I’ve got a product and that’s a car and I’m gonna decompose it into engine transmission brakes. Those are different components. That’s different than telling a story about driving to work. Now I can use storytelling as a way to decompose software because software is closely wired to use. If I were to take feature decomposition to a hammer, I would break the hammer down into the handle and that metal head, I could break the head of the hammer down into the flat part that hammers and nails and the claw part that pulls up nails. But that’s different than telling the story of hammering in a nail. Hold the nail in your left hand. Hold the hammer in your right hand unless you’re left-handed, and then strike the nail with the hammer. Avoid your thumb. If the nail gets knocked over, twisted over to the claw part and use the claw part to pull up the nail. 

Murray: That sounds quite a bit like a customer journey 

Jeff: Yeah. It is a customer journey. Oftentimes people use the term journey map to describe customers journeys today. Here’s what customers do today, and here’s where they have challenges and problems. People have been using that term for a long time. 

Murray: Okay, so at the top level you’ve got the journey map. Then under each step in the journey you brainstorm all of the things that you want the customer do or things that you wanna build, or both? 

Jeff: Yes. Sometimes nouns get really close to verbs. And so sometimes, when you write sign up for a service, that’s the verb. But then the sign up form is the noun that’s underneath it. So when you get close to the, edge, the things you’re saying people do start to more directly point to the ideas that you have in the product.

Murray: I did a class with Alistair Coburn about 10 years ago and we talked about the walking skeleton. Can you talk to us about that? What is that? 

Jeff: One of the things I’ll draw a distinction from is the difference between a release strategy and a development strategy. 

What we’re trying to find is a smallest successful release. The least I could release that people could use and find really useful. That’s what we did with Gary, is we worked on that big map and we found a smallest successful release. Now, when I’m gonna start to build this thing a piece at a time, I wanna see it get up and walking, and so I’m gonna build the least I can. To see it working end to end. That’s the thinnest slice that allows me to go through that whole story left to right, end to end. But it’s a skeleton. Doesn’t have any meat on the bones. It’s just enough to see it work, just enough to force you to get the architecture built and up and running just enough to force you to build a lot of the Code that’s behind things, but it’s not fully featured. If you release it as a product, people would go, what the heck is this? It hardly does anything at all. 

It’s a skeleton. It’s not delightful. It’s not easy to use. It’s not fun. It’s barely solving one problem and not very well, and that’s what a walking skeleton is. Once you’ve decided what goes in a release, then you can start to say, okay, what’s the thinnest slice I could build to see this thing running, and then how could I start to build it up from there? 

Murray: So that’s all about reducing risk by having some thread all the way through that you can see is 

Jeff: it’s, Alistair would call that a walking skeleton, but sometimes there’s a distinction between a functional walking skeleton versus an architectural walking skeleton, which forces you to stitch all the architecture together. It’s different than allowing users to achieve something functionally end to end, but other terms like tracer, bullet and steel thread. A story map gives you a canvas to think that through.

Murray: So then you’ve done your steel thread or your walking skeleton. So then the next version, that’s just adding more functionality to it, is it? 

Jeff: In the story mapping book, I use this Mona Lisa metaphor. If you are a painter, the first thing you might do is a pencil sketch that shows what you intend to paint. That’s a walking skeleton. It’s not even a painting yet, it’s just enough to see the shape of it and know where the positions of everything are. I can’t ship it. I can’t deliver it. But if we could add some paint to that, it’s gonna be a lot better. So the next layer of paint isn’t a perfect upper left hand corner. Rather the next layer of paint is layering in broad brush strokes form, shape things like that. and the last layer of paint is layering in refinement. So that’s what I’ll ask people to do. The walking skeleton, that’s just the end to end. It’s rough. I can see it work. The next layer it’s adding form, it’s adding shape, and the last layer is adding refinement.

Shane: So the other one that’s often used is the skateboard to car concept. Start with one thing and end up with another and the mon Lisa seems to say you know what it is and you’re just iterating within the boundaries to make it better. What’s your view on those two? Are they polar opposites? 

Jeff: One is a release strategy and one is a development strategy. That’s where the Mona Lisa fits in. I know I want a painting here and I want a way to make sure that painting comes out as high quality as it can be. So I wanna sketch it in, I wanna understand the shape and, I wanna add form and things like that.

But that skateboard to scooter thing, that’s where you say I don’t know exactly what, I need here. I know, I need a transportation device. So let’s build and release a good skateboard. And when people evaluate it, they say that is a great skateboard, but really if I’m trying to commute miles to work, that is insufficient. It’s not a great transportation device, but I learned that from trying that awesome skateboard you just made. I just didn’t need a skateboard. I needed a scooter. I needed a bicycle. I needed a motorcycle. I needed an actual car. Those are two different strategies. You don’t release a skateboard to someone who needs a car. If you know they need a car and you give them a really awesome skateboard and say, is that okay? No, it’s not okay. Of course it’s not okay. You release that skateboard in order to try and get at, is this sufficient? Does this solve the problem? But if you know, a skateboard is not gonna solve the problem and you release to somebody is skateboard, that’s just stupid. 

Murray: Yeah, so you’ve done your customer journey on the top. You’ve got all of these verbs about things that you’re gonna do, which is breaking it down. You’ve done your walking skeleton, then you’ve done your enhancement, then you’ve done something potentially releasable like an mvp. 

Jeff: Yeah. The two terms I like are smallest successful release, and then some people use MVP to mean a test. So once you found the smallest successful release, that’s what we’re shooting for.

Murray: All right. So Gary’s done this process with you for his music app, and then the obvious question is, how much is it gonna cost? Cause I only have a certain amount of money, so what can I afford and how do I keep this on track so that I can deliver something that I can sell with the amount of money I’ve got? So how do you estimate and manage that? 

Jeff: You build a map that lets people looking at the product, see the big picture. They’re not estimating one backlog at a time. They’re seeing the big picture. They can estimate things in context, and that’s what happened . Now, I don’t like the term estimate. One of the concepts I like to use when I’m working with big things is budgeting. 

If you were gonna remodel your kitchen, would you design a perfect kitchen and then go get an estimate on it, or would you decide on your budget? And then work with someone that can come up with the best possible kitchen design that fits within your budget. Now, what most software people do is they design the perfect thing and ask for an estimate on it, and then they get depressed and sad and start cutting corners.

What really happened is Gary did a little bit of both, got estimates looked at budgets ran into a lot of technical complications. Things were a lot harder than he thought they were gonna be for the engineers building it was a lot harder than they thought it was gonna be. And then Gary went out to find more money. One thing he didn’t do is cut scope. 

One of the things you use a story map for is you identify a smallest successful release. If you decide what a smallest successful release is, anything less than a smallest successful release is called an unsuccessful release and that’s not so useful.

Having a map lets people see the big picture. Sometimes we use budget thinking and we talk about, , what can I get for this budget. And, where can we pull things out? The way gary got to a smallest successful release is by drastically reducing the number of people he supported and the number of kinds of problems he supported. His original intention was to create something that allowed professional musicians to promote their bands, and what he ended up with was a very simple email promoting tool. He took on just one problem for one person. So that’s the way you reduce scope. It’s not by pulling out features, but by reducing the number of people you focus on and reducing the number of problems you’re gonna solve for those people. 

Murray: In your book you describe how you identified all of the things he wanted to do. I hesitate to say requirements. 

Jeff: Yeah, my old friend, mentor colleague is Alistair Coburn, and he used to say requirement’s just another name for a decision. If it’s your decision to make, it’s called design. If it’s not your decision to make, it’s called a requirement. So calling something a requirement means shut up and do what you’re told. You don’t need to know why it’s a requirement. 

Murray: I had a recent experience with the team I was helping where the digital people were keen to talk about the product. But then the IT management took over and their objective was to shut down conversation on everything to narrow everything, limit everything. Get it all documented and approved and signed off. So when it inevitably didn’t work, they could say you signed off the document. 

Jeff: When I was talking about the difference between what I refer to as a product culture and then the counter to that is, what I refer to as a service culture. A characteristic of that service provider’s posture is, we are not responsible for the outcome. We’re not responsible for whether this product gets used or people like it, or it really solves a problem. The person who asked for it is responsible. And the way we avoid culpability is to agree on requirements. We agree that it , wasn’t our decision to make it was yours. And so we can’t be held culpable that it’s not a good product.

Murray: I find that the process that the traditional service providers use results in bad products because what they try and do is lock down the first idea of the product and the technical architecture. Their process means that you are unable to learn, you are unable to focus on the outcome. 

Jeff: Could you learn if you chose to spend the money to unbuild the product or tear it down and rebuild it another way? 

Murray: They don’t make the ability to learn, quick and easy.

Jeff: Oh no, they don’t make it cheap because they’re not paid for that. They’re paid for building software. 

Murray: Yeah. But Agile makes the cost of change low and quick, supposedly. 

Jeff: Does it? You ever seen that old movie about McDonald’s called the founder? And did you watch them prototyping the kitchen? 

Murray: they chalked out the kitchen in the parking lot?

Jeff: Exactly, they built a prototype. They didn’t build a working kitchen. They built a prototype and they simulated working in that fake kitchen in the parking lot and iterated and changed it. That’s fast. That’s cheap to change. Potentially shippable software that ain’t so cheap to, change. That McDonald’s story would’ve gone very differently if they built a whole working kitchen and then tried it out and it didn’t work and said, okay, now we need you to change the kitchen.

Murray: Yeah, the way that the traditional, software development process works is that, you ask everybody what they want and you put it into a document without any idea about cost at all.

And then you go to a partner and say, how much will this gonna cost? And it’ll be 10 times what you could afford because nobody has ever thought about trade off’s up until that, point. So then you get into this situation where you have to do all of these trade-offs before you engage somebody to build it for you. 

So there’s this interplay between what you want and what you can afford, and feels to me like you can’t actually set a budget up front because you don’t really know what the value for money is. Maybe if I spent a bit more, I’d get something really valuable.

Jeff: You described a couple anti-patterns there. The first anti-pattern is separating decision makers and builders. If you were remodeling your kitchen and somebody told you no, the last thing you wanna do is actually talk to a carpenter. No. I’m just gonna go through home improvement magazines and tear out the pictures of the most sexy kitchens I can find. and stitch all those together. And then I’ll talk to a carpenter. These are all anti-patterns. 

And in the story mapping book, we’ll talk about a product discovery team, we want the people who understand our business. We want people that understand users and how they’re gonna use it And we want people that understand technology and those three people work together. It’s not a handoff or people that understand the business hands something off to people who design the user interface and then they hand something off to the people who estimate it. What we’re trying to do is solve for all three of those things at once. And that means those three people work together. 

I was at a yao conference many years ago and the speaker was this guy from Lego. His products were those three in one sets where we can build three different things. And he talked about his design process and how they tested and play tested things. And he said at one point you know how you come up with a perfect design, but you’ve got a cost target to hit and a perfect design is gonna cost more. And so we have to keep working with the design so it comes in under the cost target. And he looked at the audience of software developers and said, you know how that is, right? And they didn’t. Because in the software world, we just don’t do that. We don’t come to engineers and architects with a cost target, but in the real product world, we do.

Murray: Yeah that’s what we should do. I’m a big fan of doing some story mapping in order to get a ballpark by talking to people who might build it. And then using that ballpark to set a fixed budget for a fixed team of people for a fixed time. And then focusing on delivering as much value as possible within the time and budget envelope available. 

Jeff: Yeah, That’s what’s ideal. But you don’t fix the scope. It’s hard to fix exactly what the scope is, but what went wrong for Gary in an agile environment is not having that big picture. And the team just starting to get to work, building things and hoping that, at some point in time enough would get built to be valuable. Having that big picture story map helps us represent our vision in a story, in a narrative.

Murray: All right. So we’ve talked a lot about planning at the beginning, but what happens during the project or the product development. What are you doing throughout to keep things on track? 

Jeff: The good thing you get out of a good, agile process with a fixed time box, every week or two, you’re forced to predict what you can get done in a week or two weeks. And every week or two you get to see how good you are at predicting. And if you sucked at predicting what you’re doing in the first week or two. Chances are you sucked at predicting all the rest of this stuff and you get a very early warning that you’re gonna be off. And now you’re in a situation where you’ve gotta replan.

Now you replan or get things back on course by stepping back and reevaluating your release strategy. You intended to release to these people and solve all these problems. Clearly we’re not gonna get there. So can we solve fewer problems for fewer people? Identify a smaller successful release. Or is this really our smallest successful release? And do we need to go back and, get more budget and get more time? Or we look at assumptions we’re making and we figure out, where can I cut cost without cutting value. 

Murray: There’s an assumption from what you’re saying, that you have a cross-functional team with a product manager, a designer and developers all working together and talking to real customers. 

Jeff: Yeah. We’ve gotta be able to change all of the things, the functional requirements the user interface design not just the code part. 

Murray: It strikes me that as we are building something, if we are showing real customers things, we could find out that some of our assumptions we use to build our user story map are wrong.

Jeff: True enough. I can show customers things as we’re building them, but I would rather show them things before I built them. We were talking about the McDonald’s kitchen. I’d rather see people pretend to work in a fake kitchen before I started showing them the kitchen. I don’t wanna wait until I have part of the kitchen built for them to figure out it’s wrong. 

What I’m looking at constantly is the cost of learning. Could I have learned this cheaper? And when we build something at production quality and we learn it was the wrong thing to build I feel like we probably could have figured this out faster and simpler than building production quality code.

Murray: We see a range of companies on this spectrum between build it and learn and interview people and learn. Sometimes people go too heavily research focused. On the other hand, people go too heavily into just build it and learn it. We were talking to a a product manager from Amazon the other day and it sounded like they were much more towards the build it and learn end.

Jeff: I’m probably a fan of the build it thing. But here’s the trick. I’ll talk about the difference between build to learn and build to earn. When you’re building to learn, that means I’m going to build something that people can use but not to scale. When you release something to learn, you release it to a very small fraction of users. A few hundred or a few thousand, but releasing to a few thousand people is different than releasing to a few million people.

If I’m going to release to learn, it doesn’t need to scale to millions of people. It doesn’t need to be localized into different languages. It doesn’t need operational support. It doesn’t need marketing. A release to learn should be a fraction of the size of a release to earn. So yeah, of course, release to learn. But not to scale. Nail it before you scale it. You release to learn, you iterate until it’s awesome, and then you scale it. And what people do sometimes is they release it at scale and then they learn. And that takes a long time. And it’s expensive. So that’s a painful way to learn.

Murray: So what is beyond user story mapping? 

Jeff: I see organizations shifting to more of a product-centric culture and a lot of the organizations I’m working with that’s the big shift. We’ve adopted agile development, and now we wanna move forward to product thinking. We wanna stop holding teams accountable for how much they built and releasing on time, and start holding teams accountable for the value they’ve actually created. Start holding teams accountable for the success of what they’ve built. It means leadership starts to push accountability for success down. Instead of leaders decide and teams just do what was already decided. 

When you shift to a product-centric culture, we use OKRs and we set objectives around target outcomes. Not delivering a feature, but actually solving a problem. It changes the way we do work. It puts inbounds things like the release to learn stuff. It puts inbounds building prototypes . If you are accountable for whether something is good and useful and used. You’re gonna have to pull out more strategies and do things differently. So that’s what’s next for me. It’s what I teach now and what I’ve been focusing on is starting to help organizations make that shift from being just agile to being more product-centric. .

Murray: Yeah, I find that digital teams tend to be quite product focused cuz that’s the way they’ve been set up. But IT teams really struggle with this . 

Jeff: Yeah. When we talk about being product centric, what we start doing is erase that separate but equal process where we’ve got one process and way of thinking we use for digital and a different process that we use for IT.

So let’s say we’ve got an IT team and they’re building stuff for internal use in a company that’s used by a call center. We stop holding them responsible for delivering what stakeholders said on time and start holding them responsible for call durations and efficiency and effectiveness metrics. How quickly are call center employees able to learn to do their job? How easy is it for them to solve problems on a call? Are they able to do their jobs effectively? When you hold teams accountable for how effective their users are? That’s product centric. It’s a different way of thinking. Just because the product isn’t revenue generating doesn’t mean it’s not a product.

Murray: Yeah, I agree. A good approach would be to change your success measures for your technology team so that they’re focused on product and outcome usage. 

Yep. We’d better go to the summaries. Shane, what you got?

Shane: All right. You said that agile has never been about product. And then you quantified it around this idea of what makes a good product. And when you ask people, they don’t say it was on time. They don’t say it has a bunch of features. And that’s been one of the themes that’s come through this whole conversation. Around Agile being focused on the delivery of something and product being focused on the outcome achieved by something. 

So if the team’s got told what to build, they’re probably an agile delivery team. And if they’re part of the team deciding what’s been built, they’re probably a product team. Service culture versus product culture. 

And customers aren’t responsible for your business success, so they’ll tell you what their product needs to do, but you need to actually build a product that makes your business successful as much as a product your customers love.

We talked about requirements. And why they’re not a great thing. Actually requirements aren’t requirements are actually a decision. We’re documenting a decision. We’re not documenting a requirement. Story mapping helps us focus on the outcome piece. 

The story map is our idea, our vision. It’s a canvas. It’s the big picture. It’s helping us understand what that is. And it’s focused on business value. We then break it down into the release which is how can we get something in front of them to see whether that has value to them? And then the delivery piece we’re doing a thin slice and we’re proving a bet. 

One of the biggest things I’ve got outta this conversation is the skateboard versus car and Mona Lisa. I can build a good skateboard. And I can test it with a customer and they go, hold on. It’s crap in the rain and I can’t go very far. And then we can go back and build another vehicle. If we know which vehicle we’re building then we go to Mona Lisa, where we just do thin slices. We have a bunch of bets that we have to prove. And so we sketch it and then let’s color it in a bit more and we learnt some stuff. But we have a lot less uncertainty when we’re at that stage. 

Then we jumped onto budget thinking. The idea that actually, we don’t have unlimited budget or money. We tend to use scope as a lever, but what we should do is actually think about the budget we’ve got, use the story map to understand where we think we wanna spend our money. And then, by doing that reduce the problems that haven’t been solved. 

We then moved onto a triad model. So we have three people that work together. Somebody who understands the value our business will get if we build this thing, somebody who understands it’s the customer value. So what will the customer achieve if they use that thing and somebody understands the technology. And by having that triad we can reduce the uncertainty because we have people having the right conversations at the right time.

And then this thing around UX research first or MVP first. And you brought a new lens to it, which is what is the cost of learning? Fully functional MVPs are an expensive way of learning is there other ways we can learn earlier and cheaper. That may not be research projects or pieces of work but where are you gonna learn quicker and cheaper? And then a couple other sound bites that I loved. Build to learn versus build to earn and nail it before you scale it.

So that was me, Murray, what do you got?

Murray: I’ve used user story mapping and I found it very helpful. Before I was using user story mapping I was with a team that were building everything from a backlog. Great technical team, but they’d made everything super complicated and they weren’t getting any releases out because it was too much time spent on building technical components underlying the solution. They hadn’t thought at all about what’s a thin slice I can get out for users to prove this works. What’s the second slice? So this is the trap of backlog thinking.

It’s so much better to think about the customer journey. Who’s the user, what are their jobs to be done? What is the customer journey or the value stream map or the service design. It’s super helpful to say this is what it’s gonna look like from the user’s point of view, and here’s the smallest thing we can do to test that it’s working. I’ve used the argument that, okay, the first thing doesn’t have to be something we’d really release to a lot of people, but it would be really important to have some thin slice in production to prove that we can actually build this thing. Cause the last time we did this, nobody knew it was gonna work until the end when they integrated everything and then nothing worked.

Jeff: Yeah.

Murray: So that is super risky. This is a way of reducing risk and delivering value earlier, and it allows you to learn what works and what doesn’t before you commit too much to big heavy technical infrastructure. It allows you to balance. What’s desirable for the customer with what’s valuable for the business and what’s feasible technically, in a way that makes a lot of sense. And I love maps and visual diagrams. It helps everybody a lot 

Jeff: Story mapping is a really important tool. If you can’t map a story about how someone would use your product. Don’t build it. You’re about to waste a ton of money. Everybody should be able to map their customer’s experience with a product. It forces us to focus on outcomes or what our customers and users are doing. And then having this big visualization helps us to start thinking more holistically about questions like, what’s the least I could deliver to a customer for them to use and really get value? What’s the least I could build in order to prove that this thing is working end to end? How do I sequence a series of releases that give value every single time. That map gives us a canvas in order to answer those really important questions.

Murray: So I do project work quite a bit these days and I bring a product lens to it and I’d like to encourage all of the project people to do that instead of thinking about how can I fix the requirements so I won’t be blamed for not delivering them later? Let’s focus on who are the customers, what are the outcomes we’re trying to achieve for the business and let’s focus on delivering as much value as possible within the time and money we’ve got. 

Jeff, you train a lot of companies I understand. So how can people get in contact with you and what services can they engage you for?

Jeff: I’m at j patton associates.com. I teach a core Scrum product ownership class once a month. But it isn’t really scrum product ownership. It’s story mapping and all the other product thinking stuff we’ve been talking about. It really is a product thinking bootcamp. I do that internally for inside organizations and I do a lot of consulting and coaching to help organizations shift to a more product-centric process. There’s identifying your products and rethinking strategy and goal setting and a lot of other things. So that’s where I’m focused and I’d love to see anybody at a class. That’s what I enjoy doing is talking and drawing pictures.

Murray: That’s great. All right. Thanks Jeff for coming on. 

Jeff: Thank you.

Murray: That was the no-nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d help to create high value digital products and services, contactMurray@evolve.co. That’s evolve with a zero. Thanks. For listening.