Jeff Patton: earlier this year I worked with an organization that released a new brand new fabulous glossy release to 2.65 million customers, and it was crap. it was it didn't break. There were no bugs in it. It's just that nobody liked it. Hunter Harris: Hey everybody and welcome to Build and Break Through. I'm your host Hunter Harris of Hunter Software Consulting. And with me today is a someone that I've been dying to have on the podcast for some time now. Jeff Patton. He's the author of the bestseller user User Story Mapping, the chief troublemaker at Jeff Patton and Associates, and kind of like the father or grandfather of a lot of what we have in Agile, right? Jeff, do you want to introduce yourself a little bit? Jeff Patton: yeah. Maybe I'll introduce yeah, the father grandfather means I am old. I've been around for a very long time. I was there when when agile first started I was working at a a startup in San Francisco because I left my existing company to work for this cool new company doing two things a cool new way. they were doing this process called extreme programming in two thousand and then the term Agile was going in two thousand one and I found out that's what I was doing. So I got a very early start at this. If you hang around long enough then you will be the the father slash grandfather of of everything. just because you were standing in the background when it happened. but been in the background for a lot of different things to happen. we can discuss some of those things. any more introduction I need, that was that was enough. It was a complete ramble. Yes, I'm known for Hunter Harris: I I I think that's a good start. I mean, you're known for the Spotify like the drawing stuff, right? Jeff Patton: Yeah, I so little known fact, I taught the very first class of product well product ownership and product management in Spotify when it was a single location in Stockholm with less than 150 people. I had all the product managers, all the user experience people, all the senior engineers and all the agile coaches in one room and it was less than 50 people back then. And I talked and drew and they dug it, they liked it, I helped kind of inform the way they did things and my friend Henrik Kniberg said I like this talking and drawing thing. He made the Spotify engineering culture videos and he speaks better than I do, he draws better than I do, but he cannot do both at the same time, which is what I can do. So that's the that's the difference. But I I happen to be there in the the background in early stages for a lot of different companies including Spotify, including Atlassian for better or worse, and a bunch of other companies that people don't know about. Hunter Harris: And I I guess like to bring it full circle a little bit for a lot of the viewership here, like what's been sort of amazing about meeting you and talking to you and taking your course on passionate product management as well, is that yes. I was so worth it. Cause I I didn't realize that like Jeff Patton: I that's right. I I made you attend that class. do you regret it? Hunter Harris: this was like the source of so many things that I had learned on the job. So it it's really interesting to like kind of come full circle and be like hey, there's all this stuff that has been incredibly impactful in my career. And this person is the source of a huge amount of that. and because you you know, it's just the wind beneath Jeff Patton: Okay. Yeah. It's up. Hunter Harris: your wings, the water in your gills, it's just the environment you Jeff Patton: Yeah, yeah, the Hunter Harris: think you're in and you don't think about someone creating this and you can meet that person and learn from them directly, right? Jeff Patton: It's just i again, be as a function of being there. in my early consulting days after leaving a company called ThoughtWorks. Some listeners may know who they are, but you should look them up if you don't. but I left ThoughtWorks and then I took a first consulting client. I was working for this guy named Josh Seiden at a at a company in New York, and I was working there continuously. And then I through an introduction from somebody else, I met with this other guy named Jeff Gothelf. Jeff Gothelf at that time, very long time ago, was very pessimistic about. About how all this agile stuff would work. And then eventually Jeff and Josh met each other. They wrote a book called Lean UX that's now in its third edition. And yeah, it's I hate to say it, certainly they've built on it and advanced on it, but it's it's the stuff I used to be doing before then. it yeah, it just I'm not very good at self-promotion or book writing. I finally got one out, but but it's it's nice to have been there and nice to have seen things. Yeah. Hunter Harris: Hmm. And you don't have to worry too much about self-promotion. That's what stuff like this podcast is for, right? We can do a teeny bit to the best of our ability, Jeff Patton: Yeah. Hunter Harris: we can do a teeny bit of the promotion for you. But I guess jumping into it though, Jeff Patton: Yeah. Well yeah, I was gonna say at the end I'm gonna promote the class you attended because I that's one of the things I can continue to but we'll do that at the end. Hunter Harris: Yeah. I mean that that was awesome. I mean, yeah, we'll we'll do it at the end. but jumping into it, the main thing that I wanted to cover with you is dual track development, which is something I had been introduced to. this this is one of the concepts that I had experienced on the job but had no terminology for until I took your particular class. And it also kind of like made me realize with a number of the customers that I'm working with at the moment, this is something that they're really, really struggling with. so do you wanna introduce the concept of dual track development? Jeff Patton: had you heard the term dual track development before I said it in class? You've heard of it before. I've seen Hunter Harris: I had not heard it before you said it in class. I heard it from you first. I I I b I had like a there there wasn't like a pithy term for it when I experienced it. It was more like we should be doing experiments in addition to d just shipping stuff. If that makes sense. Jeff Patton: I'm looking back at there she is. so a long time ago I I and I and Marty Cagan co-taught a class together. It ended up being a three-day class and I I think as a result of that Marty saying, I want to teach classes again with Jeff because I do a bunch of things very differently and and there's a lot an awful lot of overlap of what we say and it makes it difficult. But but one of the things we were talking about, I was intro I introduced this this idea of doing discovery discovery and delivery simultaneously and and I and I drew the model but I didn't have a word for it and I I I said, Well this is an old concept and I I get the model from This well a long time ago from a company called Alias. Alias is now a part of Autodesk. anybody who does 3D animation and creates 3D models know whose alias is or was. And a lady named Desiree Sy, I had to correct my pronunciation. It looks like S Y, it looks like Cy, but it's the cor proper Korean pronunciation is C. Desiree wrote a paper a long time ago, and in there she talked about using discovery and delivery in dual track. And I have pointed that out. And Marty was there and he saw that dual track thing and he started saying dual track from then on after. Now, if I could choose a different name for it, I would. But when somebody like Marty says dual track and keeps saying it, then other people pick it up and keep saying it, it's done. I can't change it. And all it means. What you see traditionally in an agile process or most development teams, you're focused on building what they're asked to build. But if you're product-centric, you're not just responsible for building what you're asked to build, you're responsible for it being successful. And there are a lot of risks to it being successful. Now, I wrote that story. I'm tacking, I'm taking too long to get to the you can cut me off and refocus me, but Hunter Harris: No, no, no, this is great. Jeff Patton: So I there are two chapters in the story mapping book about product discovery. The first chapter but the there are two chapters in of on product discovery in the story mapping book. One is on exposing your hypothesis, exposing who it's for, how you see you use the map to explain how they well the interactions, the outcomes, what they're doing with the product, to break down that big feature story into the steps and into options and then to visualize it, the use that's what the first part of discovery is for. That exposes what you believe. And the second part of the second chapter in story mapping is about questioning your beliefs. And here's why there needs to be a second edition of story mapping is because in story mapping I talked about you know, there's a discovery team doing all that stuff, exposing and and defining what we're gonna build and exposing risks and assumptions and validating those and then there's a second team that's a delivery team that builds those and what I learned from working with and coaching people over the last 10 years is that it is two tracks but it is one team and that's what I see and when we talk about dual track we talk about yes we've got these two tracks running but our ambition is to have cross pollinate is to pull engineers and testers and other traditional builders up into the product discovery part. And if you're a product Hunter Harris: Mm-hmm. Jeff Patton: manager or a UX person, you know you're gonna get pulled down in the delivery part whether you like it or not. you're gonna be there to define answer questions on answer questions you didn't think of on the the the software you're building. So yeah that's the the origin of dual track is that Weird pointing out the dual tracks of development in Desiree Sy's paper many years ago with Marty. And what it means is we're moving from traditional traditional, let's say if we've got a everybody here is using it, likely is using an agile process these days. But a traditional agile Hunter Harris: Agile or agile Jeff Patton: Agile ish, yeah. look, if we were talking twenty years ago, we would have been taught talking about trying to do waterfall well and complaining Hunter Harris: Course. Jeff Patton: about waterfall. and now we all talk about doing agile well and complaining about agile. So the people still complain about everything, but now the new the new Agile is the new waterfall. But if you are doing a traditional scrum process, your head's down focus on delivery. You committed the beginning of every sprint to what you're gonna build, you build things and check your definition of done to see if it's really built but you're never no part of o oftentimes and I don't want to I'm gonna offend some scrum people but oftentimes off the shelf scrum doesn't take responsibility for building the right thing that's the product owner's job Hunter Harris: Exactly. Jeff Patton: and what we're trying to do with dual track is to make it the whole team's job to do the right thing to build the right thing to expose risks and do discovery work. So that's I think your original question was what's dual track development? And that that's you know question question over answered. But Hunter Harris: So when a team says it needs to ship something, how do you decide or how do they decide whether they need to learn something first as part of that dual track? Jeff Patton: How do we decide if they need to learn something first? I've got a thing in the story mapping book called an opportunity canvas. these days better known as an epic canvas. It's the the the big look, I'm being asked to do a feature, and before I break that feature or that capability or that next release of the software down into a bunch of backlog items, just expose your beliefs in an opportunity or epic canvas is asked you to say, okay, what are you trying Trying to build? Who is it for? What problem do they have? How do they solve that problem today? And how does them having that problem become an a problem for our business if we don't solve it? And then if we build the solution, what do we expect they're going to do? How will we measure that they did it? And how will we expose this new feature capability to them, get them to even try it? And then how, if they do this, how How do how does our organization benefit? So what it's doing is exposing the problem we're solving, both the customer problem and the business problem, and exposing the outcome we're going to get, how specifically we can measure it, and the business impact from that. Now I will define outcome. I use a language model that's output, outcome, and impact. I get into kind of scuffly arguments about terminology even with guys like Marty Kmitt. it's very smart People like Marty Cagan, with people like Teresa Torres, and they just use output and outcome. But you know, Teresa's really good. She'll say, what's the difference? she'll make you be clear about what the user or customer outcome is versus the business outcome. What's the difference between those two things? Because your customer has a problem to solve or a need or s you know the something they want to achieve, and that's their outcome when they can, and your business wants to make money. Your customer doesn't care if you make money. Gotch. what I'll I'll define outcome is look you release this new feature, you release this new product, and people have to see it, try it, use it, keep using it, and say good things about it. Now, if you are an analytics person, you would call that acquisition, activation, retention, and referral. But that's what you know tend to use big multisyllable words to make them sound smart. or sometimes obfuscated for people who don't get it, but by acquisition we mean see it and try it. And we do that at a product level and we do that at a feature by feature level. So you were asking how do you decide what you learn? There's a lot of ways of doing this. There's my friend the the there's something called assumption mapping from David Bland, Hunter Harris: Mm-hmm. Jeff Patton: and it's good to look at that. And there's a good thing on defining assumptions and prioritizing, but in I as a result of I mentioned that guy Jeff Gothelf earlier. He and I will teach this stuff together, used to, at least routine routinely, many times a year before COVID. But we came up with a simple set of questions that to to ask. and I do these with teams on a and ask them on a scale of one to five. On a scale of one to five, do you believe when people see this feature they're gonna want to try it? Or five is, absolutely they will, and three is, well, I think they will, and one is, no, I don't think so. and I will. Ask the whole team on a scale of one to five, how confident are you that people will see it and want to try it? And if somebody answers three and somebody answers five, you have a this starts to be again. If you're an agile team, you're gonna smell a bit of story pointing exercises here. But what we're talking about is Hunter Harris: Yes, exactly. Jeff Patton: assumptions. So if we're not sure if people are gonna see it and want to try it, then we say, God, what would you need to learn in order to be sure? gosh, if I don't I I think we need to build a simple prototype or something to show it to them and and then see show it to them and and when they see it see what they what they do or what they think of it or do they want to try it and then we come up with experiments for that. so again see try use keep using and say good things about so see and try great we can we come up with a if if everybody's confident they would do that but if they say we say use then we say okay well Well now we we're we if we're not sure if they can learn how to use it or or they use it the first time, then we gotta start to build a better prototype and do some usability testing. otherwise otherwise we're starting to build something and we're not sure if anybody's gonna use or they can learn how to use. and Hunter Harris: Mm-hmm. Jeff Patton: then keep using is the hard one to test if they're going to keep using it. Well that means you more or less have to build it and let them use it and let and then see if they continue to use it. And this is one of the things Hunter Harris: Mm-hmm. Jeff Patton: you and I talked about when we were Getting together with this, this is where you build a prototype, but a usable prototype. Or we talked Hunter Harris: Absolutely. Jeff Patton: about the the difference between building to learn versus building to earn. When you build something Hunter Harris: Mm-hmm. Jeff Patton: that your customers can use, but you're not sure if they are going to use it, don't build it at scale. don't clean up every nook and cranny of it. don't Hunter Harris: Uh-huh. Jeff Patton: you're building a prototype, releasing it or making exposing it to a small number of people and measuring whether they They use it and keep using it and and say good things about it. That's it. what most organizations do as their last discovery step is to say, hey, we can't build something that we're going to release to all of our customers. We need to build something that we're going to release to a small target set of customers, early adopter group, Cagan uses the term CDP for customer development partners. Something we can show people, but it's not just to test whether they can learn how to use it, but to actually use it and get value. Lots of examples of these. I promise you that every new feature you see on Spotify, on Amazon, on Jira in Jira has been released to learn, meaning a learning Hunter Harris: Mm-hmm. Jeff Patton: release was sent out to a small number of people. They iterated. it until it was awesome and then the you get the the term nail it before you scale it. Now when you Hunter Harris: Mm-hmm. Jeff Patton: build release to learn it ain't gonna meet your scrum definition of done. it isn't Hunter Harris: Mm-hmm. Jeff Patton: built to scale. It it's not gonna have any supporting marketing material. It's not gonna have manuals and help files. It's not gonna have operational support. There's a lot of things you leave out of one of those. So in shorthand you ask how do you figure out if you need to learn. I this is a bit of a confidence test. and you ask those confidence questions and have if you're gonna take responsibility for getting a good outcome, then you need to be confident it is at at minimum. No matter what you build, you better count on measuring whether people actually used it. Otherwise It's not gonna happen. But maybe one of the last things we'll ask is can we build it predict not one of the last things or we'll we'll ask can we build it predictably? What we mean by that, or what I mean by that, is look, we're estimating it's gonna take weeks to build, you know, how much would you bet it's gonna take you weeks to build? Hunter Harris: Mm-hmm. Jeff Patton: the the bigger the estimate, the higher the risk in building it predictably. And everybody knows that when engineers tell you it's gonna take two months to build, that means somewhere between two months and nine months. Hunter Harris: Four months, six months. Jeff Patton: if they say six months, it some means somewhere between six months and never, that's the the Hunter Harris: Yeah. Jeff Patton: works. There's risk in it. And when you say, okay, if you needed to confidently say how long that was going to take to build, what would you do to be confident? That's where you get things like spikes and agile Hunter Harris: Mm-hmm. Jeff Patton: spikes. Those are, you know, learning spikes to dig into old code or engineering spikes where we're going to build an engineering prototype to test to test a couple different frameworks or learn how to use something, then we can better estimate or more predictably estimate how long it's going take. The But you know the the the I just gave you the long answer. The short answer is make sure your team knows what they are accountable for and make sure they understand it, Hunter Harris: Mm-hmm. Jeff Patton: not just building it on time. Hunter Harris: Accountability is absolutely pivotal there. If you're not accountable, it's so easy to just kind of go and build stuff for reasons. Which I I guess that transitions into what I wanted to talk about next. So you said a particular thing, ship to earn, ship to learn. sorry, that's my thing. You said a release to earn versus release to learn as it also known as nail it before you scale it. My Jeff Patton: Yeah, yeah. Hunter Harris: verbiage for this that I've been using recently, which is highly derivative for two of these, is ship to earn versus ship to learn. But I've defined a third category in terms of this, which is ship to burn, which is essentially waste. Jeff Patton: Okay. Yeah, I think you you mentioned that briefly. What does that mean? And can you just ship bird? Okay. What's it wasn't ship bird? Hunter Harris: No one should be attempting to ship to burn, but a lot of organizations end up doing a lot of ship to burn in my experience. So so if we think about a pretty classic like feature factory, for example, right? If you're doing the business, if you're doing a software business, you probably have nailed ship to earn, right? You know you have a contract, you know you need to do something to nail the contract, right? We've just covered ship to learn, which is to it's kind of like the next level above that, right? Jeff Patton: And the Hunter Harris: Which is Jeff Patton: and the Look, if you're a contract developer, if if a company hires you to build Hunter Harris: Mm-hmm. Jeff Patton: software, you're in the ship to you are in the ship to earn business because you get paid Hunter Harris: Absolutely. Jeff Patton: for what you ship. You don't get paid whether Hunter Harris: Mm-hmm. Jeff Patton: it if anybody uses it, it's if it's a complete mar failure in the market, or even if you're building it for internal use. Have you ever seen situations where we build something for internal use and you force employees to use it, but it makes them worse at their jobs or slower at their jobs? Hunter Harris: A thousand times. Jeff Patton: Or they will not adopt it because because it forces them to abandon a legacy system. And yeah, that's that Hunter Harris: Mm. Jeff Patton: that's a bad outcome, even though you control the customer there. They work for you and you still can get bad outcomes. But yeah, if you're in Hunter Harris: Absolutely. Jeff Patton: if if you were if you're a a company that they hired to develop the the the the product, you're gonna get paid for shipping it on time. Hunter Harris: Mm-hmm. Jeff Patton: Not it doesn't matter whether it was the right thing to ship or not. Anyway, I digress. Go on. Let's go back to ship to learn. Hunter Harris: Absolutely. Which yes, building on top of that in terms of ownership and agile is the ship to learn as we've just covered here, and realistically the most successful software organizations that I've worked with have been very, very heavily shipped to learn. essentially ship to learn being ship to earn being making your money today, ship to learn being make your future money make the future of the business. That third category, ship to burn, is all the other stuff essentially. So if you're doing ship to learn and you're developing a prototype that's to your point, like it's a it's a real prototype, but then it gets out on production, and then it's not scalable, but you scale it anyway, and then you get f Jeff Patton: Yeah. To make sure it works at scale and every all the time. Hunter Harris: And it but there's so many features, right, that y you get a customer cohort on it. Like you build something that nails part of your customer base, and then you find out that, no, this feature has fifty customers that are very passionate about it, and fifty other customers that are also very passionate about it, but in the opposite direction. So either way, you've got a very tough decision here, right? You can you have three choices, right? You can either leave it in like a half-alive state rolled out to some people. not roll it out to other people and surprise, surprise, now your engineering and QA burden are going up. You can tear it out of the hands of the people that love it, which is gonna, you know, make them less than happy and you may generate some churn there. same thing, put it in the hands of all the people that desperately ate it and deal with the ramifications there. So l I mean like that that's not fully ship to burn. The the the core ship to burn that I see is Endless UI refactors like I've seen organizations spend months on changing the colors in the email when they have fundamental issues that are preventing them from delivering their core client needs and you know, this sort of stuff. Jeff Patton: You you see a lot of the side effects of not learning what you needed to before you shipped. Hunter Harris: Exactly. Jeff Patton: And what you're doing is what your organization thinks is a ship to earn or release to earn in my language. But what they find out after shipping it at scale to a lot of people is there's a lot of shit we don't know here. and I say, we have to change this and that, or it's not working the way it was supposed to, or people aren't adopting it right. it's these days I do a lot of product model adoption. Kinds of working with organizations adopting a product model. And it's not always people that are building software products. I remember working with a Coca-Cola distributor recently, and they were adopting a product operating model, and they were building a lot of stuff for their own internal use, for stuff to use in the warehouse and for packing trucks and for calculating demand and steering their their manufacturing or how much they were gonna model, and I I learned the the the big craziness they they do with trying to figure out all the blended flavors of Dr Pepper. the they learned that Dr Pepper Blackberry wasn't a huge success and Dr Pepper vanilla is and and and Hunter Harris: Mm-hmm. Jeff Patton: Things that. But but they the one of the biggest problems they had is their stakeholders were piling them on with all kinds of things to build. They started actually measuring outcomes and they learned their biggest adopt problem was adoption, is that no in their organization would use it and they were going through the thrashing you were starting to talk about here. They were in a way releasing to burn or it started on fire once they released it, however you put it. but they had to keep iterating after release in order to. f actually get something that their internal users would adopt. That's so that's what happens. Yeah. The yeah and Hunter Harris: Yeah, that it's an go ahead. Jeff Patton: maybe the release to burn is the unin not knowing the difference is I I'm sure it's not Hunter Harris: That's a good way to put it too. Jeff Patton: intending to do it. It's just it happens when you don't think about it. Hunter Harris: Mm-hmm. Jeff Patton: Or for better or worse you don't take responsibility for it. Even if Hunter Harris: that is another major category here. I I was gonna say too, one of the interesting things that I've seen about this, because I do have access to several of my clients' GitHub repos, and I can look at the I I know when they adopted AI, for example, and so I can view things like trends and how they interact with their work through AI. One of the interesting things that I've seen in a lot of organizations is AI does allow them to scale their throughput significantly, to your point. It allows them to drastically improve their output. But part of the reason why I started thinking about things in terms of release to burn is because they the percentage of the time, the percentage of the actual work, the percentage of the complexity that they're actually shipping towards customer results, shipped to learn, shipped to earn. Is essentially unchanged for the most part, right? In many cases, actually, that percentage has gone down. And there's this growing mass of just stuff that's happening because AI lets you just kinda do it, right? It it's this thing like, is this a priority? Is this not a priority? Well, let's just do it anyway. Like throw it on the pile. Who cares, right? Jeff Patton: It's the it it's funny, you got me my head starting to spin. There was I'm gonna paraphrase wrong, there was an old expression that everybody makes mistakes, but to make a huge mistake requires a computer. and but to and now we compound that to make a monumental mistake requires AI. And Yeah. Hunter Harris: AI helps you scale, so if you're gonna make a mistake, we can scale that mistake all the way logarithmic, right? Jeff Patton: I won't name the name of the customer, but earlier this year I worked with an organization that released a new brand new fabulous glossy release to 2.65 million customers, and it was crap. it was it didn't break. There were no bugs in it. It's just that nobody liked it. And when you have two over two million consistent users that use your product every day and you drastically change things so that people don't like them, that's gonna tank It's gonna cause a lot of customer attrition or a lot of retention issues. It's going to really it's going to shock your app store reviews. it's gonna it's gonna cause a and ultimately it'll rattle up to your board of directors and and hurt your your your earnings. So th anyway, and and they were able to succeed with a big monumental release because of AI. They were able to generate that new release on time that had a lot of new things in it again. And and and you're right, Hunter, this was a release to burn. It's just that it was very unintentional. They didn't want to or hope to and were unhappy that that happened. so one of the things I keep coming to with the yes, I'm working with a lot of organizations, everybody's everybody is somewhere in this continuum of spoke with an insurance company earlier today and they're super afraid of releasing Claude on customer data because of culpability. And and yes, there are a lot of, by the way, there's some there's good books coming out recently. I recently heard from a couple people who are writing a book on AI patterns in order to allow Claude access to your data but secure it. And I forget the the AI terminology to to gate it so that it can't misuse or inadvertently expose data to other customers or to people that shouldn't have it. But there's a lot of risk with with using AI. But you need to understand the basic product fundamentals. If you go back to the questions we were asking, you yes, AI can design and code and show you the UI and let you iterate on it, but is it ever gonna answer the do people want it question? now, what's interesting is I've seen s a company I was working with Maybe I can name it, I don't know. I was talking with Zumba dot com recently. Do you know what Zoom you know what Zumba is, right? Hunter Harris: I've heard of Zumba. I don't remember right now what Zumba is, but I've heard of Zumba. Jeff Patton: It's a wonderful look, it's it's it's dancing to be zoom up improve Hunter Harris: yes. I do know what's about. Jeff Patton: your your your health. but they're using AI really well, but one of the things they do is if they've got an idea, they kind of expose the the the hypothesis and then they run it through a voice of the customer agent that looks at it and it has synthesized and consolidated bucket loads of customer feedback and opinions, and it kind of gives an opinion. Now what It's interesting and and what they know is it's giving an opinion. Just because the AI says customers won't like it, okay, that that that that makes it even riskier. but maybe we bet still but if we really believe in it, we'll still put it in front of actual customers and test it. Hunter Harris: Mm-hmm. Jeff Patton: Or even if the AI says that customers will love it, Just because the AI says customers will love it, that's not evidence that they love it. Hunter Harris: Mm-hmm. Jeff Patton: See, the AI is not your customer. Just because the AI loves it, it's Hunter Harris: Yeah, it's a signal, not a gospel, right? Jeff Patton: exactly and so you still need to, depending on how much risk there is with this. if you release this for this re release and it tanks your brand, that's big risk. so Hunter Harris: Oof. Jeff Patton: yes, we still need to understand the fundamentals. You still need to understand. Where risk comes from. You still need to be able to use AI to construct tests and test before you invest. AI needs to know the difference between a release to learn and a release to earn. It needs to know what to leave out, Hunter Harris: Mm-hmm. Jeff Patton: release to learn, so it can get out there faster. It needs we need to know how to either feature flag it or get it out to a select number of customers. And AI definitely needs to know how to measure out. outcomes when it comes out. I I don't know, I popped something on LinkedIn a couple months ago about our our people building stuff. that AI allows you to build stupid stuff faster, basically. I don't remember exactly what I said. And they said, Well no, somebody responded back saying, No, it helps you build stupid stuff, it helps you not do that and then further say for everything we release with AI, AI constructs a dashboard and lets us see how many people use that feature, how many people keep using that feature, and help look at distinct data about those people so they can see who's using it, how often they use it, how long they take to use it, but they plan on using AI to instrument the release to actually measure the outcomes. I see a lot of people not doing that. Because AI won't do it. It Hunter Harris: You have to ask for it at least. Jeff Patton: You have to ask for it. I don't know if AI knows what's best, but Hunter Harris: It doesn't. I I I I know that for sure. It knows a lot of things, but like to to the Jeff Patton: I know a lot of things. Hunter Harris: point of release to earn, release to learn, AI is very strong at the release to earn type stuff, like raw execution when you have a clear direction. But AI if you don't have that clear direction, you need that direction from somewhere and it's gonna be coming from a human for the time being. Jeff Patton: Y exactly. It's interesting. AI yes AI y d to make AI work for you you need to them prompt engineers when they're good at phrasing prompts AI, but it just means you need to ask AI to do the right things. And if you ask AI in a ham-handed way to do something, it will do it in a ham-handed way. Hunter Harris: Absolutely. Jeff Patton: unfortunately don't rely on the AI being smarter than you. Yes, gosh, who was it? I I remember I saw a talk a long time ago from a guy named Kent Beck, if you know who that guy is. yeah but Hunter Harris: Think so. The names for those. Jeff Patton: No, it better be. He's one of the chief agile people, the inventor of extreme programming and the inventor Hunter Harris: yeah. Jeff Patton: of the user story. but Hunter Harris: Mm-hmm. Jeff Patton: Kent is a he's a code guy. and he was and he was in this talk he was t talking about how AI creates code, but it gets progressively worse over time. It doesn't refactor it and make it better, make it more manageable, and the bigger your code base gets. AI will fix it and keep adding things to it, but it becomes a a bit Hunter Harris: Band-Aids on top of band aids on top of band-aids. Jeff Patton: becomes yeah becomes a big ball of mud and Claude does not care how many tokens it of your how much money it spends regenerating that code. so it it makes it bad. But he said look you've still gotta look at the code and you've still gotta look at everything AI does and he positioned AI as as a it's a super suit. it's just like Iron Man. Inside that Iron Man suit is a regular guy. so you need to wear AI like an Iron Man suit Hunter Harris: And I think the other thing that I wanna make sure that we return to with this thread too is it's not enough for me, for example, using AI to do execution. I need to be communicating with my customers and getting my customers' viewpoint and understanding my customer because that direction from the customer is part of what's gonna really help me Jeff Patton: Yeah. Hunter Harris: move in the right direction, right? Jeff Patton: There's a there's an old person who used to say you can ask AI to understand your customer, meaning it can it can do research, it can read through all the reviews and you can construct a voice of the customer agent who will try and identify things and and learn about your customers and render opinions on it. but there's an old person who used to say that, you know, outsourcing your discovery, outsourcing learning about customers is a little like outsourcing your vacation. You'll sorry, yeah, you'll get it done Hunter Harris: fine. Jeff Patton: faster, but I don't think that's the point. You need to learn about Hunter Harris: Mm-hmm. Jeff Patton: your customer. Don't outsource it. the real insights come from you learning and building honest to God empathy. And I promise you that you can ask your AI agent to get empathy but there will be a time ten, fifteen, twenty years from now that when we approach an Asimovian society, Isaac Asimov, the I, Robot guy. we'll be approaching that. but I don't see Claude or ChatGPT or and I'm not There's lot of other, of the Google and Microsoft and then Hunter Harris: There's a ton. Kimi, DeepSeek, mm, Gemini, all that. Jeff Patton: Gemini's yeah, Google's, but I don't see them I don't I'm not yet confident that they have empathy. Hunter Harris: I'm very confident that they do not. well, Jeff, Jeff Patton: Hey Mike. Hunter Harris: one last question. what should a team try next week for the viewers here? Jeff Patton: we should put a link on it. do I have it? what they should try next week is doing an opportunity canvas, also known as an epic canvas, for the feature they're working on right now. Do an a Opportunity on Epic Canvas because it's gonna force you to expose who it's for, what problem you're solving, what you think the outcomes are, what how you'll measure them, and you should, and how it's gonna benefit your business. And if that's hard, if you don't have answers to those questions, stop building it. and ask, how could we get answers to these questions? What could we You we've been talking about build to learn. we're talking about release to learn or the deliver to learn. Is that this is Hunter Hungary. Ship to learn. Sho Hunter Harris: Ship to learn, ship to earn, ship to burn. Jeff Patton: yeah, ship to burn. Okay. Ship or release to learn or burn, but Hunter Harris: Yes. Jeff Patton: I'll tell people look, there's a lot of the stuff we're doing isn't shipping anything, it's pay to learn. what is our Hunter Harris: Mm-hmm. Jeff Patton: team gonna spend time on to learn things we don't know? If you honestly don't know who this is for and what they're doing today that has a problem and how and what their workarounds are, I promise you you can't They're never gonna adopt it or use it if it's not better than what they do today. And if you don't know what they do today, Hunter Harris: Absolutely. Jeff Patton: that is a huge risk. So first first thing I don't want people to do is just expose your risks, understand how much risk you've taken on for your team, for your organization. Hunter Harris: I love it. Well, Jeff, I want to be a sequel of your time. Do you want to plug your pluggables? Jeff Patton: the only pluggables I've got the only thing look, I I do a lot of client work with clients and helping them move to from a project to a product model or helping them adopt a product centric thing. You should call me if you need work. But I do teach the I teach a product ownership product manager. I don't know what it is. It is a certified Scrum product ownership class. So you will get your Scrum certification. But the Scrum Alliance is not particular how ironic. The Scrum Alliance is not aligned on what you're supposed to know to be a product owner. So I get to teach what I want. It is not a traditional product owner class. it's a class that teaches the fundamentals that we've been talking about and how those fit into Hunter Harris: Mm-hmm. Jeff Patton: our agile context. You should take take a class and a lot of companies keep sending people from their company to the class because I'm there the they outsource the the training so that everybody speaks the same language. And I well I should say I am working on another book right now, but I I guess I can't say too much about that. But stay tuned working on a book that's kind of targeted at your business people to sort of beat them over the head with these fundamentals and help Hunter Harris: Love it. Jeff Patton: help your CEO start to understand that understand these things that it makes the fundamental point that your company won't succeed unless you build something that helps your customers and users succeed. Hunter Harris: Absolutely. Jeff Patton: or your company can succeed if you cheat them, but it doesn't go so well for you in the long term. Hunter Harris: Not a fan of that business model, we'll put it that way. Jeff Patton: So well a lot of companies don't do it intentionally, but a lot of companies ship products that Hunter Harris: Mm-hmm. Jeff Patton: do not work and or they certainly a lot of companies make it really hard for you to cancel your subscription. so Hunter Harris: hate that. Jeff Patton: they do a lot of things that make it hard on you that don't help you succeed, when it's in their financial interest not to. But ultimately Hunter Harris: Well Jeff Patton: Your company is more successful if your customers and users are. Hunter Harris: Absolutely. Well, I mean, I for one would love to know more about that book when it becomes available because it sounds right up my personal alley. And I wanted to like plug for you like I I did attend this course and it was fun and interesting and useful and I've been referencing it repeatedly ever since. So I the audience of one here really recommends that you try it out. like I as I said at the top of the call, I didn't realize how much of this stuff was like Fundamental to the successful companies that I worked with. And so it was very useful to me to get Jeff Patton: Yeah. Hunter Harris: a standard language for talking about this sort of stuff. Jeff Patton: Yeah, so look it maybe to to to really expand on this, Hunter, my goal isn't to teach anybody anything new. My Goal is to expose reality as it is. I what I often find is people say, yeah, I know that, but I didn't have language to explain it, and now I do. and Hunter Harris: Exactly. Jeff Patton: yeah, we do do that when things go wrong. I didn't know that was a practice. And that's what I've always thought, but I didn't the again, there's nothing new here. what we're doing is giving people language, and yeah, there is a little bit Hunter Harris: Well, there's nothing new, but it's definitely new to a lot of companies that I talk to. So we we we kinda also can't take our experience too much for granted, right? Jeff Patton: I fair enough, but I I swear I feel like I'm explaining Newtonian physics to people and you can Hunter Harris: I know that's how it feels, but man, our industry loves to reinvent stuff every couple of years, right? It's totally different this time. Everything's different, throw all the rules out the window and then the rules just come flying back in from the other direction, right? Jeff Patton: Yeah, we've redefined gravity as gravitronics and it works completely different. no, it's still the same gravity. Hunter Harris: Yeah, the fundamentals are the same and it feels like it's the same as it ever has been. The way I put it occasionally is with AI specifically, it's more the same as it ever has been, because AI's scaling the same as it ever has been, even more, Jeff Patton: Yeah. Hunter Harris: which is kind of an insane way to put stuff, but I hope people listening I hope that makes sense. Jeff Patton: Yes. To make a big problem takes a computer, to make a catastrophically big problem takes AI. So you better better know what you're doing when you're wielding it. Hunter Harris: Absolutely. Well Jeff, thank you so much for joining us. This has been fantastic. And everybody watching, Jeff Patton: Thank you. Hunter Harris: I'm so glad that you're here watching this with me, because I've been looking forward to this conversation for literally months now. I'm glad that we Jeff Patton: Well Hunter Harris: got out of the books and I'm glad that we have the opportunity to share all of this knowledge that you have with honestly a ton of people that need to hear it. Jeff Patton: Yeah, well good. I hope they're listening. I hope but for for the same reason I hope a lot of people were bored stiff because they already knew this stuff. that that would Hunter Harris: That's ideal. Jeff Patton: that would be ideal if we didn't need to talk about this stuff. But but it is what it is. Hunter Harris: But Jeff, thank you very much for your time. And everybody online, thank you very much for viewing, and I hope you all have a fantastic day. Peace.