Episode 6: Is Waterfall Back? With Mike Cohn

Brian Milner (00:23) Hello, hello, welcome everybody. we are back here for another episode of People Over Prompts Podcast. I am your host, with you always, Brian Milner. this is the podcast where we talk about the future of teamwork in the age of AI. And today I have Mike (00:38) No. Brian Milner (00:39) a very, very special guest with me. I have Mr. Mike Cohn with us, the one and only. Welcome in, Mike. Mike (00:43) Thanks for having me, Brian. Brian Milner (00:44) really glad to have Mike here. a huge favor. I'm really thankful for him coming on. if you haven't crossed paths with Mike, then first of all, where have you been? But second of all, just to give you kind of the background, if if you come you know from from some other parts of the industries or whatever, Mike is a co-founder of the Scrum Alliance and the Agile Alliance. he's the author of three really huge books: User Stories Applied, Agile Estimating and Planning, and Succeeding with Agile. Mike is you know one of the The godfathers of the Agile movement, and brings a lot of that history to the table here. but just in case anyone feels like maybe Mike's an AI skeptic or you know from a different time period from this or anything, he's not at all. in fact, he had a blog post that he put out just this year where there's a there's a free AI prompt pack that he has available from that, where you can you know find prompts for personas, user stories. user interviews, backlog generation, acceptance criteria. and and even his Better User Stories course now includes an AI toolkit trained on his teaching. So he's he's really on board with this stuff and has been using it in his own business as well. but I wanted to have Mike on because there's sort of this this echoing theme that I've heard based on the way that we're We're using AI and these these teams that were there we're kind of human slash AI teams, where I I've heard this echo of Waterfall is back, baby. that sort of we have we're back to this era of waterfall a little bit and what we're trying to do. So first of all, Mike, is Waterfall back, baby? Mike (02:27) Waterfall is back, baby. No, no, no. you know, here's here's the thing with waterfall. I used to get into these discussions about Agile with people and they were like, you know, we don't really like Agile. And I'm like, well, you know, go on Amazon and buy the best book on waterfall. And here's the thing: there isn't a best book on waterfall. Nobody who truly knows a lot about software development advocates true waterfall. It's just not a viable approach for doing something kind of in the complex domain of of software development or product development more generally. And so, you know, you can't really now maybe you can today go on Amazon and Google a waterfall book. There's, you know, probably something by now. But I mean, at least a handful of years ago, there was not, you know, the, you know, waterfall guide to development or something like that. There just just doesn't exist. And the reason for that is. I think people really misinterpret what waterfall was meant to be. And I started my software development career in the early 80s, kind of professionally by 84. I was working as a programmer. And the company I worked at, I was hired to do some C programming, very early in C programming days, really. And everybody in the company had to go through this COBOL class. And in the COBOL class, we were taught about how to code in there, but we also taught how to design the systems. And we were being told we were literally going to be limited to three compiles a day, right? You know, because the mainframe was always so busy running the banking system. You had three compiles a day. And so you wrote all your code, you did all these fancy designs up front. And you know, you preserved your three compiles. And some of the people teaching the class were really proud they'd keep track. Of how many days they could get by with two compiles in Brian Milner (04:15) Mm-hmm. Mike (04:16) a day. And so waterfall is really this approach to development where you get a step right before you do any of the next step, right? And so I had to get my code right before I could compile it, right? you know, you wouldn't even test a compile and say, I missed a semicolon here, right? and so waterfall involves doing All of the analysis up front, all of it, not most of it, not one section all the way, but analyze the whole system, then do all of the design, right? Then do all of the coding, right? Then do all of the testing. And that's what true waterfall is, and you know, sometimes gets referred to as a stage gate approach. And nobody's gonna do that, right? I mean, that's no one's gonna build anything that way. It just doesn't make any sense. Brian Milner (05:03) Yeah. Yeah, I mean I I I agree. I d I don't really see anyone I mean, I I remember back when you had the April Fool's Day joke of you know, the first annual waterfall conference is coming. and I I remember getting a real kick out of that when I saw that. yeah, I mean I I don't think there's anyone who's who's kind of advocating, hey, let's pull that that white paper from nineteen seventy, whatever, and say, let's follow this process exactly. But I mean, I do think there's an element of truth to it in that there there is sort of this return. With with things like spec driven development where people are, you know, when you when you build things with AI, you're you it it's smart to have a spec that you build bef and and have that be something you can refer to and point the AI to and say, hey, make sure you read the spec 'cause That's what we need to build. So I think there's a danger maybe in there of of that return to it. how do I mean what's your opinion on that, Mike? I mean, how much is too much? How much of of capturing information there is is too much information? And what's what what should people really try to avoid if they're using that approach so that they don't fall backwards into kind of pure waterfall? Mike (06:14) I it I think what it has to do with the the effort involved in coordinating development now, right? We're coordinating development between a developer of some sort sitting at the their desk with an AI, presumably with other team members. And when we're gonna coordinate things, even if it's just between me and my computer, I open up Chat GPT and I wanna I wanna do something. I have to coordinate with that. And that's going to require more, call it documentation, right? And we have to write more. you know, you know this. I've spent a lot of my life telling people to write less, talk more. This has been kind of my thing with in agile development. Just write enough down that we can go have a good conversation. And that does get flipped around when what I'm writing down is essentially instructions to a computer, right? I'm giving the computer the instructions. And I'm going to write more down. I'm going to be more explicit about the behavior I want, or who knows what I'll get, right? So I think we have to be more explicit with those things, but we're not going back to waterfall, baby. What we're doing is still incremental development. I'm going to build one part of this thing. It might be a big part because AI can help me a lot, but it's still a part of a system. It's not the whole system. And so I'm going to build a little part of that. And when I get that, Call it done, but maybe it's not all the way done. It's close enough. I move on to the next part. Right. And so I write a specification for that part. Then I go back and I change the previous part. And so we're still having conversations with an AI instead of with the stakeholder or with a user. And we're still having those conversations too, but there's still conversations and we have to document those things. We do it in the form of the prompts that we give to the computer. So it's Being explicit enough to get out what we want, just like it always was in a conversation. Users had to be explicit in telling us, you know, I want this, this, this, right? And we'd ask questions and we'd go build the thing. Brian Milner (08:04) Yeah. No, I I really love this and and I think you're getting to the heart of I you know, one of the things I I've been trying to focus on with this, and that's kind of the purpose behind the things that we do. And, you know, I think you even addressed that a little bit with Waterfall into, you know, like why was the what was the purpose of doing stuff like Waterfall and the history of why we would do that in the first place. And I I think that's important to understand here as far as communicating with a an AI agent of some kind. is that it's it's a form of communication. And you know we we've tried to solve the problem of communicating with developers in different ways over the years. I mean you're you're an expert in that area when we talk about things like user stories. that was you know a a means of of relaying information Mike (08:52) Mm-hmm. Brian Milner (08:53) to human developers that was really excellent at what it did because it pushed it more into conversation. so that that's kind of the curious part now is the conversation is with a an AI agent, it's not with a human. So how do I mean I'm just obviously we're speculating here. We're talking about things, but in your opinion, how does that shift? How does that change when you're you're trying to relay information? You y you know, you can't really promote a conversation you know, with an agent. It's only gonna do what you tell it to do. Mike (09:24) Yeah. I think with the for me, the way I think about whatever AI I'm working with is I think of them as probably my most intelligent coworker. Because I'm I'm amazed at how smart they are, right? I mean, things that I that I can ask in in a lot of domains it's pretty darn smart. I was picking out a while was waiting to get started this afternoon, I was looking at buying a new surfboard. And so I'm using AI to help me, you know, what nose shape to Brian Milner (09:49) Yeah. Mike (09:49) own my surfboard. And so it's this, it's the smartest coworker that you've ever had, but it's also a junior intern in that it is just gonna make some wacky mistakes, right? Just gonna just weird things. and I mean I have this example unrelated to kind of software development, but I was trying to pick out some I think it was like checkbooking software. I'm trying to replace quick and for out of my life, but it's not really good. Kind of desktop software. I wanted something more web-based. And I was looking at two or three different products. And it came up with this idea that I was already a user of one of the products because I'd asked it questions about that product like six months ago and it remembered the chat Brian Milner (10:29) Yeah. Mike (10:29) and said, well, because we're already using this, I wouldn't make a switch right now. I'm like, I'm not already using that. I asked you questions about it, right? And so it's this really, really smart junior intern. And we have to, we have to treat it that way, meaning we have to give it. more instructions, you know, because it's that junior intern. but we can expect really amazing output when we do because it's the smartest coworker I've ever worked with. No offense to all my past coworkers. I'm picturing them all being offended right now because I've worked with some really smart people. Brian Milner (10:59) Yeah, I mean Mike (11:03) But all of my smart coworkers have never been able to write code for me and recommend surfboard nose shapes at the same time. So Brian Milner (11:10) No, I mean they c that's the thing, is you can't be an expert about everything. that's that's kinda the limits of humanity is that, you know, we we are experts in certain things. But, you know, since AI is connected to everything, like it really can be an expert at everything and it can help you understand things that maybe you wouldn't normally think it could help you understand. so yeah. Mike (11:27) Yeah. Yeah. I I do a lot with the prompts of trying to give it a, you know, a decent start, right? I mean, I wanna, you know, think of myself as a smart guy, thank myself as a writer, so I can probably write a smart prompt to start with. but I do a lot with you know, the agile principle of iterate, right? So I will give it a prompt, I will ask for feedback on my prompt, do that a couple of times and then ask it to develop the thing that that I want built. We're doing some rework or revision. We're rebuilding our whole website right now. And so we're doing that. We're using completely new technology to any of us in the company. And so I'll ask it how to do things and I'll ask it to improve my prompts for me. And it it's never come back and said your prompt's perfect. Right. There's nothing I'd change. So iterating over the prompt with it has been extremely helpful. Brian Milner (12:16) Yeah. Yeah, it it's it's it's definit i it for those of us who've mostly work with human teams, it's it's definitely a a a paradigm shift to think about some of the things that we've learned over the years of this is the best practice and this is the best way of doing things, to now shift that and think, well, what's the purpose behind that though, and is that purpose still even necessary? you know, I think about sort of the the three C's from Ron Jeffries about you know, card conversation confirmation. And when I think about that kind of thing in the light of communicating with an AI, I I think card is still relevant because it's, you know, the principle of trying not to capture every last detail, but having placeholder information that you can then expand on over time. Mike (12:59) Yeah. Brian Milner (13:02) the The confirmation, the last part of it I think is still relevant because I do think it's still important to test to make sure that you actually accomplish what you needed it to do. It's that con the conversation part of it in the middle that I I'm struggling with a little bit in today's world because as I as I said, you can't really have the conversation. It's not going to proactively reach out to you and say, hey, I was building this and I had a question about this. Mike (13:17) have the conversation it's not proactively reproductive and say, I was building this and I have a question about this. I I think that's you know for me the conversation is the back and forth with the AI, right? You know, whether I'm asking it to improve my prompt, whether I'm asking it to build a thing and show it to me, those those are part of the conversation, right? Conversations are about clarifying assumptions, making sure we're in agreement on things. And you know, human language is just so imprecise, right? One of the things I used to show in class all the time was this photo of somewhere in England. it was a photo of a trash bin. And there was a sign on the trash bin that says, if your dog does a poo, put it in the bin. And there's a picture of a guy basically dropping his dog in the pin, right? If your dog does a poo, drop it, meaning the dog, in the bin. I mean, that's literally what that sentence says, but it's not what anybody meant. I had an example where I wanted to do an event and I needed to rent a hotel room, ballroom to do the event. I emailed my assistant and I said, you know, see if you can book the the it was a Marriott hotel in Denver, book the Marriott for me by June 7th. And she emails back and says, The hotel's booked. I went about my business, right? The hotel's booked, right? She's done. She finally contacts me about two weeks later and says, Mike, what do you want to do? The hotel's booked. You can't have it. Right. Brian Milner (14:36) Ha ha ha. Mike (14:37) How how was I to know that's what she met, right? It's not her fault, but I mean, you know, it's but that's how imprecise language is. And so it's why we have to iterate, why we have to have the conversation. It's not just one directional. It's not one shot. we iterate over it. And you know, you're talking about card conversation confirmation. Maybe we swap card out for clawed, right? So it's clawed conversation Brian Milner (14:57) Ha ha ha. Mike (14:58) and confirmation. So keep the acronym. Brian Milner (15:00) Yeah. Yeah, I mean it Yeah, yeah, right. I mean I I think you still I think I know I still benefit from the conversation with others around things and talking through the ideas and you know, the the more humans I can bounce the idea off of the better. but I I I I think the the other side of that is is sort of, you know, the the the spec itself that we now have like a spec dot md file that the Claude would reference or something like that. it's it's not a it's not the fact that it exists that's the problem. I think the the problem is that even some of the AIs, when they help you build a spec file, will try to waterfall it up a little bit. You know, they'll try to get you to identify every last element of it. And that I think can lead us to the the misperception that Now it's done and it's it's frozen and it's complete. so I mean when I compare that to things like user stories, were user stories ever looked at as complete specs? were they ever supposed to encap encapsulate everything that you needed to do? Mike (16:08) Well, when I wrote my book on user stories applied, and I wrote it in 2003, came out in 2004, use cases were kind of a common approach among the kind of savvy development world. Other people just, you know, did this system shall documents, IEEE 830 documents. But use cases were fairly popular. And one of the points I made in my book about a difference between use case and a user story was a use case model was meant to be complete. It was meant to be something you could look at and go, I've captured all of them. There is the entire set of requirements. And no one would look at a hopefully no one would look at a Scrum Teams product backlog full of user stories and go, there they are, there will never be another Brian Milner (16:48) Yeah. Mike (16:48) one. and part of that was because the the level at which they were written. I remember talking to Grady Booch, one of the originators of the UML method. And very involved in use cases after Ivan Jakobson had started them. And I described a system to him that a team I had worked with had just finished building. I asked him, how many, you know, use cases do you think? And this is just, you know, hallway conversation at a conference. So don't take his number too literally. but he said probably 15, right? now, you know, let's multiply that by 10, just for fun. Let's say, you know, if I'd given him more detail, maybe what is that 150? these guys had over 4,000. use cases for that system. And so they had just gone nuts, right? They'd just gone nuts with overspecifying things. And so a use case model, if you have 15 of them, yeah, you can say you've got everything because it's at a high level. If you've got 4,000, you haven't thought of everything. There's there's gaps in there. And so user stories were meant to be at a much smaller level, meaning we're never going to have all of them. They were meant to be just enough to make the next round of progress. And That does fit a bit with what we're doing now, where it's these kind of iterative waterfalls where I build a little bit. Brian Milner (18:02) Mm. Mike (18:02) I use kind of a mini waterfall to do that. I do another one. And so is waterfall back, baby? Maybe if we think about it as a very iterative waterfall, build a part of the system using specs, get the spec perfect, build the system, test it. Right? It's back in that sense, but not in the grand sense. Brian Milner (18:18) Yeah. I've read some work that and I'll try to I'll I'll find the link to this so that I attribute the right person, but this this one framework out there is calling him Cascades now. So that's a series of cascades. not one big waterfall, but you know, basically describing it in an iterative manner that it's a series of these small waterfalls, rather than one big one. And I I mean I I I appreciate that. I I get the idea behind it. maybe it's just my bias of of the term waterfall that makes me want to run away from that. But you know, I I think that everyone's recognizing that there's a need for iterating. it's not a either-or thing. It it's sort of, you know, they complement each other when you do that. doesn't matter if you're working with a computer or working with humans, it's still small little iterations that that are useful. Mike (19:07) Yeah. Yeah. You know, and you know, if we think about it at an extreme, we always kind of work in a waterfall. I'm not coding and designing and testing at the same time, right? I mean, I'm doing one thing maybe for 10 seconds, but I'm doing one thing at a time. So but one thing at a time isn't waterfall. Waterfall was where I do all of one step before I do any of the next. That's waterfall. That's bad. Nobody who really knows what they're doing with development does that. Nobody's gonna go spec an entire non-trivial system and say, I'm done. There's no more specification needed. I can give the prompt over and I never have to touch the prompt again. Brian Milner (19:38) Yeah. I mean I I I actually my my own kind of failure bow here a little bit publicly, but I was working to build something with with some AI agents recently and you know we had a a spec document that they were working off of and I tried to keep it very lightweight so that it was the stuff up front, you know, kind of the the top of the backlog, if you will, I knew more information about further down I tried to keep it light. But as we went on, then we would change things and I would say, I don't like that. It needs to be this now. And you know, now that I see it, it needs to be this. And I at one point, one of the agents actually reminded me, we probably should go back and change the spec document. And I thought, well, that's kind of a kick to the a punch to the gut, you know, like the the have the AI agent have to remind me to go back and and you know update the documentation on it. But I I think it's a good reminder that, you know, that we we get so caught up in things sometimes that we kind of forget that Hey, that that document should be a living document. It shouldn't be something that we just finished at the start and Mike (20:37) Yeah. Brian Milner (20:37) obey, you know. Mike (20:38) Well, and that's the type of thing that AI is gonna always do better than you or I at remembering to do those things, right? So Brian Milner (20:44) Yeah. Well and so I I kinda wanna get your your your take on this, Mike, 'cause in the last episode I talked a little bit about the dimming cycle in relation to all of this. And by the way, another failure, Bow, because I was so caught up in the first two that I got the the back half of that out of order when I described it. So anyone who's an expert in that area made a coolpla. Mike (21:03) the plan do you check act? Brian Milner (21:05) Yes. so I g I I kinda reversed those last two. but, you know, I I think Mike (21:10) What's a ready ready fire aim? Right. Brian Milner (21:12) Right, right, exactly. Exactly. but the plan I I I think it's kind of interesting because we're what we're talking about is the planning part of it, of planning what it is you're going going to do. And you know, I was saying last week that kind of the the the the doing was so expensive previously that the planning had to counterbalance that and we had to invest more upfront in the planning, but now the doing is so cheap. The the planning needs to come down and we need to, you know, counterbalance it for what it is today. And I'm just kind of curious what your thoughts are on that. How d how do you think the the dimming cycle changes or adjusts in this AI world? Mike (21:49) Well, I mean, Deming's a genius for having, you know, labeled that and noticed it, but I wouldn't say it's something he invented, right? I mean, you know, Brian Milner (21:56) Yeah, yeah. Mike (21:57) you know, the the first caveman planned a fire, right? So, you know, did the fire, checked it and said it wasn't hot enough, you know, and and acted, right? And so so you know, Demi named it and you know, absolute genius, but it wasn't like he before him there was no plan do check act, right? And so know it it still exists. It's what we're talking about here with these iterative waterfalls, right? Plan a little bit Brian Milner (22:19) Yeah. Yeah. Mike (22:20) a little bit, do it, check it, see how it worked, and react, right? Do it, do it differently, change it, go back to this the prompt or, you know, have a new prompt that revises it. So that cycles, I mean that's just part of of humanity, I think. It's how we do anything. So I don't think that necessarily changes as as we go about AI driven development. Brian Milner (22:40) Yeah. I I mean I I I definitely think it's the the the the expensive part is shifting in those four things. And it it feels I I don't know if you agree with me on this, but it feels like the check Mike (22:52) totally. Brian Milner (22:52) the check part of it is the the expensive part now, you know, because yeah. Mike (22:55) absolutely. Absolutely. I mean, go back to go back to what I started with, you know, early at the beginning where I was talking about I was allowed three compiles a day, right? by Brian Milner (23:02) Right. Mike (23:03) the way, I got around that. I was on a compact luggable computer, one of those. And I wrote a program in C on my compact. No, it was in basic, wrote a program in in basic on my compact that would analyze my COBOL code to make sure it was fine. And so I didn't need to ever waste compiles. So I got to tell my instructor that I used one compile a day and beat his average of two. but you know, if we go back to to that, that's that was ex doing that because the coding was expensive, right? The the processing time was expensive. And what you're saying is that we're seeing the economics shift. And the expensive part now is kind of not even the checking part. It's really the figuring out what to build part. Brian Milner (23:48) Mm. Mike (23:49) And so You know, we have to make sure that we're building the right thing. and we do that up front and we do it by checking ourselves, by checking with our users, because it's fairly straightforward to build stuff. Not everything, but it's getting cheaper to build things. But it's not getting cheaper to talk to our customers necessarily. It's a little bit not dramatically. So the cost center is changing. Brian Milner (24:11) Yeah. Yeah, I agree. And I mean I I I I I think that knowing what to do, i it's kind of an interesting paradigm flip. And I I'm I'm kind of I've been noodling this idea a little bit as well, in that if the if the do part of it gets cheap enough and you know essentially gets down to almost zero, then you have to kind of question the the time, the investment into figuring out the right thing to do. And and kind of wonder like is it is it is it worth it at a certain point just to do a bunch of things and throw spaghetti at Mike (24:44) Do and show Brian Milner (24:45) the wall, you know, and see what sticks. Yeah. Yeah. Mike (24:47) Yeah, do it and show it, right? Do it and show it and see what your users think. Right. So, and that's you know, that's how we would figure out what the, you know, what is the spec, right? When I remember when I was getting my masters in CS and I was looking around at like, what did I want to do it in? What did I wanna study? I came across all this information on formal specification methods. And there was one called Zed that Michael Spivey wrote a lot about and Another one called Vienna Development Method. But there were basically these like mathematical notations for a specification. And you'd write them in these formulas. And I tried doing a few systems that way. And it was fun because my brain kind of goes in that direction. but it was really tedious. But you when you finished the specification, it said exactly what a part of the system needed to do. And there was no misinterpretation, right? You couldn't misinterpret it because it was mathematical notation. but it was. Incredibly expensive to do that for something like, you know, you know, let me search for a book on Amazon, right? You'd specify that. It would take you days to write the specification, but there'd be no miscommunications. but the cost of those min miscommunications has come down and they're coming down further again, meaning we can make those mistakes because we can recover from them so quickly in most cases, right? We can't do it, you know, medical software, whatever. You gotta, you know, you have to be safe, but we can recover from mistakes pretty quickly. Brian Milner (26:07) Yeah, we can't we can't throw ten ideas for how to fix your insulin pump and then say, Well, one of them will work you know. Like we need to know which one it is. Mike (26:14) Yeah. Yeah. Well we we could we c we could come up, you know, we could generate ten ideas and we could, you know, gen you know, build three or build ten insulin pumps and see which one works, right? I mean, you know, that's Brian Milner (26:25) Yeah. Mike (26:25) that's something that's possible. So it's possible to have multiple approaches, but we, you know, we can't we can't sell them all and see which one sells. Brian Milner (26:33) Yeah. Well I I I I'm I'm really I really want to get your your take before we run out of time here, Mike, because I I know you've been Mountain Goats d really dove into the idea of AI and how it's changing software development and you've published the the AI prompts and on all those things and the assistant and stuff that people can can get from working you know, y I think anyone can just get that going to the the Mountain Goat website. but I I'm curious about your own personal kind of interactions and experiences working with AI and where where has AI genuinely changed your own practice? you know, w where has it disappointed you and where has it exceeded your expectations? Mike (27:13) I don't think there's any, I'll start with the disappointments. I don't think there are any true disappointments. There's more kind of the I'm shocked that you couldn't do that type of a thing for five minutes, right? And then I change it and it and it does it. But it's, you know, it's kind of shocking at times when it when it won't do something. Like I had a I mean, and they're just stupid things at times. Like I was trying to change some video thumbnails for YouTube, right? I have some really bad ones. I was trying to change them. And I said, you know, hey, here's a file folder of a bunch of photos of me. Pick one of these and put it on here and just, you know, change the title. and it comes up with a guy that looks a little bit like me, Brian Milner (27:50) Yeah. Mike (27:50) but it was kind of like a cross between me and Walter White. and it was like, you know, I'm like, dude, I told you to use this folder, right? so those are the type of disappointments, little five minute things, right? It's like, okay, something there didn't work. But those are examples what we're talking about, where we're you know, misspecifying, you know, but you've seen this where it comes back is like, sorry, that one's on me. I, you know, thought I could do this instead or something, right? So those are the only disappointments. The things where it's really impressed me is the the speed at which we can develop things, the speed at which we can change things. you know, you think about the the old days where you would hear about, you know, cost to change curves and, you know, it was a thousand times more expensive to fix something after it was tested. Right. It was literally the the number. if you caught it in testing rather than if you caught it during specification a thousand times more expensive. That's not true anymore. Right? That's not true anymore. I make a mistake in the spec. It might have been faster to make the mistake in the spec, see it and fix it now. And so it's very easy to fix things. And so that cost of change curve has been flattening for years. That's something I've talked about for a long time. But it's really flattened again. And that makes it very easy for us to change systems. So that part's been exciting for me. I've been happy with something we haven't talked about, I've been happy with recording stakeholder interviews, discussions, Brian Milner (29:16) Mm-hmm. Mike (29:17) you know, just the random Zoom calls, putting those into the system and then being able to ask the AI, I'm thinking about one user I'm working with named Jessica, what would Jessica think about this? Right. You know. and then I can ask it how confident are you? And it'll say, I'm, you know, eighty percent confident. I was like, Okay, I'm not gonna bother the real Jessica. I'm just gonna do this thing and show it to her. And so being able to train AI on our users so that we can get real feedback from them has been helpful. So Brian Milner (29:46) Yeah, I love that. And I agree. I I've done that as well with some clients where I've been able to feed in multiple transcripts of different interviews Mike (29:53) Mm-hmm. Brian Milner (29:54) or even you know recently been able to take like, you know, ten, fifteen research papers on different topics, throw it in somewhere and say, you know, what is it what does the research say about this, you know, or, you know, what what's its take on this or give me some interesting facts about or anything like that. And that's what I I've been really impressed with as well, is it it does a great job of surfacing those things that we might have otherwise missed. Mike (30:17) Yeah. I guess one other one other thing I'd say where I'm just kind of maybe disappointed or surprised is that none of the AIs are ever happy with their own work. Right. They'll they'll do something and then you ask for it to critique its work and it'll give you some suggestions. But if you keep doing that, it'll just keep going and going, right? And they're not and and it'll start to switch back at times. And there was this old TV show with Penn and Teller, the magicians. And they did an episode where they brought in somebody to feng shui a room, right? They, you know, move the furniture and they guess, okay, this is all perfect now. And then that guy left and they brought in another feng shui expert. And they said, okay, feng shui the room. And he moved it literally back to how it was the first time, right? so, you know, it's like, so, you know, I'll have a design, you know, mock up of some pages that we're doing, and we'll say, Okay, what do you think about this? And you know, you think it would at some point go. Damn, that's good. I leave it alone, right? Brian Milner (31:14) Right. Mike (31:14) And it's like, nope, it'll just keep making changes. And I guess, you know, I guess in some concept that makes sense, but I don't know. I kinda wanna be told at some point that what I did with its help is good enough and it never does. So Brian Milner (31:28) Yeah, yeah. Well I mean it it's it it's self interest is to keep you on the hook, keep to keep you going, right? So Mike (31:35) I guess so. Wants me to spend more tokens. I don't know. I I don't know if that's it or not, but it's just, you know so I was like, here's one more thing and I'm like, You told me the opposite a half hour ago. So Brian Milner (31:44) Yeah, absolutely. Well, Mike, I can't thank you enough. I really appreciate you coming on. This has been really fascinating and it's always great to hear from you. But thanks for thanks for sharing your insights in this area and helping us kind of navigate these muddy waters. Mike (31:56) Thanks for having me, Brian. It was a joy. Brian Milner (31:58) Well, a huge thanks to the one and only Mike Cohn for coming on the show. I really appreciate my former boss being here and and talking with us. Mike's been doing this for such a long time and he's seen the evolution of this over the years. And as far as I'm concerned, there's there's no one better. There's no one in a better position to have this conversation. So I'm I'm really thankful that he he came on and got to share some of this stuff. Check out our show notes, it'll be on my website at agility evolve.com slash podcast. You'll find the show notes for this and I'll put some links and so some of the things we've talked about as well as to Mike's site and you can find that there and you know we talked about his his offer there where you can download some prompts on different things. So I'll make sure that there's a link for that if you're looking for that. you don't have to s furiously scribble anything down here while you're listening. listen, I I know your time is short. I've got three things for you here, and then we'll wrap it up. like, tell, and email. First of all, like and subscribe. if you haven't done that yet for this podcast, that really is helpful. We're still in the early, early days. This is just episode six. And we're in that point where it it's important for us to try to find if there's an audience for this. So if you like this and want to continue it, then please like and subscribe to it. That will help us continue to do this and get found by others. tell others. Tell somebody, a coworker, a friend, anyone you know who might be interested in this, tell them about this. I'm not advertising anywhere else, I'm depending on your word of mouth. So yeah, if there's anyone that you think, hey, this space is kind of a unique space. We're talking about how teams work in this AI era. and we're gonna cover the gamut. We're gonna talk about the psychology, the sociology of it. We're gonna talk about the di the interpersonal dynamics and And all of that stuff is going to be part of our conversation. So if you're looking for that, then I think this is probably the best place for you. I hope it's the best place for you. Lastly, email. Email me if there's anything you want me to know. You can email me at Brian at agilityevolve.com. It's Brian with an I at agilityevolve.com. And give me any feedback on the show, anything you want to tell me about it, if you have any potential guest or topics you want me to cover, then please do send that to me at my email address. I love hearing from you. That really is something that makes my day. and I promise you you'll get a reply from me. that's not some form or going to an assistant or anything that comes straight to me. So email me directly, Brian at agilityevolve.com. And that'll wrap it up for this week. So hope you're having a great week, a great month, great summer. And we'll talk to you next time on another episode of People Over Prompts Podcast.