#0084 - Jeff Patton - Product thinking and user story mapping

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode we speak to Jeff Pattitt about product thinking and user story mapping. Jeff emphasizes that product thinking focuses on outcomes, not output. He explains that product market fit requires a deep understanding of customers and users problems while balancing customer desirability, business value and technical feasibility. We discuss how to build a user story map and develop a release plan that reduces your risk and delivers as much value as possible within the time and budget available. Jeff discusses the limitations of requirements and the value of prototyping. He suggests that IT teams should focus on delivering user outcomes rather than delivering requirements. Tune in for insights on how to use user story mapping to deliver great products.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

And I'm Geoff Patton.

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?

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 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 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 from a product perspective. Now all that said, like a lot of people that are old, I've done every possible role and I actually, after the startup I worked 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 that. 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 a big part of my toolkit.

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

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.

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

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 it was a lot more tolerant 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 wrong way.

You mainly worked in the product space. So is there a difference between Agile and product, or has Agile always been about product?

Agile's never been about product. Well, when you think of a great product, what makes it great? Give me a couple things.

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

It's easier. It's better than alternatives. Shane, you want to add anything to that?

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.

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 the 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 customer or 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. And 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 want to hear. If I hired somebody to write software, I'd want them to collaborate with me and not go into contract negotiation. If I hire somebody, build software, I want them to focus on early and continuous delivery. I 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. So. 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.

I agree with you. Agile's clearly being 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 that business people will tell us what to do and we're going to do it.

Yeah. One of the core XP principles was customer on site. My role when I first started in a natural 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 going to 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.

One of the most interesting thing I've seen happening recently is from people like Teresa 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.

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's 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 going to choose to satisfy and what customers we're going to not worry about. That's the heart of product strategy, is choosing the customers you want to help. And sadly, the customers we're going to choose are the ones that represent big groups of people with big problems we can solve and lots of money.

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

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. But 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 who aren't like you. So 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? You start by figuring out who you want to focus on and then you build some deep understanding and empathy for their problems. Then you find solutions to their problems.

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 the experimentation got them to somewhere where they were successful.

A 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 that 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 got to build that learning habit.

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

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 a 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 I 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 anytime and it could be done anytime you want. And Gary's saying, no, it's not done. I got this big vision. It's not going to be ready until we get all this stuff done. It's not really a useful tool for anybody. And after getting super frustrated, the person he was working with said, you really got to 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. Talk about the people it's for. Now let's start to focus a little bit here.

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?

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 as an outcome and the product itself as the output. Now, what building a story map does, when you do it right is to force you to think in outcomes. 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 a 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. Then the story continued into people would do to receive a message and respond to it and signal they were going to 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. 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 not the car, and I'm going to 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 it 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 clunk part that pulls up nails. 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 handed, and strike a nail with the hammer. Avoid your thumb. If the nail gets knocked over, twist it over to the claw part and use the claw part to pull up the nail.

That sounds quite a bit like a customer journey.

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.

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 to do or things that you want to build, or both.

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.

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?

Yeah, 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 small successful release. Now, when I'm going to start to build this thing a piece at a time, I want to see it get up and walking. And so I'm going to 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, 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. 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?

So that's all about reducing risk by having some thread all the way through. You can see his work.

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.

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, isn't it?

In the story mapping book, I use this Mona Lisa metaphor. If you're 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, can't deliver it, but if we can add some paint to that, it's going to 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 brushstrokes, form, shape, things like that. And the last layer of paint is laying 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.

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 Mona 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?

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 want to sketch it in. I want to understand the shape that I want to add form, 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 going to solve the problem and you release to somebody a skateboard, that's just stupid.

Yeah. So you've done your customer journey on the top. You've got all of these verbs about things that you're going to 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.

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

All right, so Gary's done this process with you for his music app, and then the obvious question is, how much is it going to cost? Because 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?

Yeah, 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 estimates. One of the concepts I like to use when I'm working with big things is budgeting. If you were going to 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 going to be. For the engineers building it, it was a lot harder than they thought it was going to 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 smaller 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. It 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 going to solve for those people.

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

Yeah. My old friend, mentor, colleague is Alistair Coburn, and they used to say requirements. 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.

I had a recent experience with a 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.

When I was talking about the difference between what I refer to As a product culture. And then counter to that is what I refer to as a service culture. The 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.

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're unable to learn, you're unable to focus on the outcome.

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

They don't make the ability to learn quick and easy.

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

Yeah, but Agile makes the cost of change low and quick, supposedly does it.

You ever seen that old movie about McDonald's called A Founder and did you watch them prototyping the kitchen?

They chalked out the kitchen in the parking lot.

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. Now that McDonald's story would have 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.

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 costs 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 offs 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 it 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.

You describe 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 the last thing you want to do is actually talk to a carpenter. No, I'm just going to 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 in the story mapping book. I'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 going to use it and we want people that understand technology. And those three people work together. It's not a handoff where people that understand the business hand something off to people who design the user interface and then they hand something off to the people who estimated that. 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 product were those three in one sets where he 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 going to 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.

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.

Yeah, that's what's ideal. Which 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.

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?

The good thing you get out of a good Advil 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 going to be off. And now you're in a situation where you've got to replan. Now you replan or get things back on course by stepping back and re evaluating your release strategy. You intended to release to these people and solve all these problems. Clearly we're not going to 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?

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.

Yeah, we've got to be able to change all of the things, the functional requirements, the user interface design, not just the code part.

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

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 want to 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.

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 product manager from Amazon the other day and it sounded like they were much more towards the build it and learn.

And 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. 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.

So what is beyond user story mapping?

I see organizations shifting to more of a product centric culture in a lot of the organizations I'm working with, that's the big shift. We've adopted agile development and now we want to move forward to product thinking. We want to 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. That 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. 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 going to 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.

Yeah. I find that digital teams tend to be quite product focused because that's the way they've been set up. But IT teams really struggle with this.

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 duration 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. And it's a different way of thinking. Just because the product isn't revenue generating doesn't mean it's not a product.

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 better go to summaries. Shane, what you got?

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 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, they're 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 bit. One of the biggest things I got out of this conversation is the skateboard versus car and Mona Lisa. I can build a good skateboard and I can test it with the 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 print. And so we get you and then let's color it in a bit more and we learn some stuff. We have a lot less uncertainty when we're at that stage. Then we jumped on to 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 want to spend our money and then by doing that, reduce the problems that haven't been sold. We then moved on to a triad model. So we had three people that work together. Somebody who understands the value our business will get if we build this thing. Somebody who understands 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 going to 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?

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 of it 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 going to look like from the user's point of view. And here's the smallest thing we can do to test that it's working. And 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. Because last time we did this, nobody knew what was going to work until the end when they integrated everything and then nothing worked.

Yeah.

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 and helps everybody a lot.

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 hub 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 valuable? 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?

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 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?

I'm@jpattonassociates.com I teach a course 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 taught here. 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. 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.

That's great. All right. Thanks, Jeff, for coming on.

Thank you.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd helped create high value digital products and services, contact Murray at Evolve Co. That's Evolve with a zero. Thanks for listening.