Jeff Patton: AI Doesn't Change Product Management Fundamentals

People who use AI well use AI like a super suit, like Iron Man. It's just Tony in that suit, but he can fly and shoot things out of the sky and has super strength, but it's still a person in that suit. When I see people using it right, they do use story maps for what they're intended for, which is understanding that solution, thinking through the outcome before it comes out, and then breaking it down into options. What's in our release to learn? What can we leave out of it if we're doing that minimum lovable product? Hello, and welcome to One Night's In Product, a show where I chat to some of the brightest minds in and around product from across the globe to help you see product management in a whole new light. If that sounds like Mule Street, don't forget to dive into the back catalog on your favorite podcast app or on YouTube, and of course, follow, share, or drop me a comment or review. If you're a founder, executive, or product leader, who'd like help with product strategy, leadership, or capability, I work with product companies as a fractional leader, consultant, coach, and trainer. My email's in the show notes, and I'd love to chat about how I can help you. On this episode, I'm speaking to Jeff Patton. Jeff's the chief troublemaker at Jeff Patton Associates, who claims to make product thinking practical, profitable, and fun, which, given that he claims to own a haunted pirate house, I'm hoping doesn't involve making people walk the plank. Jeff's the renowned author of User Story Mapping, a book I recommend to everyone about an approach that I recommend to everyone, so I'm hoping if I butter him up enough, I might get a cut of his royalties by the end of this interview. Speaking of butter, Jeff started out as a cook in Salt Lake City, but he's here tonight to give us the recipe for product success with hopefully just the right amount of AI seasoning. Jeff, thanks for coming, and welcome to the show. I am thrilled to be here. I'm working hard to try and match your energy level, Jason. It's all fake. I'm very old. All of the energy is going to be a front, and then at the end of it, I'll just collapse into a pool. I've got my coffee. There you go. I'm going to keep up. I'm going to keep up. It's going to be fine. It's going to be fine. Okay, so before we start, you told me you have a haunted pirate house, so I do have to start by asking what on earth are you talking about? I feel like I'm from the middle of nowhere. I live in Salt Lake City, Utah, which the best thing I've got is it's a Delta hub, so I can have a single flight to Amsterdam and to London and to most places in the US. But there's a long story behind why I got stuck here and kept living here, but I'm tired of it, and I bought a house in Astoria, Oregon. Do you know anything about Astoria, Oregon? No, it's in Oregon. So, yeah, it's in Oregon. It's at the very northwestern tip of Oregon, and one of the most famous thing that Astoria is known for is that's where the movie, The Goonies, was filmed. Hey, there you go. Yeah, so in Goonies, there are still pirate flags flying from many homes in Astoria. It's easy place to buy Goonie stuff, and the house I bought there is four blocks from the ocean, and it is black, and so it looks like a pirate house. We've renamed it the pirate house. We've got a lot of pirate memorabilia in it. There's a picture of Blackbeard above the fireplace, and that house, you can hear walking around in the upstairs and the attic almost anytime the wind blows, and we're sure it's ghosts walking around there. So that's it. That's the haunted pirate house, and it's beautiful. I love it. The ghost of user stories past, but definitely good for your pirate metrics as well. You know, your acquisition. Fair enough. Yeah, exactly. Well, new pirate metrics that I'm going to come up with. New pirate. There you go. Exactly. Yeah. Exactly. Yeah. Well, let's get to business, and of course, I can't have the chance to talk to you about taking that chance to speak a little bit about user story mapping, although obviously, that's been around for a while now. I think the book originally came out something like 12 years ago. So it's almost a teenager on its own. I'm sure you aren't able to dine out on that forever, but in general, what's keeping you busy these days? Like, what are you working on? Well, I should be working on a second edition of story mapping, but it took me so long to get the first edition written. I should be writing more, but I hate it. Where I get called to help organizations and people is organizations that are adopting a product operating model. Organizations that are trying to take product management seriously, and oftentimes, non-traditional organizations. Organizations like banks and insurance companies and not-profits. And we've talked a little bit earlier, governmental organizations. What does it mean to be product-centric when you're not shipping something that's a product? You're not shipping something that people buy. How does that work? I get called in to help with that, help give initial boot-up talks. I teach a lot of product management and coach a lot of product leaders in those organizations. That's what's keeping me busy. I'm not sure if that makes us competitors or friends, but it's obviously... I keep trying to retire because I want to retire to Astoria. I'm waiting in this house for a 16-year-old to graduate high school because she doesn't want to move before then. I get back and forth from there and I'm ready to retire and go clam digging. I'm buying crab traps because I can go four blocks down the hill and throw a crab trap into the water and bring it down to the ends of the raft. That's what I want to do. But in the meantime, there's a lot of companies that still struggle. There are, and I think that the governmental thing... I've worked with banks and we chatted before we started about some of the pros and cons of working with banks, and it's a fascinating world. But governmental just seems like a possible or potential horror show, not just because of the ways that they might be working, more traditional, not quite the product-y organizations that maybe we see in some of the books, but also the fact, and I've actually chatted to government product managers before, about the fact that, for example, every four or five years, depending on your country, everything changes. Your vision, your long-lived vision is completely thrown out the window because the new guy, and it's normally a guy, comes in and replaces that with an entirely different vision. Imagine being a PM for something governmental between Biden and Trump, for example. But whatever your political sensibilities, they're very different. So it kind of feels like... I mean, how do you see that when you do go into governments? Is it very... Do they kind of just sort of sigh and say, well, that's just the way it is? Or do they try and find threads that they can kind of... longer-lived threads that they can kind of still hold on to? When I'm working with government, I'm working with agencies. I mean, I got to boil it down to, I'm always busting it down to back to the basics or back to what matters. You know, the biggest hamstring most governmental organizations have is they still use a product finance, excuse me, a project finance model. They work hard to come up with requirements. They work hard to agree on those requirements. They fund that project and they get to work and they build it and they're done. They never pay attention to whether it worked, whether it achieved what they wanted to. And the annoying thing these days, the annoying thing about the 21st century is products change faster or more continuously than ever. There's no new last version of Microsoft Word. There's no new last version of Spotify and everything we use, we expect it to change continuously. But governmental organizations don't fund things that way. They only fund the big bang. That ends up getting in the way. And yes, leaders take over and they cancel funding for ongoing projects. So that tanks that. But then they go right back to the same mistake and fund a new project to do something new. And rest assured, it's going to take them somewhere between nine months and never to ship anything. Anyway, that's the way it works. Well, keeps paying the bills, I guess. But the problem, talking back to user story mapping, the problem of a 12 year old book, of course, is that it's been 12 years since you wrote it. And I know you're saying maybe it's time to write a new version. But before then, there's all this time for young upstarts to come and write new books or maybe even some new approaches that come out or new sort of theories and things that either support or maybe even try and replace some of the sort of the classic theories and the classic methodologies that maybe came before them. So do you feel that the concept of user story mapping and the kind of the approach that you championed in that book kind of stood the test of time and is still just as relevant today in this kind of 100x agentic AI powered product builder future? Yes, for the most part. It's interesting. The book is evergreen. The book continues to sell even today. If you go to Amazon and type in user story, it's the first title that comes up. But well, who knows, it may come up something different in a different country or somewhere else. It's been translated into lots, tons of different languages. They told me it was translated into Ukrainian and released the month the Ukraine war started. So it's your fault is what we're saying. Well, I just I was thinking you guys should have better. You've got bigger things to worry about right now than learning the story map. So yes, it continues to be evergreen. And it's such a stupid, simple idea that I don't know how you replace it. It's not something I invented. It's not something new. It's just that if you've got an idea for a feature or a capability or a product, just tell me a story about somebody using it. They do this, then this, then this, then this. And then, okay, now let's take this step and let's start breaking it down into pieces. It's such a simple concept. And if you can't tell me a story about how someone will use something you're building, stop building it. That's it. Anyway, it's a simple idea. How do you improve on that? So you've already kind of you've already hit the bullseye. What is there even to write about in the second book? What there is to write about is nobody is sitting in a conference room and putting sticky notes on the wall anymore. We're all using story mapping now. Yeah, yes, we're all using... Probably not Miro anymore because that's all been bought and who knows what's going to happen to that. But whatever replaces Miro... Yeah, exactly. Except Claude connects to Miro. So that's so, but we'll go there soon. But yes, people were doing this stuff. We're collaborating using tools like Miro or FigJam or whatever. So that's changed things. And there's still a lot of fundamentals that people just can't quite wrap their head around. I see so many people story mapping by doing a feature decomp. By that, I mean, they have a solution in mind and the story map isn't about what people do with the product. Rather, they are mapping the pieces of the product and breaking those pieces down into more smaller pieces to build. And that's not the same as a story map. So a lot of people don't quite get that idea. And so if there's a new edition, I got to discuss the way we work differently. I've got to discuss the fundamental problems that I keep seeing over and over with people doing this. And of course, we have to talk about how does this work or why is this relevant in an AI world? Well, that's the thing, because, you know, I could probably generate a thousand user story maps using my LLM of choice, right? And it kind of goes back to that point about, you know, that sort of feature decomp that you talked about, for example, like it's going to look a little bit like a user story map and it's going to, you know, you can kind of slice it up and you can kind of take a picture of it and you can sort of use it almost like you would with the user story map. But it's not a user story map because it's not started from the foundations that you talked about. And I guess you could say it would be the same with the AI stuff. Like, again, I can sit there and crank out a bunch of potential user story maps and they'll all look perfectly nice and usable. But I think where you're going with this is that you've actually got to fundamentally work and operate in a different way to you operating before, you know, which kind of feels like, you know, back to fundamentals, right? Kind of the problem of all these different approaches that people champion, OKRs and everything else, it's like people just sort of slap them on top of what wasn't working already and just expect that somehow that magically changes it. And I guess you're going to say that it doesn't. Yeah, new processes, new mental models are often paint jobs over the old model. And that starts to be a problem. And AI can be, if you're using AI, you need to be smarter than the AI. The AI is going to generate a product. And yes, it might look right, but if you can't read it and understand it and evaluate it and then give, tell Claude, no, this isn't right and that's not right. Regenerate, regenerate, regenerate until Claude starts to understand what it's supposed to be. It starts to understand that it is a story about who the user is and what they're doing in the product. And then from that, we will dig down into how does it look and how does it feel. And if you're not, if you don't know how to story map, it's asking Claude to build a story map isn't going to help. It's going to do it wrong. Or asking Claude, asking chat GPT, it's going to do it wrong. And if you don't have the skills to evaluate whether it's right or wrong, same as asking AI to generate the user interface design. It doesn't mean it's going to be good. Maybe it will be, maybe it won't. But like, again, I think it's that point you have to be able to evaluate that. And with something like a user interface, maybe you sit there and say, well, yeah, it kind of looks good to me and I can click it and stuff. But when it's something kind of a bit more in depth, then, you know, actually kind of, you're still missing that thinking that got you there. But you said before this that, and you kind of mentioned already this idea that you're kind of, you're not just a user story map guy now. You're out there trying to almost help people install product operating systems and really bringing it back to basics or fundamentals. And like, on the one hand, you sort of sit there and say, well, basics and fundamentals. First of all, they're kind of, they're not sexy in a way because, you know, they're kind of, they've been around for a while, but at the same time, they're sort of time tested and durable and they should still work. But it also feels like people should kind of know them by now. Like, you know, you've written your books, you know, people like Marty, your friend, Marty, you've written a bunch of books and there's a bunch of all these other different types of books there and books about books and all these different types of ways of, you know, YouTube videos and podcasts and everything to basically sort of map out what they all should be. Kind of feels like everyone should know them by now, but obviously they don't. And I guess I'm curious from your perspective, like, what are they missing? And maybe even why are they missing it still? This is going to be terribly boring. That's fine. That's my entire vibe. It was good. I may not be, have you matched your energy level, but I can outbore you. So one of the things like in a story mapping book, there isn't an introduction. There's a read this first section. And in the read this first section, I draw this model that I have redrawn. I swear every freaking day or at least every week, I draw this output, outcome and impact model where output is what you build, outcome is what people do with it after and impact is how your business benefits. And everybody knows that if they work for a business, they want impact. Impact is the return on investment. It's the profit. It's the reduction in cost. It's the improvement of reputation. And everybody has big backlogs and huge ideas for features and they release all those things. But nobody seems to pay freaking attention to the outcome. And even nobody seems to know even what it is, what I'm helping organizations. Oh, if I had a nickel for every time I went into an organization that says we've got huge backlogs, we need to improve productivity, but then we've got to get these things out and more things there and I can't keep up with our competitors and our board of directors is ticked off because we're not making meeting our revenue targets. How can you help us build more stuff faster? And I'll say, well, who's doing it well? And I'll go talk to the team is doing it well. And let's say, yeah, we've shipped this and this is what I wish we could get more people because we've got so much to do. And then I will ask them, well, tell me about the things you last shipped. How did they do? And I get the slow blink, staring into the eyes of a fish and they don't know. They have no idea if anybody used it. I'll tell people that we measure outcome by saying, did people see it, try it, use it, keep using it and say good things about it, or in pirate metrics lingo, acquisition, activation, retention, referral. Well, however you want to say it, if you want to overcomplicate it with multi-syllabic words, go ahead. But, but they don't know if anybody saw it. They don't know if anybody tried it. They don't know if anybody's using it. They don't know how often it's being used. They don't know if they keep using it or just tried it once and abandoned it. And if you, if they don't use it, it's not going to get you return on investment. It's not gonna increase revenue, reduce costs and organizations just simply don't know. They don't measure that. They don't pay attention to that. Um, and that those ended up being the fundamentals that I keep having to remind people of. And I see people generating tons of new features with AI and shipping new things. And I can ask the same question. Did anybody use it? Uh, the AI is not going to instrument that new feature and put usage. instrument that new feature and put usage metrics in it, unless you ask it to. And if you don't know to ask it to, uh, that's, that's the, that's the first problem, uh, it's the forgetting the fundamentals that, that a lot of organizations do and then operationalizing it, making it part of the way we do things. But these are smart people normally, or, you know, certainly smart in certain domains, so you would sit there and, you know, I'm sure that people be listening to everything you just said, and have been kind of nodding along to some extent saying, yeah, that all makes sense. And yeah, no, we don't do that either. And actually you really wish we could do that. And it's like, well, why don't you try and do it? So again, you're, we're both going into companies that, that maybe aren't doing some of those things. So, you know, we could probably share some war stories over that. The, the point kind of still remains, like, is there some kind of mental block or some kind of other factor that is stopping them just sort of sitting there having that kind of, you know, sort of double take moment and then just be like, Oh, hang on a minute. No, why don't we try doing something different? Because obviously, yeah, by the time they get someone like you or someone like me to come and help them to try and do some of that stuff, they've probably left it a little bit too late. Yeah. Cause they've tried a bunch of other stuff and no one wants to pay for a consultant unless it's really urgent. Right. So you kind of get that person in and, and they do their best, but they knew these problems were there in the first place. So like what's stopping them from trying? Is it literally that they've never done it before and they don't know, or is it something else sort of systemically or institutionally that kind of gets in the way? I've got a big, weird ass hypothesis about why this happens and why this is. All right, let's uh, so everybody be patient with me here. Um, there was an old, uh, neuroscientist person that did experiments, uh, during a police, during the world war two era, uh, whose name is BF Skinner and he, he was working with pigeons. Have you heard of the BF Skinner and the pigeon box? Do you know what I'm talking about? I have not, but I feel compelled to look it up and I'm going to avoid doing that until afterwards. Okay. I'm not Joe Rogan. I don't bring things up on the screen. Yeah. All right. So here's, here's the, you put a pigeon in a box and there was a button on the, in the box and when the pigeon pecks the button, it dispenses food. Uh, and, uh, the pigeons very quickly learn how to peck the button and it dispenses food. And then Skinner gets a little weird with this and he turns it off. So pigeons, when you turn it off and it doesn't dispense food, the pigeon keeps pecking the button. And then it finally gives up. Now here's where things get really weird, uh, is he sets the machine. So it's intermittent. So it's unpredictable. So you peck the button and sometimes it gives you food, but a lot of time it doesn't. And, uh, when it's the, when the reward is intermittent, the pigeons go freaking nuts. They peck harder and faster than ever. Uh, the pigeons even develop little weird habits where if the pigeon spun around and pecked and it worked, the pigeon will start spinning and pecking, spinning and pecking, or bobbing and pecking. Now, uh, this, uh, they call this intermittent reinforcement. Now this is, uh, this is not a pigeon thing. It's a biological thing. And it's in, uh, it's been proven in monkeys and humans and, and it's, this is why we humans sit in Las Vegas in front of a slot machine and keep pulling the handle because, uh, and they may even bob their head, they may wear their lucky socks, uh, uh, this is why people blow on the dice at a crap table. Uh, because this is what works. And when a business releases a new product or a new feature and it works, they think they're awesome. And then they, when they release something and it doesn't work, sometimes it does, and sometimes it doesn't. Sometimes it makes a difference and sometimes it doesn't. They become addicted to trying. Um, there's a, another author, author, uh, that's more current. Uh, Sapolsky is his last name. I forget his first name. Uh, he wrote a book called, uh, Why Zebras Don't Get Ultras. And it explains a lot of, uh, why our, how our brain chemistry works and why we do this thing. But one of the things he explains is that, yeah, you get a dopamine hit when you. Play a game when you pull that slot machine, or I'm going to assert that stakeholders in companies and product managers get a dopamine hit when they. Come up with that feature idea and they build it and they launch it. But what, uh, what Sapolsky shows from monitoring the brains of chimpanzees is you get the dopamine hit when you try, not when you succeed. And that's when it happens, you get addicted to trying. So organizations, uh, keep falling into the trap of try harder, try faster, try more, and they fail, uh, and they peck the target. They don't know what's going on in the machine behind the target. They don't understand the outcome. Uh, but they check their bank balances for the impact and they keep, uh, if there's three phases to this, do something, release something, make something, see what people do with it, and then see how it benefits your organization, they get really used to just doing the two, uh, and just like pigeons that don't know what's going on behind the wall, they start acting like that. And I think we are biologically predisposed to keep trying and kind of biologically, we don't want to, we're not as dumb as pigeons, but we just, we know what the, the, the hard stuff is that we should be doing. So, but you and I both, you can, uh, I'm sure you've got customers who are, or people you've worked with who were wildly successful with something they did, and they don't know why, or it was just as much a surprise to them as it was, uh, they've learned that when I do everything right, I fail. And when I guess sometimes I'm right. Uh, so does that all make sense? My big hypothesis is we, we and organizations, and we've learned that we become addicted to trying. But that's an interesting point around people kind of, you know, effectively succeeding, but not really knowing why. And I know that we talked before this, but when we're doing the prep around kind of the idea of luck in product management as well, and, you know, he talks about playing games and hitting the slots and stuff. And I think, you know, before this, you were like, you know, sometimes, I don't know if it's sometimes or always, but luck can trump good process, good skill, because ultimately, you know, you can do all of the things wrong and still hit a home run, or you can do everything right and strike out. And that's somewhat of a depressing thought for an industry full of people saying, operate like the best of the best, do these things, follow these frameworks, you know, install this operating model, and you're going to get better results. So how much then is product success really down to luck? I don't know. And I don't think anybody does. And again, I think a lot of organizations have huge rewards from luck. What, so I think we all have to acknowledge, we all have to believe, understand that we are one of Skinner's pigeons, we are stuck in the cage sometimes, and we don't know what's going on behind that wall, or we can't predict what's going to happen when we peck that button or release that feature or release that new product, but it's, you have to acknowledge that we can't know. One of the common things, let me tell a story without naming company names. I was with a company earlier this year and they had recruited me to come in and help with, help with their vision and strategy, help them rethink where they were going because they had just released an end of year release at the end of 2025. And it tanked every, they had over 2.6 million active users for the product paying monthly to use this product. And they released a product, incorporated a bunch of new features, and they made the product that people use daily harder to use. And they injected lots of, you should upgrade your subscription to this new feature, junk into it, and you can expect what was going to happen. So, they believed that if we can just get this, these chunk of new features in, that we can charge revenue for it, we're going to release this and we're going to make bucket loads of money. They didn't realize that the thing in the middle is that people have to see it, try it, use it and keep using it and say good things about it. And people saw it and they tried it and they struggled a little bit and some abandoned it right away. Some of them kept using it and abandoned some of them. Then they went on to write bad reviews and the app store ratings started to sink and people started to, started to try it, well, that people wanted to cancel their accounts and it was a huge mistake and just realizing that, ah, there's that thing that has to happen to be successful causes companies to say, this is a bigger risk than I thought. And you've, I'll say phrases like, test before you invest or nail it before you scale it. We'll talk, I'll talk about organizations using a release to learn and iterating that before they do a release to earn. And these ended up being product fundamentals. And yeah, if you understand those product fundamentals, you realize if we are wrong with this and our users don't see it, try it, use it, keep using it and say good things about it, it's going to hurt bad. Then we ought to test before we invest. And that was the fundamental that you, so yes, that, that part works, but being able to predict what's going to happen. Yeah. Sometimes it's luck. Uh, but Yeah. Well, like right place, right time, or, you know, you happen to be the first entrant in a market or you have some kind of other advantage or technical moat that obviously technical moats are apparently all going away now, but just this general idea of like, sometimes it is right place, right time, right? Sometimes it's not just that you kind of out-executed or you kind of out-product or out-producted your competitors, but that, you know, you, you kind of just took your chance when you had it. And so let me, um, mention, uh, have you ever worked with a client who accidentally succeeds, they release a product and their customers misuse it or use it for a purpose that wasn't, it wasn't intended for, and then they say, Oh my gosh, there's an opportunity there. We should lean into that and re-strategize and shift into it. But we had no idea. We didn't even try to release the product that people are misusing our product and using it for something else. Uh, I, there's no, I have to remind, uh, how many clients do you have that use Jira for example? I have several. There's a disappointing number on Azure DevOps as well these days, but. Yeah, yeah, fair enough. But, but it's interesting to remind people that Jira was released as a help desk ticketing system. How did we turn this into a, an agile project management system? It wasn't, that wasn't its intention. And I've had, I've got so many customers that happened to notice that customers are doing this weird thing with our product, uh, and, and they dig into it and go, Oh my gosh, there's a problem to solve that we didn't know needed solving. It, if we talk, look at processes, um, it's just really hard to predict what people are going to need. It's really hard to, uh, predict what's going to happen when we release it. But the only thing we can build into the way we do things is the paying attention part, paying attention to what happens when we ship something and then paying attention to what they're doing today. And I see a lot of companies that just pull that part out of their process. And that's the, the shocking thing. Well, one of the ways, um, you know, we've kind of talked about sort of satisfying the, the, the people that use these things and doing things that matter to those as well, and one of the things we talked about before this as well, this idea of, you know, kind of the fundamental, one of the fundamentals of product is to kind of talk to the people who use what you make. And that kind of goes, you know, maybe to recap on some of the points you just made, like this idea that, you know, you observe how people are using stuff, you try and work out what they're doing, what the best opportunities are, and you, you kind of double down the nose, et cetera, et cetera, but you also said before this, that humans aren't naturally empathetic. And empathy seems to be a big part of that. You know, I'm going to watch these people. I'm going to kind of understand and empathize with them. And then I'm going to make the best calls and try and make their lives better. So how can we make sure that when we are going out to people and trying to find out what's going on in their worlds and try and deliver better outcomes for them, that we're actually hearing what they're really saying and empathizing what they're really trying to do so that we can maybe make some of those hard decisions and not just double down on what we were working on before. But, you know, if it makes sense, actually move into a different space or, or solve a slightly different use case, because actually that's the real problem. So that's a good question. Uh, Jason, just bring the energy and, uh, put all the lights on and, and, uh, just asking loads of good, good questions and good follow-ups and listen to their answers. I just, it's, I think humans have sometimes a hard time being, I remember having a, an argument with someone, uh, that you can't really be empathetic unless, unless you've been in their shoes. Uh, and, uh, and Jeff, you're saying empathy so much, but you can't be empathetic and I'm saying, look, are you saying that I can't build software that a brain surgeon likes without being a brain surgeon? Um, uh, if I can't build flight control systems for a jet without being a jet pilot, uh, no, yes, it's hard. It's harder to get empathy. It's harder to put ourselves in your shoes. So keep trying, uh, and, and, and keep putting things in front of them and keep learning from what you learn. So, yeah, it's, I think one more thing I want to come back to with the empathy, but if we make a practice out of trying and one of the, one of the most useful things, one of the things I do, you do, you do a lot of B2B software. Uh, you were talking about, uh, you and I were talking about rich mineral before and we've all know rich is a strong super product guy, but he's focuses on that. Oh, wow. Sorry. Yeah. It's, uh, don't talk with your hands on a Mac. I got to turn that feature off. I got to find where to turn that feature off and I'm sure it's great. Yeah. Yeah. Yeah, probably. Uh, with a B2B product, it's hard to validate that you built the right thing. So one of the things we'll do, uh, um, is a simulation is a dress rehearsal where, uh, it used to be called in the old days for old people before agile, we used to call it a conference room pilot where we set up the system and we all be, we don't just, it's not an acceptance test where we go through the software, we all step into the roles of the user and do their job. Uh, even if we don't quite know how to do it, we will struggle with it, but we simulate being the user and where we're delivering a B2B process that normally might take a week or a month to go from end to end in the process. We can simulate it in a day. Uh, and we can orchestrate a simulation a day to using real stuff and fake some of the data we don't have. And every time I do that, when you put it, uh, an engineer behind something they built, you put a product manager behind something they built and they have to start entering data and they said, I never realized how freaking annoying this is, how hard this is, or I thought it was good, but it's not. Uh, uh, I, we've done these kinds of simulations where, uh, we've got people creating documents and then people that need to review and give feedback on them. Uh, and when we're doing a simulation, uh, we put them in separate rooms because in the real world, they're not in the same room, they can't talk to each other. The only way they can talk to each other was, is with instant messaging, things like that, and they start to see how freaking annoying it is to have to ask a question, have to wait for the answer. And, uh, and, and they start to really putting yourself in the shoes of the user. That's one of the, that's one way we do start to build in a little bit of empathy. Yeah. Spend time with them, sit with them, put yourself in the shoes of the user. There's a, there's a bunch of kind of, uh, little things and we can, we can brainstorm about that all day long. But the important thing is to recognize that it's hard and if you don't spend time doing it, it's going to be a problem. Aidan McCullen-Gromicky Yeah. I've, I remember hearing the advice, uh, from someone can't remember from whom, but this idea that every now and then you should basically re-onboard yourself to your own product as a new user versus just, you know, you've signed in once and you've saved your login and it logs you in automatically forevermore. And you kind of miss the new user experience and all of the pain points that probably you're going to get. I actually would love to see some of them LinkedIn. I'd love to see a video of a LinkedIn product manager using LinkedIn and to see exactly how much fun they're having with it because, uh, Yeah. So I teach a routine product management classes and I want them to be real. So, uh, the, the shape of the class is, uh, I'll have people spend the first part of the first day complaining about products that they use. Uh, and then I say, okay, let's organize teams and, uh, you're going to be substitute product managers and let's talk about, choose the products you want to work in, work on and the problem you want to solve. And then let's talk about, let's go through the steps of solving it. And the last time I ran a class, somebody chose LinkedIn and how annoying it was to, uh, use LinkedIn to apply for a job, to find out about jobs, to talk with recruiters, uh, and all the problems they have with that. Uh, so yeah, I do wish. not. Uh, so yeah, I do wish someone at LinkedIn would have to reapply for their job on LinkedIn and see how it goes. One day, one day. One day, yeah. But one way people are trying to, you know, fix up all this stuff and get better and build all the best products in the world is by slapping AI over everything. You know, we kind of touched on it a little bit earlier. I know it's something that you've got opinions on as well. And you've said that in your experience and probably everyone's experience, AI can kind of, it can help us, but it can also help us fail and it can kind of help us fail bigger and faster than ever before. So, yeah, you're out talking to a bunch of companies. What are you seeing out there? Like the kind of the failure modes of AI, where maybe it's not delivering on the promise that maybe some of the loudest LinkedIn and, and social media voices are kind of, you know, espousing to the world. As an aside, I told the story earlier about a company that I couldn't possibly name without getting into legal trouble, released something to 2.65 million users. One of the things that we're really struggling with is releasing it because it had a lot of bigger new capabilities they were putting in. And the only way they were able to get the release out was by using AI to get it out. So there was, there used to be an old joke that everybody makes mistakes, but to make a huge mistake, it takes a computer and to make a monolithic mistake takes AI. And you can start to sink a hundred million dollar company by releasing something that, that hurts everybody using the product. So I see those, what I see are failures of people understanding the fundamental model. I see people not assessing the risk and using a test before you invest or releasing to a small, doing a 1% release to a small subset of customers in an area you can control, observing, actually checking the metrics and then, and also there's a problem with metrics, metrics tell you what happened, but not why. So you can see what people are doing or not doing, but why? So you still have to pair the subjective and objective data and you have to learn from that release. So yeah, AI allows us to get something out faster. And if you are oblivious, if you are a pigeon in a box pecking the target, if you peck and there's no food, you can peck again and you can peck again and peck again. But what we need to do is look behind that target, look into the engine, learn from what we released and AI doesn't let us do that faster. Now that said, I've seen people construct AI that will evaluate a UI for usability. I worked with a company that had constructed a voice of the customer agent that was trained on all the reviews and all the interviews. Aidan McCullen-Navarrow But haven't heard you speak to an actual customer. Yeah, no, no, because they do, they did. The company is smart, but the first, their first cut is the, yeah, they did both, but their first cut, when somebody proposes a new feature, they ask the voice of the customer to say, is it good? And, and it helps them expose some of their assumptions. But it isn't, it's AI predicting what customers say. It's not what they actually said. And when you have AI do usability tests or heuristic evaluations of your software, if you have AI predict how many people are going to use it, it's just a prediction. And AI, AI isn't much better if, look, if AI could predict things, somebody would harness AI on the stock market and become a billionaire pretty quickly. But it's not, yes, it can, it can expose things for us to think about, but it's still, it's still hard to predict. Again, back to our discussion about luck, there's still a bit of luck. There's still a bit of things we can often learn something or get blindsided by something that, Oh my gosh, I'm surprised about that. I didn't know that. Uh, your, your question was how does AI screw up things? Uh, the short answer is it allows people to make, uh, more mistakes faster. Uh, and if they, yeah, the bad decisions of scale, and if they don't test before they invest, uh, and then they, they release a whole bunch of stuff that people can't use. Uh, I like the, I was catching up on your podcast and I was listening to what Rich Mineroff was saying about, yeah, if you release a ton of new features, there's a high likelihood that almost no one is going to see them or try them anyway, especially if you're changing that fast. So, uh, drawing people to a new feature, a new capability is, is a hard thing. Um, um, and gosh, one of the, where AI can write code faster than you can, AI can do research on the world a little bit better than you can, but where AI gets really powerful is when it can look at your customer data and help your customer make decisions faster. Uh, when you get away from that, uh, prompt of, well, what do you, what do you want, or where the user has to ask the questions, but you harness the AI embedded in the system and have it make good decisions, uh, that's great, but it's also freaking risky if you were a bank and you unleash AI on your customer's data, how do you know that you haven't created a hole for hackers to get through? How do you know, uh, that that AI can't start, uh, uh, answering, uh, your customer's questions about their accounts, uh, uh, by referencing other people's big accounts and what they've done and how would those other people feel about it? Uh, there, one of the things I attended a tech conference last, last week. And I, cause I'm so post-tech, but I watched architects talk about AI architectural patterns and using, I had to write it down, an MCPL or a model context protocol so that AI is locked out of, or policed on what data it can get and share, and there is some very complex architecture that goes into using AI. And it ain't so easy as just saying, I want this feature and put it in there. It's how, uh, how it does things. There's a lot of risk embedded in it. Uh, so, and I see organizations that are starting to shovel faster, but they're, uh, uh, you can see them, uh, uh, uh, driving at formula one speeds with no airbags, uh, yeah, yes, exactly. Uh, and I can see bad things are going to happen. I think we're going to start to see over the course of the next few years, we're going to see some big, bad mistakes. Well, it's interesting though, cause that point about kind of shoveling and it kind of brings me back almost to the kind of the user story map, uh, concept as well, of like, you kind of got your backbone, the kind of the overall set of things that the users are going to want to do, uh, to get from sort of A to B from wanting to do something to achieving that thing. And then you kind of got your vertical body underneath it and all of the different things that they could do. And then you start slicing the, uh, and they tell you, you, but the book, but kind of makes it feel like AI is making people addicted to kind of the vertical. And not so much the horizontal, like, so they're, they're worrying more about just getting as many things in to solve a use case as possible and not really necessarily worrying too much about whether it's actually solving a meaningful user problem and it kind of feels like maybe they should be pointing the AI at that instead, not necessarily to create the map or the, or the path or whatever, but to investigate and explore and understand maybe what they should be solving, not the different expressions of that solution. So one of the things, uh, I, I have worked with a few people, it's like, I'm so, uh, I feel super behind when I started working with smart people. Uh, there's a lot of smart people that have contacted me about using, uh, using cloud to generate story maps. And one of the things they do is take a requirements document, take a big description of the feature, and then they have it generate a story map. Uh, and of course you have to massage it and you have to know what a good story map is, but as soon as it starts generating a story map, they can start to spot what abouts, or what if we did this, or what about that? Uh, and there's, they learn a lot about, again, we, we can't release anything without expecting users to change their behavior, even if it's just using a new feature instead of an old feature, but we're expecting them to do something different and what your story mapping is, what they're doing. Uh, you start by saying, telling me the story of what they do. And, uh, so the people that are using AI to generate a story map, and then they inspect the story map, then they start to say, oh, there's a hole here. Or what about this? Uh, and then, and they learn a lot, uh, and they're using, people who use AI well, use AI, uh, like a super suit, uh, like, uh, like Iron Man, just, yeah, it's just, just Tony in that suit, but, uh, yeah, he can fly and shoot things out of the sky and, uh, and has super strength, but it's still a person in that suit, and when I see people using it, right, they do use story maps for what they're intended for, which is understanding that solution, thinking through the outcome before it comes out. Um, and then, and we got to have an MVP talk by the way, uh, uh, um, uh, then breaking it down into options, uh, uh, I'll tell people to break it down. And when they're breaking down what they might do, or they break down that user experience, I'll ask them to play the good, better, best game. What's good enough? Uh, what would be better? What would be best? Um, um, and they can start to come up with a release strategy. What do we need to release first? Or if we'd use that release to learn, if we're releasing, instead of releasing, we're Spotify and instead of listening to a million, releasing to millions of users, we're going to release to a few thousand users in this geographical area. So we don't have to localize it to other languages and blah, blah, blah. Uh, and then we'll learn from that, uh, uh, what's in our release to learn? What can we leave out of it? If we're doing that minimum lovable product, uh, and, and using a story map, uh, lets you do that. Uh, there's a lot of thinking that goes into it. And if people don't understand that thinking, yeah, they will go straight from here's the description of the feature to the UI, to the code and release it. They haven't thought about a release strategy. They haven't looked at the risks. They haven't, if you don't know that stuff, that's where. Uh, if, yeah, if it, um, now what is it? Uh, I remember, uh, somebody saying to me once I was, because I'm, one of the things I'm known for is, is teaching user experience kind of thinking and practice to non UX people. Uh, and, uh, and, uh, and somebody was telling me you should, you can't do that. They're not UX people. You shouldn't teach them. And I said, dude, you, you act like I'm teaching monkeys how to use handguns. And then they said, and they said, okay, yeah, you're right. That's, that's, I think what you're doing. And, uh, AI is a big handgun. Um, don't put someone who's a good shot behind it. Well, it's interesting because you talk about like, um, this idea of just like, you know, shipping and, uh, you know, shipping, shipping all the things and, and, you know, like not tracking what people do with those things and the results and what you learn and what you don't learn, but I've actually seen some people in the, kind of the more AI booster camp espousing this idea more like, Hey, we don't even need to really even do discover anymore. We can just shove as many features as we want out of the door. We'll give them to everyone. And if we find out that people aren't using them, then Hey, we'll just turn them off again. Now that doesn't feel very customer centric to me, but maybe I'm just old fashioned. It's a little bit like, let's say, uh, let's say, uh, uh, uh, Jason, let's say you and I want to open a restaurant and, uh, open the doors. Well, you used to be a cook, no, I did. I used to be a fry cook when I was 15, 16 years old. I learned how to, I learned how to flip eggs, try and flip an egg without breaking the yolk, man. Uh, uh, it's a, it's a big deal, but let's say you and I are going to open a restaurant, but we don't know what to serve. Uh, so every day we put stuff on the menu, uh, and some of it tastes like shit and some of it's good and some of it, nobody wants to do, uh, do there, but that's okay. We'll just keep trying things. How long do you think people are going to come to that restaurant? Uh, not long, probably. Yeah, that's it. So you can't, so yes, people, yeah. So if your discovery is, uh, okay, let's say you're a drug company and your way of, uh, doing drug discovery is to create weird things and just try them out on people. Go ahead. And when you do that with customers, customers eventually say, I've had it. I'm not going to try any of this new stuff. Yeah. They'll go to another restaurant where the, where the, the food they're trying has honestly been cooked and tried and iterated on before they order it needed. Uh, so there's that. So, so yes, we can do discovery. And again, I I'll use the terms released to learn or build to learn. So long as we've got a learning audience, so long as it's not our core audience. So not, uh, so long as we're working with early adopters, not the majority, because the majority ain't giving you a second chance, uh, uh, you, if we go back to metrics, you don't have an acquisition problem, you have a reacquisition problem because you've already disappointed them. Uh, that's a problem. And then here's the other, yeah, secret to product that, uh, um, that nobody quite remembers is the most important part. Isn't building something and seeing how people respond. It's finding the problem you want to solve or finding the need that needs to be met. It's the work you do to, uh, and, and my friend, Jeff got health and Josh Seiden's language. It's the word you do is sense. It's the sense and respond. And if you're just having AI build stuff, you can think of the worst stuff that people ask for as though, uh, they're going to ask for the thing they need. Uh, as though they're the best problem solvers, the, the, as though they know technology and what technology can do better than you do, uh, that that's where the real art comes in is paying attention. And sometimes when you pay attention to what people are doing with what you built, that's when the, the, the, we talked about this earlier about companies stumbling on success. Companies finding a need they had no idea was there by watching people and learning from them. Um, so, uh, yeah, the, so yes, uh, people are saying, yeah, we don't need discovery anymore. Well, first off you are still doing discovery. You can't, you can't, you can either validate your idea by shipping you to everybody and suffering a big financial loss, or you can validate your idea by constructing a prototype and releasing to learn with a small set of people. Uh, and, uh, AI lets you do either. Well, choose wisely. But a lot of what we're talking there is around kind of good product practices, I guess, versus less good product practices. Then we start thinking of, you know, back to the kind of good product manager, bad product manager. But, uh, on that note, there was a statement that you made before we recorded or started recording this around how the strongest product people can use their powers for evil. Now this makes me think of my recent discussion with Eric Reese about these kind of investor driven profit at all costs, unethical organizations that are just trashing all of the value that they create, but that's on the investor side, is it really true that the strongest product people gravitate towards the dark side and what does that concretely look like? Well, not everybody. I mean, we, we know from star Wars that not everybody gravitates to the dark side, but some do, uh, and, and you can use, you could use the product force for, for evil. Uh, there's an old friend of mine who wrote a book called evil by design. Have you ever seen that? I've heard of the book. I haven't read it, but I have heard of it. Yeah. It's a guy named Chris Nodder. He's a, he's a good, smart guy. And the, the book is organized into seven basic sections. Uh, any guesses what those seven sections are? Uh, yes, exactly. Uh, lust, uh, greed, envy, pride. Uh, and I, uh, that's, I'm, I forget the, the other, the other one. We're going to have to watch the film again. Yes. Yeah, no, that's a good breakout film for, uh, but, uh, now no, yes, we think we're building software products that solve people's problems, but I can promise you that people are not using Facebook or Instagram or Tik TOK to solve a problem. Uh, the problem they might be solving is sloth or, uh, envy, uh, or if they're trying to use it to market the, the, the greed part, uh, look, we wouldn't have an internet without lust. Uh, what, what drove the internet boom? And now, sorry, and there's the talking with your hands thing again. Uh, you know, the, the, if we didn't have a porn industry driving the growth of the internet, uh, it wouldn't be there. We'd still be on modems and dial up, right? Uh, exactly. Uh, I mean, it, it, it drives a lot. Uh, and if you recognize that people are driven to, uh, they're driven by pride and envy, and if you show them, if they get more likes on their photographs, their pride swells, if they look at more people doing cool things on Facebook and Tik TOK and Instagram and, uh, uh, whatever else they're there, it's going to dig up their envy and they're going to look at more things. You can leverage that. You can construct algorithms that show them more things that they can get addicted to, uh, more things that will cause them. And remember the, my Skinner's pigeon intermittent reinforcement problem, just because if you show them in short form content and show them thing after thing, after thing, and only one thing. or thing, and only one thing out of 10 or 20 or 30 is good, that's enough to keep them clicking and playing. And yeah, when you start to understand that, yes, for a product to be successful, people's behavior needs to change. But when you recognize that people want things that are not good for them, which is why McDonald's stays in business, you can leverage that. And there is no shortage of companies that are doing things that might hurt people, and this is no surprise that, is it Australia, New Zealand, the Southern hemisphere, that's outlawing social media for kids under 16? And they're going to try and do it here as well, I think as well. Yeah, fair enough, because it's not good. Yes, there may be some benefits to it, but the seven deadly sins embedded into it is driving behavior that makes them money, but hurts people. But again, if it's not going to, we're still going to sell a lot of candy bars because no matter how much we put into them, and I still have a pack of cigarettes in my computer bag because everyone's smoking a whole lot of cigarettes. Well, if you have three whiskeys in your, at a nice bar, it's time for a cigarette. That's what I've learned, but you know, maybe once a month. There you go. Well, what's the worst that can happen? Yeah, I can, yeah, I meter it. Imagine then there's someone listening to this thinking about some of the stuff we talked about, about the fundamentals and this idea that there are some kind of core things that we should be trying to do and sort of principles that we should be trying to live by to make better product decisions, drive better outcomes for our users, obviously drive better outcomes for our business as well. But they're also kind of swimming in this kind of AI hype hellscape that's going on at the moment and being pushed to do certain things that maybe they feel pushed against that, like what's one concrete thing you would recommend someone try to do or go back to doing that maybe they might've felt dragged away from that could make them feel better and make better product decisions. No, there's not an easy short answer to this one. Um, first off, I spent a lot of time exposing that basic, you know, fundamental product model that your business wants something, it can't get something unless it finds a customer user that wants something, uh, and then they spend money building, releasing a product or a service, and then your customer has to see, try and use it. And the money they spend building something is converted into more money by the customers and that's what funds your business. So once they understand that, I'll ask them to just make sure you understand those models and that there's the secret phase two or the outcome, uh, in there. If we got output, outcome and impact, and I'm probably going the wrong way. output, outcome and impact for the viewers. Uh, um, but the hidden phase two or the thing right behind it is that opportunity, uh, it's spending time really understanding the opportunity, understanding what people need and really spend time, spend time really understanding the outcome or what happened. Uh, the, the one thing that I'll ask people to do is just pay attention to what you're building and tell me who is going to use it and what you expect them to do, uh, and the, and if they could do one thing, it's just go find somebody using what you build and watch them use it or talk to them. Uh, I I've worked with product managers for the last 15 plus years, and I'll ask a product manager, what one piece of advice would you give to someone who's a new product manager? What do you wish someone had told you 10 years ago? And at least half the time I get, uh, the advice to talk to your customers more often, if people would just do that, one of the, uh, gosh, I've worked with a lot of companies that, uh, we'll say the excuse that, well, we can't talk to our customers or we're not allowed to talk to our customers. I remember working with a U S department store chain target, but all target IT people work in an office building where downstairs is usually a target. And we can go down and talk to people buying from target, talk to people, cashiers using a system, the system systems they build, we can talk. It's easy to go find and observe and talk to people, uh, and just do it. Uh, and you'll be looking, uh, Jason, I know you've probably watched somebody use something you've built. Yeah. And everybody, everybody, everybody listening here, uh, the, uh, most people listening probably have watched somebody use something they built. If you think back to the first time you did it, uh, how did that go for you? And most people will say it was a shock. It was awful. Uh, and it's, that's where the, that's where you start to get a little bit of empathy, that's where you really start to understand the, the, the difference you're making. Well, here, here, go and talk to your customers or your users and go and find out what they're doing. And don't have AI go talk to your customers and users. AI can read all the data, it can synthesize it. Yeah. I usually I'm, I'm terrible at marketing lately when people ask me, uh, yeah, just don't, don't ask, don't look at my marketing stuff. Don't look at this stuff. Just go ask chat GPT, what I do, or who is Jeff Patton, because it does a better job explaining to people what I do or what I care about than I do. So, but it can, it can synthesize a lot of data. So there's that, but I don't know, you need the empathy. You're the decision maker. You're the person in the super suit. Uh, you've got it now. Well, if people do want to come and ask you after this, what it is you do, or maybe, you know, try and persuade you to write a second edition of a book or see if they can get you to flip them an egg, where can I come and find you after this? Uh, I have the super long, just Google Jeff Patton. Uh, but I have the super long domain name because I couldn't get JPA, uh, of J Patton and associates, J Patton and associates.com. Go to there. Uh, just reach out, just get in touch, ask chat GPT, what, what he does and who he's helped that does a better job than I do go to YouTube and, uh, I've, I've never put a single video on YouTube, but there's a bazillion people, uh, recorded talks on there and they could do that. Um, I teach routine product, product ownership, product leadership, products, uh, management classes. Routinely, a lot of companies have, uh, actually I remember a lot of companies will send three people this month and three people next month, and I've become sort of the training platform. Uh, uh, what was, I was told by somebody that, uh, I was told I need to come to your class because my head of products, uh, uh, says, uh, you're the decoder ring for her, everything, if you don't know this language, you're not gonna understand anything I say. So go to Jeff's class to do that. So, uh, so, so people can do that. And, uh, we're talking about this before I'm struggling to work on another book and the struggle, the book I'm struggling. Look, you were asking how do people get these basics and I cannot point them to any one book that cleanly describes these are the essentials. And this is what goes wrong when you, uh, don't do things and what goes right when you do, uh, my friends, uh, Josh and Jeff tried to do that with sense and respond. I'm going to try and do the same thing. So stay tuned next year. I'll get something out that, uh, that hopefully we'll try and do that again. Because I am so tired of, I'm so tired of walking into big organizations and running into the problem that, you know, Eric Reese did go back and listen to his or the organization loses its way and thinks its job is to make profit. Uh, and they, they, and they forget the essentials that your company succeeds because you actually make things that people want to use that help them. Uh, or you can do evil by design and you can succeed wildly by doing things that hurt people, uh, at least until the, at least until there's new regulations against you. Or AI kills us all. Uh, yeah. And it's only a matter of time before it gets hold of our nuclear systems. Well, I dunno, blessed relief, huh? But before then I'll make sure to, uh, add that all into the show notes and then hopefully another few people heading in your direction, find out more and maybe jolly you along on the pathway to a new book. Well, Jeff, it's been a pleasure to chat and kind of go into some sort of fundamentals and sort of see how we can try and make sense of all of those in a world where we're all being told to kind of move fast and do everything all at the same time and how machines can do that. We used to move fast and break things. Now we can break things even faster. Yeah. No, let's bring the humanity back, but, uh, thanks for, thanks for coming on. And, uh, hopefully we stay in touch, but yeah, as for now, thanks for taking the time. I am pleased to be with you and, uh, thanks for having me.