Definitely, Maybe Agile · 2026-06-25 · 18 min
Key moments - from our scoring
Substance score
31 / 100
Five dimensions, 20 points each
Peter and Dave explore a counterintuitive trend: as AI makes it faster and cheaper to build software features, some organizations are reverting to large project-based delivery with extensive upfront design, abandoning the iterative product delivery practices that reduced business and delivery risk. The hosts argue this misses the point entirely. AI hasn't solved the core problem that drove the shift to agile - the fundamental uncertainty about what customers actually need. While AI has commoditized feature delivery, enabling teams to build at scale, it hasn't improved validation. The real opportunity is combining AI's speed with smaller, more frequent releases tied to concrete outcome metrics. Peter and Dave emphasize that organizations must maintain focus on measuring whether each increment actually delivers customer value before piling on additional features. They stress the importance of understanding your entire delivery system, establishing clear success metrics upfront, and creating feedback loops so the system continuously learns what's working - rather than delivering monolithic releases that may include 80% of features customers never wanted.
Organizations are confusing AI's ability to speed up feature execution with solving the original problem AI didn't address: validating that customers actually want what's being built. The commoditization of delivery is tempting teams to bundle more features into larger releases, but this increases business risk and complexity without improving market fit.
Project delivery involves big upfront planning and longer release cycles, while product delivery breaks work into small increments tested with customers. The key distinction is that product delivery includes validation - measuring whether customers actually want and use what's delivered before building more.
Establish a clear North Star and defined context/boundaries for what you're building, but keep execution small and iterative. The planning becomes context for AI agents, not a detailed specification; the delivery should still be tiny increments tied to concrete outcome metrics and customer feedback.
Customers can't tell which features drove their decision to buy or stay, you accumulate maintenance burden for unused complexity, and you lose the ability to quickly learn and pivot based on what actually resonates. This results in bloated products that don't solve real customer problems better than focused alternatives.
Define concrete success metrics upfront - like reducing clicks from five to four - then continuously monitor them and feed results back into the system. This allows both human oversight and AI systems to detect when outcomes are drifting and make corrections before over-investing in the wrong direction.
Our reviewer’s read on each dimension, with quotes from the episode.
There is one genuinely useful observation - that AI accelerates feature building but leaves the validation problem entirely unsolved, creating a pressure toward big-bang releases - but the rest of the episode restates standard agile product-vs-project thinking with significant throat-clearing and repetition across an 18-minute runtime.
AI augmentation didn't really touch the validation as much as it touched building and releasing features and enabled, like I think of it as commoditization or utility. You know, it's almost that getting a feature out of the door is a utility now. You just turn on the tap and it goes.
those micro changes have got bucketed up into these bigger releases because there's confidence that that release will not have the headaches that they used to have in the past
Applying the 'don't return to big upfront design' principle to the AI coding era is a reasonable and timely angle, but the underlying argument is a direct restatement of standard iterative-delivery doctrine rather than a contrarian or first-principles challenge; the assembly-line analogy is well-worn.
that logic hasn't changed just because we can do this faster. In fact, if anything, we can now do this much, much faster and in parallel.
Software actually doesn't have that, it still has a very artisanal kind of um way of working where you know solution design gets done over here and specialists come in and do their piece and it all gets stitched together.
There are no external guests - only the two recurring co-hosts, who describe themselves as working with organisations on process improvement but offer no specific credentials, named engagements, or evidence of having operated these practices at meaningful scale.
we both of us work with organizations that kind of didn't really take that on board and are still very kind of, you know, get these features out of the door
Peter Madison and David Shurk discuss the complexities of adopting new ways of working at scale
The episode contains almost no concrete evidence: no named companies, no data, no cited research, and no real case studies. The only quasi-specific example is a hypothetical click-count metric invented in the moment to illustrate a point.
say say you could you've definitively determined that uh it if uh we reduce the number of clicks from five to four, then then it was a success
we need to wait 18 months or two years before the annual budgeting cycle comes around
The two-host format produces no real interrogation: both parties agree throughout, questions are gentle scene-setters rather than probing follow-ups, and there is no productive disagreement or pushback on any claim made during the conversation.
Peter: Which seems completely the opposite of what you would expect.
Dave: Exactly, exactly and just end up with a gloopy soup thing that's not really what anybody needs.
Computed from the transcript - who did the talking, and the words that came up most.
AI is making it faster and cheaper to ship features. That doesn't mean you should ship more of them at once. Peter and Dave dig into a pattern they're both starting to see: organizations using AI-assisted development as a reason to bring back big upfront planning and large project releases. The logic makes a certain kind of sense. If AI can build faster, why not design bigger? But that reasoning skips the part that actually mattered when teams moved to product delivery in the first place: validating that you're building what customers actually need. The conversation covers why large releases make it harder to learn what's working, why feature parity with competitors is a trap, and what "North Star context" actually means when you're coordinating AI agents. The core argument: the planning layer is back in vogue for good reason, but the delivery layer still needs to be small and iterative. Cheaper to build doesn't reduce business risk. It just makes it easier to build the wrong thing faster. This week's takeaways: AI augmentation speeds up building and releasing features, but it doesn't replace the need to validate whether those features are what customers actually want.
Transcribed and scored by The B2B Podcast Index.
1 - > Peter: Welcome to Definitely Maybe Agile, the podcast where 2 - > Peter Madison and David Shurk discuss the complexities of 3 - > adopting new ways of working at scale. 4 - > Dave: Hello, Dave. 5 - > How are you doing? 6 - > Always good to catch up.
7 - > It's uh well it's been a while since we've had a chance to just 8 - > have a one-on-one chat. 9 - > Peter: It it has, hasn't it? 10 - > I I mean I'm uh it's a bit unusual, so I uh I feel like 11 - > it'd be good to dig into an interesting topic. 12 - > What do you have for me today?
13 - > Dave: I was gonna say we've had some fantastic guests in the 14 - > last few weeks that have kept us busy, and and it's always a 15 - > pleasure to have the guests coming on board. 16 - > But sometimes it's just nice to just talk a little bit about 17 - > what's going on in the world of well, the the stuff that we do, 18 - > process improvement, product delivery, getting things out of 19 - > the door in a timely manner. 20 - > Peter: Yeah, all of that kind of fun stuff.
21 - > Because uh so the what you were you were mentioning right before 22 - > this, we were we were chatting about what different areas and 23 - > different things are that are happening in the world around 24 - > us. 25 - > And you were mentioning you were seeing a rise or some people 26 - > commenting on the fact, yay, we've got AIs, let's go back to 27 - > doing projects. 28 - > Dave: Yes, yeah, the resurgence of project delivery over product 29 - > delivery, right, or agile delivery.
30 - > And I think that that's certainly something we're 31 - > beginning to see. 32 - > I'm bumping into this in a number of conversations where 33 - > it's almost like the tide has been going out for some time on 34 - > project versus product and shifting towards product 35 - > delivery, and all of a sudden, AI is enabling organizations to 36 - > put all of the plans together, big plans, and so this sort of 37 - > renaissance, if you like, of big upfront design and you know, 38 - > huge projects being delivered over longer time frames, in some 39 - > belief that this AI augmentation is going to make it more 40 - > successful than it has proven to be in the past.
41 - > Peter: Which seems completely the opposite of what you would 42 - > expect. 43 - > Um and because I mean with we know that the the reason that we 44 - > that everybody was like breaking, I say everybody, but 45 - > the the people who moved to a product delivery type uh mindset 46 - > and method were doing this because they understood that 47 - > breaking things into smaller incremental pieces, putting them 48 - > in front of a customer, because we simply don't know if what 49 - > we're building is the thing that we should be building.
50 - > So we need to get feedback as quickly as we can. 51 - > So we need to build as a complete small piece of it, get 52 - > it in front of a customer, ask, say, hey, what do you think of 53 - > this? 54 - > Get that information back and then figure out what we do next, 55 - > and then rinse and repeat and incrementally build it out. 56 - > They that that logic hasn't changed just because we can do 57 - > this faster.
58 - > In fact, if anything, we can now do this much, much faster and in 59 - > parallel. 60 - > Dave: So it's kind of like now in 3D, we can well it's 61 - > interesting when you say that because what you're describing 62 - > is first of all an ideal state. 63 - > And many of the organizations never really got to the 64 - > validation piece. 65 - > They talked about iterative and incremental, they took that on 66 - > because it reduced risk and delivery risk, but they didn't 67 - > do the business risk, the sort of, is this what the customers 68 - > like?
69 - > Is that what they need? 70 - > Are they prepared to pay us more for it, stay with us, be engaged 71 - > with us longer? 72 - > That element, there are many organizations that definitely 73 - > did go in that direction, but we both of us work with 74 - > organizations that kind of didn't really take that on board 75 - > and are still very kind of, you know, get these features out of 76 - > the door and make sure you meet the specifications that we've 77 - > agreed internally rather than validating what customers really 78 - > want and they're looking for.
79 - > Peter: Yeah, which is interesting, really, isn't it? 80 - > Because that we've we know and we have seen on many occasions 81 - > that that when you put it in front of the customer, that's 82 - > when you realize that what's actually going wrong. 83 - > Dave: Yeah, absolutely. 84 - > Yeah, yeah.
85 - > And then and then there's a whole kind of process that goes 86 - > through, and and you know, product delivery optimizes that 87 - > process, really sort of shrinks it down so you can get quick 88 - > feedback, you can build that back into it. 89 - > We don't have to necessarily go through some of the hoops that 90 - > you jump through when you're doing something in a more sort 91 - > of scaled project-driven approach where you're gonna have 92 - > to wait 18 months or two years before the annual budgeting 93 - > cycle comes around, it gets you know grouped together and 94 - > actually delivered and so on.
95 - > So there's definitely that sort of shift. 96 - > But we would, or at least that that recognition that there are 97 - > companies that aren't doing that validation. 98 - > But there's another piece that I wanted to add into that, which 99 - > you were just touching on, which is the AI augmentation didn't 100 - > really touch the validation as much as it touched building and 101 - > releasing features and enabled, like I think of it as 102 - > commoditization or utility.
103 - > You know, it's almost that getting a feature out of the 104 - > door is a utility now. 105 - > You just turn on the tap and it goes. 106 - > And so instead of going, okay, now we can do lots and lots of 107 - > micro changes and maybe look at how those changes are going to 108 - > change what our customers deal with, those micro changes have 109 - > got bucketed up into these bigger releases because there's 110 - > confidence that that release will not have the headaches that 111 - > they used to have in the past.
112 - > Peter: Yes. 113 - > And we we understand and have known for a very long time that 114 - > if you jam everything into one big packet, then you're gonna 115 - > it's gonna be much more confusing to figure out well, 116 - > which part of that big packet was the thing that did what I 117 - > wanted. 118 - > And what about the other 80% that we didn't actually need? 119 - > Um, do I still continue to add and maintain that complexity?
120 - > Because that that's the other problem you get. 121 - > The more stuff you jam into uh production, the more stuff there 122 - > is in production that needs looking after, and the more 123 - > things that can go wrong. 124 - > So we we also need to consider the the entire system, not just 125 - > the part of it that we're looking at. 126 - > And so I do find it interesting, this idea that uh the big 127 - > upfront design and planning piece of it uh is sort of comes 128 - > back into the vogue.
129 - > I yeah I think that there is a piece here where we we are 130 - > looking at the coordination of AI agents to build out the 131 - > various parts of the system, and that we a lot of that requires 132 - > much better uh understanding of the context and the design of 133 - > the pieces that we're building. 134 - > So that is 100% true. 135 - > Dave: But but that that is that is the same problem of building 136 - > cars by hand in a garage where we're all kind of tinkering and 137 - > and we're artisans building out the car and shaping the wing 138 - > mirrors to match and moving that to effectively uh you know 139 - > forward bringing on the assembly line, in that when you go to the 140 - > assembly line to move at speed, I need to think about the entire 141 - > picture of what we're doing, not little pieces of it.
142 - > And I feel that in until recently we've been able to 143 - > think about the little pieces because we never went quick 144 - > enough. 145 - > There was never really the assembly line type of model and 146 - > speed that we saw in automotive uh industry versus computing, 147 - > which is a bit weird. 148 - > Software actually doesn't have that, it still has a very 149 - > artisanal kind of um way of working where you know solution 150 - > design gets done over here and specialists come in and do their 151 - > piece and it all gets stitched together.
152 - > Now that changes. 153 - > We've talked about context. 154 - > We talked about you need to know what the big picture is and be 155 - > able to articulate that and break that down in a way so that 156 - > now all of those, the agentics side of things, the AI piece 157 - > knows what it's validating and evaluating again. 158 - > Peter: Because if you I mean, theoretically, you could say, 159 - > okay, here's my entire application.
160 - > I'm going to take that entire application, I'm going to break 161 - > it down into all of the pieces, and I'm going to spend probably 162 - > quite a lot of money uh sending it through a set of agents to go 163 - > build out all those different parts of that solution. 164 - > And then you might put it in front of a customer, and the 165 - > customer's going to go, Well, I didn't need that. 166 - > Yeah. 167 - > So you're I need this bit, but I don't need everything else that 168 - > you've given.
169 - > Yeah. 170 - > So I'll look somewhere else. 171 - > Yeah. 172 - > And I'll go find the thing that actually does what I want.
173 - > Yeah. 174 - > And they and this, I mean, this is from a business perspective, 175 - > this difference of you look around at everybody else and 176 - > say, Well, we've got to catch up, and they've all got all of 177 - > these features. 178 - > And so I've got to have all of those features too. 179 - > But if you actually go and talk to the customers of those other 180 - > businesses, and they say, Well, out of all the things that they 181 - > have, I use this one feature.
182 - > All of those other things they have, I don't care. 183 - > And they weren't, and quite often they'll say, and it had 184 - > nothing to do with why I picked them. 185 - > So sometimes we'll sometimes people will well, they'll pick 186 - > it because, well, they had 10 features. 187 - > I only actually ended up using one.
188 - > The other nine, I did entice me, though, because look, it says, 189 - > look what we've got. 190 - > Um, but if you can say, okay, so that one thing that uh that 191 - > those customers really, really like, can we do that better? 192 - > Can we do that faster? 193 - > Can we do that prettier?
194 - > Can we make that easier? 195 - > Um because then you've got something that a customer might 196 - > want. 197 - > Dave: So so as we're chatting about this, how do what do we 198 - > actually want to see? 199 - > Because I don't I don't think either of us want to see a 200 - > resurgence of project delivery.
201 - > I mean, there's a lot of reasons we we've talked about why 202 - > project delivery actually increases your risk, whether 203 - > it's business, customer-facing risk, whether we're building the 204 - > right thing, or whether we're building it right, and whether 205 - > that technical feasibility risk is being addressed 206 - > appropriately, delivery risk is being addressed appropriately. 207 - > None of those are solved with a project delivery mind. 208 - > Peter: I I think there's it you still end up in a situation 209 - > where we we've got to have a big North Star picture of where it 210 - > is we're going.
211 - > We need to have a rough idea of what are the main things that we 212 - > think we're gonna need and what goes first. 213 - > Um so we need some form of prioritization. 214 - > From that, which should be a small piece, we want to break 215 - > that down and have the agents go and execute. 216 - > If we're really unsure, one of the wonderful things we can do 217 - > now is try a couple of things.
218 - > But to do that, let's just say we're gonna pick one. 219 - > We we're good enough to be able to prioritize, and we're going 220 - > to we can build that out, we can try out multiple different 221 - > versions, we can do all sorts of fun things to experiment with 222 - > that, but we've got to have a clear understanding as we go 223 - > into that as to what is the outcome we're looking for and by 224 - > what measure, how are we gonna measure it? 225 - > Dave: How are we going to know that I was just going to say 226 - > that part of this is this resurgence of the project plan 227 - > end-to-end.
228 - > And and whenever we've worked, uh certainly my experience has 229 - > been that when you're introducing iterative and 230 - > incremental ways of working, that product delivery piece, 231 - > it's always within a container that is some form of project 232 - > plan with a beginning and a middle and an end, because 233 - > that's the longer term piece that sits within the firm, 234 - > within the company as the container within which this 235 - > product delivery is being done.
236 - > But the critical thing is that that planning or that 237 - > description of the North Star and what the goal is, that's 238 - > become context, become how do you define the boundaries within 239 - > which your agents are going to be doing their various tasks. 240 - > And that's research, it's sort of elevated to being super 241 - > important again, whereas before it's been kind of package it up 242 - > and put it to one side. 243 - > So that bit I completely see, but the problem is the delivery 244 - > piece should still be tiny and iterative and incremental in the 245 - > ways that we've always talked about, even though it's cheaper 246 - > to do it, you know, it's cheap now and you can do it at scale.
247 - > But why would you? 248 - > Peter: You don't reduce the risk. 249 - > And it should be tied to those concrete measurements of outcome 250 - > that you're looking for. 251 - > Absolutely.
252 - > So you you should be looking for that as a part of it, and then 253 - > you feed this into the engine as you go too. 254 - > But on the other end of that, you gotta think about uh 255 - > especially if you're delivering something that humans are gonna 256 - > consume, which isn't always the case, but say you are, then you 257 - > need to have an understanding of what is the rate at which those 258 - > humans are going to be able to consume the thing that you're 259 - > building, and how am I going to understand um whether they liked 260 - > it or not, or whether it's useful to them, or how it needs 261 - > to change, or what might need to be different, before I come back 262 - > and just build the next one and just basically pile more slop on 263 - > dip slopes.
264 - > Dave: Exactly, exactly and just end up with a gloopy soup thing 265 - > that's not really what anybody needs. 266 - > Which again, we're beginning to see as a consequence of it. 267 - > Peter: Um so I think I think it's a combination of these 268 - > different pieces. 269 - > Because I think I I there's a there's a part where uh it's not 270 - > about being on a soapbox about projects or not projects, it's 271 - > about thinking about your entire end-to-end delivery system, 272 - > yeah, understanding how that works, how it changes as a 273 - > consequence of bringing AI into it, thinking about how do I know 274 - > that the product that is being created, the thing that's coming 275 - > out of the end of the pipe is of value.
276 - > And how like how am I gonna tell that and feed that back into the 277 - > system? 278 - > It's that continuous learning, uh, that is the system learning 279 - > what's going right. 280 - > Because in a in an idealistically simple solution, 281 - > uh, which um if it's got humans involved at the end, it ain't 282 - > gonna necessarily be simple. 283 - > Uh, you can say, uh say say you could you've definitively 284 - > determined that uh it if uh we reduce the number of clicks from 285 - > five to four, then then it was a success.
286 - > And then that I can measure for that and I can then feed that 287 - > back in. 288 - > And the this A, I can monitor and say, oh, it's going up to 289 - > five again. 290 - > I better make a change. 291 - > What change might bring it down and then continue to improve the 292 - > system, uh, and it which is uh systems theory at this best.
293 - > Uh yeah, but that um the the fundamental um uh uh the ability 294 - > to do that um at scale in a highly complex system with many, 295 - > many levers and uh little uncertainty around what it is 296 - > going to be, and potentially humans who you may not easily be 297 - > able to sort of determine something as concrete as that to 298 - > measure that then it but you need a you need a longer life 299 - > cycle and you need a way of having that fed back into the 300 - > system and you need to think about what that looks like 301 - > because then you can start to think about okay, what I need I 302 - > need a point here where I can say, where do I now?
303 - > What needs to change about the next thing that goes into the 304 - > funnel? 305 - > Dave: Well, and that and that kind of pushes away from this, 306 - > let's group all the changes together in one big bang 307 - > release, which is I think that when we started this 308 - > conversation, we were going back to the it feels like those sort 309 - > of big projects are beginning to kind of be brought back into 310 - > they're back in vogue. 311 - > And we want to be aware that that's just because there's it 312 - > might be something that's sort of doable with the AI 313 - > augmentation, we don't want to go in that direction because you 314 - > don't solve the underlying problems, that risk problem 315 - > point that you're making about how can I create these positive 316 - > reinforcing loops where the system is and understands what 317 - > different parts of the system are trying to do and therefore 318 - > can fine-tune and optimize those individually.
319 - > On its own. 320 - > On its own, even. 321 - > Yeah. 322 - > So how do we summarize this conversation?
323 - > Peter: I I I can go first if you like. 324 - > Um so projects are good, projects are bad, they're 325 - > necessary, you know, in the sense that we need some kind of 326 - > what is the sequence of things that we can overall. 327 - > Let's have an idea we're doing. 328 - > There is still a very good case, say is don't overplan every last 329 - > little detail in every step of what needs to happen up front, 330 - > because that isn't going to get you the results you need, 331 - > because you know it already is going to have changed, so you're 332 - > going to have wasted your time creating a bunch of steps that 333 - > aren't going to need to happen.
334 - > So that's there's no value in doing that part of it. 335 - > Uh, there's there is definitely value in thinking about your 336 - > end-to-end. 337 - > So this would be my second point. 338 - > There is value in thinking about the end-to-end system and how uh 339 - > as you start to introduce uh AI into the way that your delivery 340 - > system works, what changes, like what's going to be different.
341 - > Um, and are you creating and understanding the the right 342 - > measures to be able to learn what's necessary from your 343 - > customers to inform those delivery systems so that the 344 - > product feature you're building is being built right? 345 - > But also so that you can think about what's coming next. 346 - > And over to you, I'll let you have the third one. 347 - > Dave: So here's one of the I I feel like we're we're hitting a 348 - > maturation of this the sort of life cycle process that we've 349 - > been discussing over the years.
350 - > And it's so it instead of it being a step back where we can 351 - > no longer think in terms of product and we can go back to 352 - > thinking in terms of project, I think that's a retrograde, 353 - > retrograde step. 354 - > I think what we're actually seeing is that as the 355 - > technology's changed, as things are progressing, we've now kind 356 - > of bringing together the two sides of it, that big picture 357 - > piece of project. 358 - > That one is back in vogue, correctly so, is driven a lot by 359 - > this sort of need for a holistic North Star context-driven view 360 - > of the systems and what we're trying to create.
361 - > But then coupled with that is the fact that delivery still 362 - > needs to be this small iterative. 363 - > So you're bringing the best of the product delivery world 364 - > coupled with the best sort of long-term perspectives that you 365 - > get from a project world rather than letting go of that product 366 - > delivery. 367 - > You still need that muscle, you still need to be able to use 368 - > that. 369 - > In fact, it gets easier when it's structured correctly, but 370 - > we want to dovetail that with the project view.
371 - > Peter: Sounds good. 372 - > Dave: We've done what we can. 373 - > Peter: Uh, with that, well, it's a pleasure as always, Dave. 374 - > Always uh good to uh chat about these things.
375 - > And uh I look forward to next time. 376 - > Right, until next time. 377 - > Thanks again. 378 - > Thanks.
379 - > And uh to all of our listeners, don't forget to hit subscribe, 380 - > tell your friends about us, and uh send us a message of feedback 381 - > at definitely maybeagile.com. 382 - > You've been listening to Definitely Maybe Agile, the 383 - > podcast where your hosts Peter Madison and David Sharr focus on 384 - > the art and science of digital, agile, and DevOps at scale.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
S2E3: Navigating the Intersection of Product and Marketing with Austin FullerProductly Speaking: Real Stories for Product Managers · on Feature prioritization65 / 100
Ambiguity Effect: The Hidden Reason Your Roadmap Keeps Playing It SafeBeyond UX Design · on Feature prioritization54 / 100
Stop Putting Features on Your Roadmap#HowIPM · on Feature prioritization43 / 100
Building a vertically integrated Saas business from day 1 w/ Sean Stavropoulos @ BoulevardEngineering Founders · on Feature prioritizationOrganizational Honesty in Agile Teams66 / 100Data, AI, and Knowing When to Let Go - with Tommy Cotter81 / 100AI Adoption Starts With How People Think, Not Which Tools They Pick - with Royce Sin81 / 100What Organizations Get Wrong About Junior Engineers and AI55 / 100AI in the room, helping non-technical teams actually use it80 / 100