Lean UX Is DEAD! (with Jeff Gothelf)

In this week’s Product Agility Podcast, we’re joined by Jeff Gothelf, author, speaker, and product discovery expert, to explore the evolution of Lean UX and why it’s no longer just about UX. Jeff shares how the Lean Product Canvas has shifted the way teams collaborate, align on business problems, and focus on outcomes over outputs.

With decades of experience in UX, product management, and agile coaching, Jeff reveals why so many teams get stuck in feature factories and how a problem-solving mindset can unlock better products, stronger teams, and more customer impact.

Key Takeaways:

• Why Lean UX is "dead"—and what’s replacing it.
• The Lean Product Canvas—A practical framework for product discovery and decision-making.
• Outcomes over outputs—How to move beyond feature delivery and focus on real business impact.
• Product vs. Agile Mindset—Why agile teams need stronger product thinking.
• The risk of blindly building AI products—How to avoid the latest hype cycle trap.

Practical Insights:

• From UX to cross-functional collaboration: Why this shift matters for teams.
• How Scrum Masters and Agile Coaches can apply Lean Product principles.
• Avoiding waste: How teams can save millions by validating ideas early.
• Using OKRs effectively: How Lean Product discovery naturally aligns with outcome-driven goals.

Quotable Moment:
"You don’t succeed just by delivering features—you succeed when customer behaviour changes."

Links & Resources:
📖 Read Jeff’s latest book: "Who Does What by How Much" - https://www.amazon.co.uk/Who-Does-What-Much-Customer-Centric-ebook/dp/B0CYDH8R71
📚 Explore the Lean Product Canvas: https://jeffgothelf.com/blog/the-lean-product-canvas/
🌐 Learn more about Jeff’s work: https://www.senseandrespond.co/

Are you still focused on feature delivery? Tune in now and let us know how your team defines success! 🚀

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility

Listen & Share On Spotify & iTunes

• Spotify - https://open.spotify.com/show/0lkwAYJzVSuk5zfJ1vIDZq?si=4c691fb12f124a56
• iTunes - https://apple.co/3YvTX8p

Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Transcript

0:00

And I think that's partially where that mindset shift is a lot about solving problems versus delivering features is delivering features. There's, you know, there's no question, there's no questioning of the directive build me, build me a mobile app, OK, We built the mobile app, whatever it is, right? But solving a problem, it's like, hey, make the mobile channel more profitable, OK, Because or, or make it easier for folks to buy our furniture using their mobile devices, OK, Now we're solving a real problem for those folks. Welcome to the Product Agility Podcast, the missing link between Agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. We are joined by a returning guest. Previously he was here with Daniel Turkle's North. I was going to say previously he was overshadowed by Daniel Turkle for that would be unfair because it was a great episode and we all loved that. We do. Yeah. But now I get some one-on-one time with the man the legend Jeff got health author of many books, including the popular lean UX book. Now on its third revision. Is it third edition correctamundo. Yes, third edition. And what we're here to talk about over the next 30 to 45 minutes is lean UX and lean product discovery. And as a someone's been of a certified trainer program with sensor response learning for the last 6 or so months, yeah, I've had a great insight into what I thought was just a canvas. Is that actually a really in depth, really valuable workshop which Jeff and Josh are running for many years around the completion of the Leaning Works Canvas. And so we're here to learn more about that and to go delve deep into what some of the differences are and how things are evolving and to understand how can teams, agile or otherwise, work together to really focus on outcomes over outputs. Now, in case some of you have been living under a rock and you haven't heard of Jeff before, Jeff, would you mind giving a short overview of your many accomplishments? Sure. I, I, I was telling some friends this weekend about my first real job actually, and my first, like, as far as like my first paid gig out of university, and that was with the circus. So I worked in the circus for six months touring around the United States. So that's something that is something. What did you do in the circus? I was my running joke is that I was the bearded lady because I actually had hair back then. And if you saw photos of me back then, you could, you could, you could, it's plausible, let's put it that way. Unlike today, it's plausible. But I was the sound and lighting technician. I thought I was going to go into like audio production and and live sound. That was that was kind of my thing. And and then the circus freed me of that. Well, I mean, it was it was, it was special. I spent six months on the road and I saw the show 400 times in a row because we didn't get a day off. And we worked, you know, multiple shows a day. And so it was special. Yeah. But other than that. And then, yeah. And then and then I was like, OK, I should really get AI, should get an education. These days I work as a, as a coach and a trainer and a speaker on the topics of objectives and key results, product management, product discovery and lean, lean UX. To that extent, like my background is UX design and product management. I've LED teams both in house and consulting teams. I've built a couple of businesses. I've got a little bit of entrepreneurial experience. And what was interesting is when I was tasked with leading a design team in New York City about 15 years ago, 19 years ago, I think. Wait, wait, wait, wait, 2817. Sorry. 17 years ago, I had to figure out how to get the design team to work successfully with the agile engineering teams. The engineering team was starting to work in a more agile fashion. I had to figure out to get my design team to work that way. And there were no good answers back then. And so we tried our own variety of experiment, experiments and iterations. And I was lucky enough to have a boss, a patient boss, who gave me a lot of cycles to try this. There was a big community of folks both in New York and across the US and across the world who was working on the same problem. And we wish we were sharing notes about all of this. And we found an answer. And that answer became Lean UX. The, the that we called it Lean UX because I was the head of the UX team and we were trying to figure out how to make UX design work more effectively with Azure development and Lean startup was really big. And so Lean UX felt like the right term for that. And as you mentioned at the beginning, that became the book Lean UX. And then there have been several books since then sent and respond and more recently, who does what by how much about OK, Rs. But the Lean UX book has evolved into its third edition and it's a fundamentally different book in its third edition. And it wasn't its first book. Whereas I, I would argue that lean UX was the right title for the 1st edition of the book for the third edition, It's it's a much broader approach to cross functional collaborative product development, right, customer centric product development. And so that's, and and that's been the foundation of the work that I've done along with Josh Sidon together over the years. And these days we, like I said, we, we teach workshops, we give keynotes, we do coaching master classes and all that kind of stuff. Thank you. I just make some notes as you were talking there because I think having run the workshop like you're yours and Josh's workshop a couple of Times Now, the real interesting thing for me is how much you see teams change their attitude and their focus over the course of even just a day. I think I've had, I've seen people who historically have just delivered out over the course of two days, then all their language has shifted to actually whenever we're going to go and talk to the customer and we're going to go and go to test some hypothesis and we're not sure if the hypothesis is the right one. So we're going to go and do some discovery work. And these are teams that, yeah, you can now look at and say that these have all the hallmarks of actually really strong product teams. Whereas prior to that, you know, they would have just called themselves a deaf team. And I think there's a big difference. And it's amazing how, you know how quickly minds can change. And I'm not mistaking changing for change here. But it's amazing with difference that can be how different people can be just after two days of the right exercises in the right frames. I suspect that people know better. I'd like to believe, let's put it that way, that that everybody knows better. I think that people who have genuinely prefer to just make stuff and then ship it and they don't really care if it worked or didn't work. Like they enjoy the process of making it and that's, and that's it. But I think I'd like to believe that the majority of folks know that there is more to product development than just making the product a human at the end of the value chain that's consuming the thing that you're making, that you're trying to help them do something better, faster, more efficiently, more delightfully, what whatever it is. And so it's when you give them that language and then you put that language to work in the process of designing and building a product or a service, it makes it, I think it extracts that innate knowledge. Maybe it wasn't like obvious to them that they knew this, but it's like, oh, yeah, that that makes sense. OK. Of course. Like, like, I know I'm building this thing, but why am I building it? Oh, right. I'm building it because people need to do X, right. So like, it's, I think we, we give them the tools to express what I'd like to believe they already know. Yeah. And, you know, I think that lots of people have learned to be helpless with what they have to do with what's asked of them and what they have to produce. And I think it's always difficult when you're in an environment where there is change, which is being, you know, encouraged or forced upon people and they'll have a desire to push back. But if they conceive that this actually does solve something, which has been annoying them for a long time, they see it is a way out of the constant kind of, I wouldn't even say feature, but just the the lines of code hamster wheel that lots of people seem to be stuck in. I think then, yeah, over time, they'll they'll grab the opportunity of both hands if they're motivated to do so. Yeah. And I think it's actually, it's, it's a rather excellent framework for a facilitated conversation when we look at the canvas. And I think I want to make this really clear at this junction. What we're, if I can make it clear is actually there's a few different things we're talking about. Yes, there's a book Lean UX and then there was the Lean UX Canvas, which is now the Lean product Canvas. And then there is then the workshop, which then the companies, the filling in of said canvas. So how? How does that all come together, Jeff, for for our listeners to understand what's the whole thing here? So look, it lean UX was it is a very practical, tactical book, right? It's not, it's not theoretical, it's not philosophical. It it is, is a very practical book that says, you know, first you do this, then you do this. It's, it's a recipe basically to follow for cross functional collaborative human centric product development. Over the years as we've evolved the teaching of I've been teaching that material since 2008, roughly right. And so you know, the, the teaching has improved and has, has iterated over the years to the point where there was a very specific way that we taught the material. And then the Alex Osterwalder gifted us the business model canvas. And then the whole world went canvas crazy and we couldn't help ourselves. We said, look, but the canvas, but the canvas makes sense, right? The canvas, it's, it's a one sheet conversation facilitation tool, right? That's what it is. And so, and it made sense because we had these kind of eight consistent steps that we were using to build, to teach lean UX. And so the lean UX canvas made sense as a way not only to structure what we were teaching and how we were teaching it, but eventually the, the 3rd edition of the book itself. Now, what's interesting is that there's an issue. And the issue, as I mentioned before, is that the evolution of the material has become deliberately more cross functional and broader in scope than just UX. But because we were, you were coming off of, I mean, more than a decade's worth of historical inertia and success on the back of lean UX, it was really difficult to let that name go. It was a double edged sword, right? And the double edged sword was people knew us and they knew the material as lean UX. Oh, you guys, you're the lean UX guy. Of course, I've, I've read your book, right. That's my job. My, my business card says that the lean UX guy. Yeah, Josh has a matching one as well. Also the lean UX guy is what it says also the other lean UX. But what was interesting is, OK, great, you're the lean UX guy. I'll send my UX folks. Great. Or we don't have UX folks or we already bought training for our UX folks or whatever it is. And and so there was, there was like this, this. The, the, the brand recognition was huge, but it self selected the attendees of the class in a way that rendered the material less effective on the organization as a whole. Because I would get lots of UX people and maybe some product people and, and in reality, these classes are designed for product design and engineering at the very least, working collaboratively on the same thing at the same time. And so last year we, we finally sort of got the nerve honestly, because it's, it's, you know, it's risky. It's risky to give up 1516 years of, of, of historical momentum and brand building. And, and we changed the name to the lean product canvas. We changed some of the prompts and we added a second kind of pre canvas called the lean strategy canvas that helps lead into that. But the idea was a, a deliberate effort to broaden the audience for this material so that the right, like more of the right people saw this stuff or perhaps recognize that it was also for them. Whereas in the past they were like, As for UX folks, we'll just let them have it type of thing. Yeah. And I've definitely, I've have experienced that in trying to entice people to come along to my course. The UX let part of it was putting people off. But I think this was born from the fact they hadn't read the latest edition of the book or even any editions of right, born from the fact that they had seen, maybe they hadn't even seen the canvas. And if you had seen the canvas said that, well, I'm capable of filling in a canvas. I mean, how hard can it be just to put some post notes on the wall. And I think then it definitely did kind of pre select the audience, as you said there. So by the big question for me, and I'm thinking about the listeners that we have, knowing that there's lots of agile coaches and scrum masters of people from the agile world, like why would a scrum master want to come on their lean product course and outlook? It makes a ton of sense, right? So look, whether an organization calls itself agile or not, whether an organization says they're using Scrum or not, the. We've all been cross pollinated point, right? So there are the foundations of scrum and agility, right? Let's just call it sort of organizational agility. Team agility fit beautifully into this lean product approach for product development. And I think that as a scrum master, if you can understand these and work these ideas into the standard set of, of, of ceremonies and activities that a team takes as they're working through a Sprint, as they're working through iteration planning, right? These, these activities inform all of that and dovetail really nicely into that and are deliberately, explicitly designed to be iterative and to promote continuous learning and continuous improvement, right. We're all, we're all we're doing in the lean product canvas is we are declaring our assumptions about what we believe to be true about the work that we're going that we're about to take on. And then we're coming up with a series of hypotheses about how we might solve for those assumptions. And then it's a matter of build, measure, learn, inspect and adapt sense and respond, right? Call it call it what you think, make check, right. All of these, you know, two to three word phrases, they all promote the same thing, right? Let's build something small. Let's get into the hands of our customers. Let's learn from that feedback and let's iterate and move forward. And it's fundamental to the since the agile manifesto. What I really was surprised that I suppose was how well the the approach that you and Josh have come up with fits into. I think I'd say the the promises of things approaches like Scrum or even large scale Scrum and other frameworks are available. But when I think of teams who really want to focus on outcomes. And I think of an old friend of mine, Buzz Vodder, they they're one of the Co creators of large scale of Scrum. And he was always saying in product backlog refinement, when you look at large scale of scrub in product backlog refinement, you're looking what you're dealing with there is a problem like what's the problem you're solving for the user or customer? You're not talking about the implementation. You're just trying to understand that person's life and why it is that they want to hire your product for the job. And what can you create to enable them to have that, to want to give you that exchange of value? And that was one of, it was so incredibly difficult to nail that down in organizations that I worked in because they weren't oriented towards that type of thinking. And back then, I didn't have a tool which enabled me to help people through the conversation. And now I look at, you know, the way that the workshop runs, you know, so I've been running a couple of Times Now, which I call Lean Product discovery at the moment was the newest workshop, you know, really does help people understand what the problem is and encourage them. And I think this is a really neat thing that is differentiates what you've created to some other workshops out there is the element of getting up the building. I think that actually when you begin to then look at a, a scrum or Kanban or any other type of agile approach, and yes, it's focused on business problem. There's a great, you've got great ways of really defining that. But then giving up a chunk of the course, the workshop to then get people out of the building, talking to potential customers or users either on the street or if they have people internally they can talk to. Actually getting them to talk to those customers and helping them have builders interview techniques is incredibly valuable. And something which I think is quite different. I don't think you you normally didn't really get that in your old school kind of agilely type workshop or course. It was very much the the team was this kind of closed walled garden and you teach the team all the things that you felt that they needed, but the moment they but you never told them to get out of the garden. You never help them get out of the garden. You never work the people outside the garden to help them in time for tea. But it's just this kind of crazy, really short sighted approach to what we really wanted to achieve with our child. You know, it's interesting having had these discussions for years now with agile folks and with scrum folks as well. You know, there is there, there is, there is a need. And, and I've seen it happen particularly in the last, I'd say 5, five to seven years to to take the, the agile material and evolve it from modern realities as well, right? Like no. And I, I mean that in the best, in the best of ways, like, you know, there's this kind of like rule that we've got to have finished work product at the, at the end of the Sprint, right? That's kind of like one of the, the kind of the original scrum rules. Like we've got to finish what whatever we put into the Sprint has to be done at the end of the Sprint. And, you know, UX work doesn't always do that, right. Sometimes research or design or experimentation work will, will, will, will last two sprints. The design work may not be finished in the Sprint, that type of thing. And there was a lot of, a lot of of, you know, grinding of the gears, if you will, in trying to, to force these two things together. And what's happened, I think successfully since then is we've evolved both the way that we do design work, research, experimentation, product management work, etcetera, and software development and Scrum such that these ideas all make sense together. And I know that they do because I've, I've, I've been on teams as a product manager, as a designer that have worked this way and have worked this way successfully. I've, I've worked with teams that have, that have done this and I've done this successfully. But it requires, it requires a few things. It requires an openness to change. It requires actual agility, which is interesting, right? Because the, the learning loops that this work, this lean product work builds into the process is going to reveal the flaws in our thinking. And once those are revealed, we need to do something about those flaws in our thinking. There's got to be some course correction around that. So not only do we have to be comfortable with that as as a product development team, but we also have to work inside an organization that's comfortable with us doing that as well. And I think that's partially where that mindset shift is a lot about solving problems versus delivering features is delivering features. There's, you know, there's no question, there's no questioning of the directive build me, build me a mobile app, OK, we built the mobile app, whatever it is, right? But solving a problem, it's like, hey, make the mobile channel more profitable. OK, because or or make it easier for folks to buy our furniture using their mobile devices. OK, now we're solving a real problem for those folks. How do we do that? Well, maybe it's a different app, maybe it's, you know, I don't know, maybe it's different content in the app, whatever it is, right? But the idea here is that the answer evolves. The product ultimately becomes the variable in all of this. And I think that that that's a think that that's a radical concept for a lot of folks. It is, I think it is. And if not radical, I mean, if not radical, then the fact that there is people that teams that maybe perhaps weren't expected to come to those conclusions are able to come to those conclusions quite quickly or to do the work. A story from a workshop that I ran quite recently where they had spent a long, long time believing that if they just reduced the manual intervention that a particular person had to make, then it would help solve the bigger problem. And this is someone that they speak to on a regular basis. It wasn't until they wrapped up as the hypothesis and then spoke to this person who turned around and said, well, it's like an hour a week. And it was like, really, they're like, he's like, yeah, honestly, it's not, it's not that big a deal. Like if you want to really turn the dial on fixing that thing there, then you have to think of something different because this is, yeah, it'd be lovely. But they left that conversation like, oh, wow, OK, this is a, this is really, really interesting. Like, we never knew that before, you know? And then when it got to, when it got to the end of the workshop, they were saying, well, like visa hub offices, we're going to go and assess them. We're not going to write any code. Actually. We're going to put in conversations and make sure we're going to go interview these people just to understand. I'll be right, I'll be wrong. It's like, well, yeah, you've just saved your company thousands, 10s of thousands of pounds. I mean, because you're not going to develop those things which weren't going to have to affect the business problem as much as the other things you're yet to find out. And I thought that was such an amazing turn around. It was literally, you know, it took these people two days to build their skills to do that. And then like half a day for them to be like, let's own it. You know, it was it was a really lovely thing to observe. It's, you know, it's interesting, all this stuff. Right. Agile, lean startup, lean product canvas, even lean UX. Right. It's risk mitigation. Risk mitigation is an unsexy title. Doesn't sell books that way. Lean UX, Lean risk mitigation. Lean risk mitigation. Yeah. No one's buying that book, right? No one's buying that for their boss, right? But that's what, that's what this is, right? This is about making sure that you're building the right thing and that you ultimately that you're building it the right way, right? I had a client recently. We spent six months coaching them. We started off with, with this workshop and then we spent six months coaching them and they're, they're AB to B to C financial services behemoth, right? And so they're like, we know what people want. We're just going to build it. They had $1,000,000, a $1,000,000 budget allocated to this one initiative. And they came up. We, we, we did this, we did this class. What's the problem that you're solving? Who you solving it for? Why do they care if you succeed? How will their behavior change? What are some of your ideas about how to solve for this? Wrote the hypothesis. And then they mocked up some prototypes, literally mocked them up in PowerPoint and they went and showed it to the client. And they learned through that initial effort, which I think if, if I was to say like total amount of time that that took, let's just say it was a week, like a full, like A1 full time week distributed over, you know, maybe two to three weeks. They learned the client was not interested in this. It wasn't going to solve the problem. It wasn't going to work for them. And they had to pivot significantly off of this original hypothesis, which they had already allocated $1,000,000 for, right? Save the company $1,000,000 in developing a product that nobody wanted, right, for a week's worth of work. And I think some of the hesitation around this way of working, if you've been around a little while, maybe you remember the days where we sat behind those one way mirrors with buckets of candy in the room and you kind of watched user after user after user come through and say the same thing. And you sat there for two days and it cost 15 grand. And you could have, you could have probably finished like midday on day one because nobody said anything new, right? But you already booked the place. I think, I think folks have that perception that this is going to take forever and it's going to slow us down. And, and it doesn't, right? The whole lean aspect of this is designed to do just enough work to move the conversation forward, just one step forward right then to the next Sprint. And, and so it's so compatible with this agile mindset, the Scrum process and and it amplifies it. Right. Like I, I think, I think it, it, it makes it even more powerful as a, as a framework because you're not just delivering things more quickly, but you're learning more quickly. And that's, that's super valuable. I think the podcast is called product agility. And I was reflecting on the podcast over the weekend and I thought, you know, is pro agility a thing? Is it just me trying to talk about product and agility? And yeah, I'm still on the fence. You'd think after this period of time, a year or two of rebranding it, I would have the answer to that, but I haven't. But what I do know is that the doing something like the Lean product Canvas and doing that workshop, it does bridge the gap. And I think that for Scrum masters and agile coaches, it gives them practical tools and ways to have more product like conversations and more UX like conversations. And actually, you know, what the agile community needs right now is a bridge to value because they haven't been valuable enough. And I think that actually that this workshop is, is so chock full of useful tools and approaches and ideas and pithy little sayings that he gives people with nothing to go back and say, well, let's give this a go. Like, sure, I'm talking about, you know, let's talk about business problems. But actually here's a frame for me to say, OK, well, how do you want to articulate a business problem? Like when we're talking about outcomes, we're actually being able to root them in that user behaviour and say, what do we need to see people doing differently, knowing that these outcomes could be your key results for an OK R You know, it's just such a neat shortcut. And I think it's what so many people would need right now. I think it's just a different way to view their work. Look, it's, yeah, it's not heavy. It's not dogmatic. It is there, there. There's almost nothing that we are religious about in the framework. And I say almost simply because I feel like I, I've sorry, my phone's ringing and I got to make, I don't make it stop. You know, I, I say there's almost nothing that we're religious about simply because I, I do believe that your measure of success has to be an outcome and has to be a measure of, of human behavior. That's, that's the only thing that I'm, you know, if I'm using my own language, religious about right. And I think that that's, that's the, that's the, that's the pivot for this whole thing is the mindset shift happens when you recognize that you delivered something of value when people change their behavior. That's the key. So that is, I think and so, so, so it flexes and it fits whatever situation, right? And, and look, I'm not, I, I don't like to speak in absolutes, but I've worked in a lot of different industries over the years that, that I haven't come across a situation yet where it didn't work. I think maybe if you're putting, you know, people on the moon, I don't know how much you want to iterate on that. But generally speaking, you know, I I've not come across and I've done like factory automation systems, I've worked in locomotives, like production, manufacturing, all kinds of stuff. And, and and it works like there's this problem for a human is, you know, if you make them more successful, they're going to change their behavior. You've got ideas. Everyone's got ideas about how to get them there. How do we figure out which one's the best? I think, yeah, it's just you're, you're absolutely right. I think so many different sort of concepts that I've I've worked in or around that would benefit from the framing what you're going to do from the perspective of a business problem. Now, I never kind of have been inching towards kind of the end of our time here. You know, I know that you have you've got things to do as well. I am keen just to pick on a a couple little things here and questions which I know I've been asked in the past. I'd love to hear your response to this. First of all, the Lean Product Canvas and OK Rs. Now I've mentioned it a few times, I don't know if I'm misusing it or how. If they're misusing the canvas, I find it quite easy to have OK Rs kind of just fall out of the process of kind of going through the workshop. What's your official take on the Lean Product Canvas and OK Rs? So the Lean product canvas is like, you can extract OK Rs directly from it, we added. So if you download the the PDF from our website, you'll get the Lean strategy Canvas with it as well. And the Lean strategy Canvas actually has an explicit process step for objectives and key results simply because we believe they should be anchored in strategy. But if you look just at the Lean product canvas, if you even skip that whole step, right, box #2 it's called business outcomes. How will you know you've solved the business problem? What will you measure and, and these are your key results, right? What will people be doing differently if we solve the problem? Box number one is the is the problem itself. And so the key results are already there, or at least the, the foundation for key results already there in, in box #2 which is great. There is. I'm trying to think that you could. If you look at box #4 on the lean product canvas, which is the user outcomes and benefits. And so the question, the prompt question is why would users seek out your product or service? What benefit would they gain from using it? What is their job to be done? What are they trying to do? That type of thing. And it could be something like save money or get a promotion or spend more time with family or do my job more successfully. You can absolutely extract a qualitative objective out of box #4 and make that your, your objective, because the objective is a qualitative statement about a, a future benefit you'd like to create for users, which is basically box 4. And if you do that, their behaviour should change. And we can start to extract those from box #2 So you can absolutely take the, the OK Rs out of the Lean product Canvas as it currently stands today. Yeah. Next question, Lean product canvas and design sprints kind of there is to what design sprints during the workshop, What have you used for the product canvas as part of the design Sprint process or ever seen that like it was, is there any relationship there? Yeah, absolutely. And in fact, I did a workshop once before COVID with Jake Knapp where we did a full day class of this canvas and design sprints and we started with the canvas. We did 1/2 day on the canvas and that was the exercise of really getting all the assumptions out and coming up with a series of hypotheses that then fed into the design Sprint and then using the design Sprint to iterate on the assumptions that you wrote down in the lean product canvas. So it's a great way to kick off a design Sprint. It's a nice, it's a nice cross functional collaborative assumptions declaration exercise and then you can work from it over the course of the week and iterate it as you learn new things. Excellent. So what next for a lean product canvas? Are we going to see the 4th edition of a lean UX book renamed? Will it still be Lean UX? Will we see any more support around completing for Lean strategy canvas? That's a great question. So it's been about once every five years that O'Reilly. Has reached out or we reached out to them and said, hey, let's let's update the book. So this most recent edition came out in 21. So yeah, I guess this would be the year if we're going to reach back out to get it, to get a new version out next year. We haven't talked about it. We just launched who does what by how much. And so we're focusing a lot on that work. So I don't know. I do know that the feedback that we've gotten on the lean product canvas is is very positive. I'd like to see the Lean Strategy Canvas in action a bit more as it's relatively new, the feedback, the fact that we're getting on it again, generally positive, some tweaks here and there. I'd like to put that through its paces over the course of the year, see where that lands and, and make some updates there. But the framework for the Lean product canvas has been in place for a while now. It's solid, it works. I don't, I don't see any major evolution. And I think if we did write, it would be really interesting, I think to, if we did write a 4th edition of Lean UXI would love to, to really to rename it, you know, to be more more broadly to just to just make it seem more broadly applicable, even though it already is. Yeah, actually, I think it's, it's hugely applicable. But I just say everyone's listened to this and they're wondering about it. We'll just go. If you Google the product canvas, you'll come across the blog posts, I think from you, Jeff, I think where you kind of outlined the latest version of the canvas. There's a great video as well, which kind of talks you through the key points of it. It's really worth checking out. I mean, even if you don't know, not interested in attending a workshop with Jeff or myself or someone else, I mean, there's this. It's a great way to facilitate a conversation. And so I do urge people to check out the show notes or just go to Google finally in product Canvas and take a look for it. Surprise yourself actually with what's there and how it can really make a difference to how we how we want to work and really make a difference to your ability to be more credible in whatever role that we're doing. Because I mean, there's some really awesome stuff there and creates that great bridge. As I said, I think between Agile and product, you've got certified training partners for sense of responding across the globe now. So people listen to this and they're not based in say Europe. How how broad is the the partner program at the moment from a geography perspective? Yep. So, so Josh and I have launched Sense and Respond Learning as a training company and the training partners that we have right now or. Are distributed between South America and the Middle East, so fairly broad. We've got a good chunk of folks in the wings waiting to get trained and come on board and, and really just kind of filling out the Americas, the Europe's, India, we've got, we've got a great trainer in India and in Dubai. And so really there's no limit to it. And at the moment we're, we're, we're expanding fairly aggressively. So if, if you want to see a workshop in your part of the world, let us know. If you've, you're an experienced trainer and you want to be a trainer with us, let us know. We'd love to hear from you. Let's take it out everyone reach out to Jeff or if you're interested in coming along to a course in in the UK, then drop me Adm on LinkedIn and we can talk about a special listener discount and it will be a lovely discount. You should definitely drop me alive if you're interested in more about the workshop because it is. It is probably the most fun I've had delivering a workshop for many, many years. So thank you very much for letting me be part of a little of the crowd. Jeff and and Josh, of course, if people want to find out more about you personally, Jeff, LinkedIn is a great place for me to come and connect with you. LinkedIn is great sense and respond.co is great and Jeff got health.com lovely. And and everyone should absolutely also check out The Who does what by how much book as well. I've been getting great feedback from my clients actually on how good that book is. So you did a fantastic job with that and a fantastic job explaining the lean product canvas and the the evolution from lean UX Jeff, thank you very much for spending the time with me today and coming on the podcast. Before we wrap up, is there anything else you think we should share? I mean, look, I think there's a lot, there's a lot to be learned. I think particularly today, I think where like the the latest shiny thing is AI, this work that is not heavy and very deliberate is a great way to temper the misapplication of AI, right? Because I'm sure all of you are in a position where it's like, add some AI to it, make it great, right? I think this is a tremendous opportunity to be like, what problem are we solving? And can AI make it better? And maybe it can, right? But let's not just say we, we, we deployed AI and it's a success. We deployed we in AI in such a way that folks are now doing X better and Y better and Z better. So I think that that to me that's that's a kind of just make this super, super current, you know, this is a nice way to kind of temper that the exuberance over AI in a way that may actually benefit your customers. May actually benefit the customers, not in a Yeah, these early attempts to integrate AI into things which just utterly pointless. Yeah. Brilliant. Thank you very much for that, Jeff and everyone. Thank you very much for listening. We'll be back again next Thursday with another guest. Just who that will be. Do you know what I don't know. We're still keeping the episodes really nice and close to the release date, so we'll see what comes up, but guaranteed there will be another episode. So everyone, thank you very much for tuning in. Please feel free to drop Jeff or myself a note on LinkedIn or somewhere else if you want to learn more about the Canvas or the workshops. That being said, have a great rest of your day and we'll speak to you again next week.