If AI is speeding up how fast we can ship, what’s slowing teams down now? Brian and returning guest Cort Sharp dig into the emerging friction between AI-assisted development and the still-slow art of product decision-making.

Overview

With AI accelerating software delivery, it’s no longer the developers dragging their feet. It’s the backlog that’s backing everything up. In this episode, Brian and Cort tackle the big shift: as coding becomes faster and easier, the real challenge becomes knowing what to build, why, and whether it’s worth it.

They talk about feature bloat, the myth of productivity, the “good enough” curve, and why product owners are quietly becoming the most critical role on agile teams. Plus: short sprints, fake one-day sprints, and a healthy dose of “what even is a Sprint, anyway?”

If you're feeling the tension between building faster and deciding smarter, this convo’s got your name on it.

References and resources mentioned in the show:

Cort Sharp
#104: Mastering Product Ownership with Mike Cohn
#3: What Makes a Great Product Owner? With Lance Dacy
#164: Why Innovation Efforts Fall Flat with Tendayi Viki
Get the Agile Skills Video Library Use code PODCASTSKILLS for $10 off
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back Agile Mentors. We're here for another episode of the Agile Mentors Podcast. I'm with you here as always, Brian Milner. And today I have back the one and only Cort Sharp with us. Welcome back Cort.

Cort Sharp (00:11)
Hey Brian, thanks for having me.

Brian Milner (00:13)
Yeah. Cort and I were chatting just in between engagements and things we were talking about going on. Cort's coaching a lot recently, and I've been coaching a lot recently as well. And so we've been kind of sharing stories and talking about kind of some of the things we've been experiencing. And you came across something really interesting recently that I thought we talked about might make a good topic. help us out. What was that that you came across?

Cort Sharp (00:42)
Yeah, so I've seen this idea pop up a few times actually on LinkedIn specifically, but I've seen it trickle out into other areas within the coaching that I've been doing recently, but also just in other pieces or parts of the internet as well. And it's this idea of like with AI being brought into organizations, brought into companies, helping out developers so much that AI has actually lowered that barrier. for the programming side of stuff, programming side of the development side of things, that the new blocker that is currently emerging, so the new piece that's been slowing everyone down now is actually the product management side of stuff itself, which I thought was just so fascinating because I've done a little programming, definitely more in the product management side of things now, but I kept seeing this pop up and I was like, man. I would love to just hear, you know, Brian's thoughts about this and the community as a whole, everyone's thoughts about this a little bit here too, but I have my own thoughts, but just quick little immediate reaction to that idea there, Brian. How does that make you feel? What do you think of that?

Brian Milner (01:51)
Yeah, I actually have been thinking this was coming for a while. I don't have this prepared, so please don't get me wrong in this. I know I always say data didn't happen. But there are three studies that I found at one point that were trying to determine the number of features in just your average software project that were rarely or never used. And it was three separate studies spread out over years. And one of them was like 48%. That was the low one, was like 48%. Then there was a middle one that was 64. And then there was another one that was more recent that said like 80%. And I mean, think about that, know, like I, even if you take the low end, And so, you know, 48, let's just round it up to 50 just to make it easier to have the conversation. But let's just say out of those three studies, we say it's 50 % of features that people are building are things that people rarely or never use. Now I get it that there are some rarely used features that are essential, right? Like admin functions and things. You may not use those all the time or it may not be a huge swath of users. that uses that, but you have to have them. So set those aside because that's not 50 % of what's being developed, right? And I think if that's true, if we even like go on the low end of that and say that it's closer to 50%, then that's an awful lot of productivity that's being lost. Not to mention just money and energy and effort. of developers to build stuff that no one cares about. Those studies were all prior to AI. So let that sink in, right? If those are prior to AI and we were seeing at the low end, 50%, you know, across those surveys of things that no one was using. Well, that's where I've been kind of forecasting this to say, if, if AI is speeding up our process to build things. the actual development of things, then what's going to become painfully obvious very quickly is that the bottleneck isn't developers. And it, you know, my point from saying that in classes is to say it's never been right. It's not been developers that have been the bottleneck to us being more successful. That's where the focus has been. But I don't think that was correct. And I think that the correct area to put it on is the product side. And if that's true, right, I know I'm doing a lot of leaps here, but if that's true, if it is the product side, well, I think that what that really translates to is the discipline of product management, of being able to recognize what's valuable.

Cort Sharp (04:50)
Mm-hmm.

Brian Milner (04:54)
to your customers to deliver that, to close the loop and verify that that's actually what was needed and to measure the impact of those things, that discipline, I think, becomes just all the more essential because that stat tells me there's a lot of bad product management going on. So that's my initial thought. That's a lot of thoughts, but that's my initial thought when you said that. What about you? What do you think about that?

Cort Sharp (05:19)
right there. I'll share my thoughts, but I do want to harp on or just go back to your first initial one of the callback to those studies there. When you first threw out those, because I've seen similar studies where it was about 50 % was kind of it. I haven't seen those studies that say like, know, what was the last one you threw out there on the high end, like 80 something percent. ⁓

Brian Milner (05:39)
Yeah, actually I remember, so I remember two of them. The 64 % one was from a group called the Standish group. There's been some question about their methodology in that one. I haven't seen the methodology of the 80 % one, but it was a group called Pindo that did that one. And I don't remember the 48 % one. that's just off top of my head.

Cort Sharp (06:01)
Sure. But that 80 % one though, that one sticks out to me because as you were going through it, I was like, okay, well, I have Google Docs open right here just for some show notes or something. Just make sure I ask the questions that I'm supposed to ask or I want to ask. And I thought, wow, I'm looking at the menu bar right here. I use maybe, two or three of these consistently. And there's like 15 options up here. yeah, I could absolutely see a large majority of features that a product has that go widely unused by the vast majority of its users. And I think that poses the question then is, do we wanna go down the path of having one product be really good for, or like, really good at one thing and then kind of OK at everything else. The thing that always comes to my mind in this, and I've been going down this rabbit hole of kind of digital minimalism, is like the cell phone, right? Where it's a really great communication device. OK camera, kind of OK video, kind of OK speaker if you want to use it once in a while. It's kind of OK at browsing the web or doing some other things on there.

Brian Milner (07:05)
Yeah.

Cort Sharp (07:21)
Is it worth making those products that have an okay aspect to it on these other things that, you know, some people like to use, but not everyone will use all the time type deal thing, which is a totally different discussion here. But that's kind of where my memory went of like, okay, that 80 % plus isn't actually all that surprising to me. I would, I would probably throw out there, you know, for the vast majority of programs that I use, baby, aside from my banking.

Brian Milner (07:35)
Right.

Cort Sharp (07:48)
my banking apps, you know, I don't use, I probably only use 10 to 15%, maybe 20 % of the total features in there. and I, it is such a interesting point to the productivity side of stuff of, okay, are we just being productive for the sake of being productive? is it actually being productive? Are we just working for the sake of working? so yeah, just harping on that a little bit.

Brian Milner (07:50)
right. Yeah, yeah, I mean, I agree. And I kind of have a similar response. And I think that there's, you know, the good enough argument, right? ⁓ Sometimes people take exception to that and say, well, why would we be okay with only doing something good enough? Well, it's not about quality, right? It's not saying that the quality of what you do is good enough, but it's saying that the...

Cort Sharp (08:22)
Mm-hmm.

Brian Milner (08:41)
the amount of functionality is good enough. And I think your example of the cell phone is a great one because, know, I'm old enough that I remember before, you know, that was the main way that people took pictures. You know, when you had the little flip phones and stuff, the quality in those were not very good. And so you would have other digital cameras that would took higher quality photos. But the reason that it won out in you started to just see more and more pictures taken from a phone, even though they were lower quality, was because you always had your phone with you. And so there's sort of an extent to which you would say, how badly do I want to carry around an extra device that's just for taking pictures, even though it takes better quality pictures, is the quality that I'm getting with the phone good enough and there was a tipping point there, right? There was a certain point where it went out and the quality of what was on the phone was high enough that people said, yeah, I don't need a separate digital camera anymore. This is good enough for what I need and that one. And I think that that value curve is very similar across any product. There's a certain level. that when you add features, it's a steep value curve. But after you've added those key core things, then it starts to tail off. It starts to flatten. that flatten, it may still be going up, right? But the effort that it takes to deliver something is not the same return on that investment of effort, right? Early on, it's a huge, you that effort creates a spike in value. Later on, that effort creates a small little spike in value. At a certain point, that's where they talk about trimming the tail. At a certain point, that's what they mean by it is that value curve has gone past that point where now it's flattened and we're incrementally adding small little things, but they're not valuable enough to justify the effort that it's taking to build them. Now, will AI change that? I don't know, right? Because if we have a bank of AI programmers, I don't know that it actually changes it because we still could have that bank of AI programmers doing something else instead, you know? ⁓

Cort Sharp (10:48)
Hmm. Right? Right? So it's figuring out that value proposition side of stuff. Yeah. Yeah.

Brian Milner (11:05)
Right, right. The impact, actual, you know, how much do people care about this being there? And, and at a certain point, you know, we had a podcast recently where we talked about this, just at a certain point, there's a, an end of life, right? At a certain point, you have to deliberately say no to something and say, you know what? This product has done all it's going to do and we'll support people that still use it up to a certain point. But at a certain point you say, no, it's better to have a new product now, where that value curve now starts to get really big again. So yeah, I mean, from an AI standpoint, I think it does make an impact because it kind of just makes it more apparent where that problem is. ⁓ And that's why I think I tell all the product owners that come through classes, I think product owners are poised to become highly impactful.

Cort Sharp (11:46)
Mm-hmm. Mm-hmm.

Brian Milner (12:00)
in their organizations in this AI era. Because if you can refine your craft to a level to where the things that you are producing are all a lot of value, right? All creating a lot of value, then now we have the productivity to spit out more and more of that stuff. And if your side of it's taken care of as well, then everything that we're producing is now producing a lot of value.

Cort Sharp (12:29)
Right. Right. I think it opens the door for programmers, developers. I'm not just going to say programmers because I know AI can help out in every aspect of the development process. But I think it opens the door to developers, not only just being more productive, but also just being able to experiment with new things more, more readily, more easily. Right. And we can, we can kind of simulate some of what our customers might want. Right. If we can build a really great persona. I know you've done this in a class recently, Brian. I'm doing a similar thing and just saying, look, let's build out this persona using an AI tool that we can use and create basically an AI agent and say, here you go. This is my ideal customer. Here's my product. What pieces or new features of my products can I focus on in order to deliver higher value to this customer? which is exactly what a product owner does. So I totally agree with you there, Brian of saying, yeah, the role of the product owner is about to become one of the most valuable roles, in an organization, in, in understanding. How do we deliver value to our customers? What do our customers even want? Right. Starting there. If you can build all the cool things you want, if your customers don't use it, who cares? Right. So many examples of that, what I called out earlier, but so many examples of that of like, if you build stuff just for the sake of building stuff, is it worth being built? And I think that's more so the question that we're gonna shift towards within our development cycles of how do we know that this is worth being built? And what quick feedback loops can we start going down in order to get that? Brian Milner (13:58) Right. Yeah, I used to always like to quote this, know, everyone's always heard the phrase, you know, if a tree falls in the woods and no one's around, does it make a sound? And I always equate that to, you know, software as well. If software is built and no one uses it, was it really built? You know, and I know I've been on the end, the bad end of that in the past where I've worked on things with development teams that

Cort Sharp (14:28)
Yeah. Yeah.

Brian Milner (14:37)
We've worked long and hard on something only to have the rug pulled out from underneath us and for management to make decisions and say, no, we're not going to do that thing. And that's a horrible feeling. There's nothing worse. no one out there wants to, I mean, go back to my stats, 50%. Nobody in software development would feel good about themselves if they said, hey, 50 % of the stuff you've worked on, no one ever saw. Like that's not a warm fuzzy feeling. ⁓

Cort Sharp (15:06)
Yeah, could you could you imagine building a car and then building this awesome, incredible car and then you're ready to roll it off the factory line and then all of a sudden it gets cut in half and that's what gets delivered and that's what because that's all that people use, right?

Brian Milner (15:18)
Right. Right. Or you work overtime on the engine going from zero to 60 and you find out that this is just going to sit in a garage. It just doesn't make you feel good because that's not what it's been built to do. ⁓ So yeah, I think that you're absolutely right. We have to focus on the discipline of knowing our customers, knowing what they want.

Cort Sharp (15:24)
Mm-hmm. Yeah. Right, right.

Brian Milner (15:44)
And then checking and asking them, did we actually deliver what you needed? ⁓ And it's funny, I was talking with someone this week about this and it's amazing to me the number of times I've talked to people in the product area that will build things. But when you ask them, did you decide to build that? You had a whole host of other things you could do.

Cort Sharp (15:51)
Mm-hmm.

Brian Milner (16:10)
made you decide to do that instead of the other things. And I'm always shocked at the number of times I get blank stares or just no response at all because it's a great thing to do, right? Well, you're asking me, don't ask me. You should be able to say that, right? You should be able to. to back it up and say, yeah, here's the research behind it. Here's the market study. Here's the business case. We ran these tests, and these tests showed this level of interest. You have to know what it is you're trying to do first. And if you don't know what it is that it's intended to do with your customer, then how do you know whether you actually succeeded at it?

Cort Sharp (16:41)
Right. Yeah, absolutely. one thing that comes out of that is like, how much of that data do you take and how much time do you spend on gathering that data? I've heard a phrase recently and it goes along the lines of like be data informed but not necessarily data driven. where we want to use data to inform our decisions, but we don't necessarily want to gather all the data in order for it to be 100%. We're not going to make a decision unless we have this data point to guide our decision or drive our decision. Yeah.

Brian Milner (17:27)
Yeah. Yeah, no, yeah, it's, know, we had, I think that the way to think about it is properly is bets. You know, that you are making bets in different areas and you don't make a bet, you don't wait to make a bet until you're 100 % certain. Cause you're never 100 % certain on a bet, right? There's always a percent chance that it could go one way or the other. But what you try to do is, you know, make informed or maybe that's not even the best analogy. Maybe it's more like an investment. You know, when you make an investment in a stock, it's not just a pure bet because it's not a flip of the coin. Right. If you do your research and you know enough about the company, then there are better investments than others. And

Cort Sharp (18:02)
Mm-hmm.

Brian Milner (18:18)
I think that's the way we should look at our features and our products is to say, this is an investment in our company. So I want to invest wisely. And you wouldn't be very smart, I'll put it this way, to have an investment strategy in the stock market of just pointing your finger at something and say, hey, I'm going to spread out my investments over these 10 companies that are just random companies.

Cort Sharp (18:30)
You

Brian Milner (18:42)
because one of them is gonna hopefully turn out to be successful. You're not gonna succeed, right? But if you research the 10 things that you're investing in, if you kind of know the history, know the trend line, know where the forecast is, all right, well, this one has a strong chance I'm investing here. ⁓ That's how you're successful. And we don't seem to always do that with our products.

Cort Sharp (19:02)
Right. Yeah, I've kind of tied that back into our products and a conversation I had with a product manager, product manager, they weren't a product owner or a project manager, but a product product manager, gosh, three months ago or something like that. Small company, very small company. Just I knew the guy from from school and was talking with him and he goes, yeah, we feel like two week sprints is too long. We even feel like one week sprints are too long. We're trying to shoot for one day long sprints. And my question back to him was, okay, why, first of all, why would you want to do that? And he goes, well, because AI just allows our developers to be so much more productive and do more things. I'm like, okay, I could buy that. But my second question to him, which goes along the lines of what you were talking about here, because getting that feedback, getting that data, let's be data informed, not data driven, was how do you make decisions on, how do you give feedback to your developers? How do you make those decisions on, yeah, this is the highest priority today versus yesterday? Is the market shifting that quickly that you have to make those decisions? And let's say it is, let's imagine we live in that world right now. Some of you probably do, but I know someone out there probably does, but how do you, do that? what tips would you give Brian to this guy about, yeah, let's drive the decision making forward and let's give the feedback faster if our development team is able to actually deliver a fully featured feature. How do give them feedback on such a short timeline?

Brian Milner (20:44)
Yeah.

Cort Sharp (20:47)
I see teams all the time struggle with saying, yeah, we get good feedback every two weeks with our sprints. I've seen teams be like, yep, two weeks is no problem for us. We get good feedback. We're able to move forward. We're able to make decisions, be data informed, and move forward that way. So we cut our sprints down into one week. I think one week is probably like the, in my mind, at least in my experience, is kind of that. lower end, the lower lower echelon, I guess, of the ability to provide meaningful feedback and meaningful delivery stuff.

Brian Milner (21:16)
Yeah. Well, it's also about, can you create something that is of meaningful value in that timeframe? Because our product increments should be valuable. And that's what's probably going to be the blocker for most teams going to a day-long sprint or so is because, yeah, we can't produce something valuable enough in just a day. It takes us multiple days. ⁓

Cort Sharp (21:33)
Yes. Right. Right.

Brian Milner (21:46)
In general, mean, I would applaud it in general because I think the shorter time span is generally better. I generally have more of a problem with people who want to go the other way and be too long, you know, and do like a month long sprint. So I would much rather have a team that wants to do a day sprint than a month long sprint. But that, mean, the questions I'd ask about a day long sprint is, Can we produce something meaningful within the day? And maybe the answer is yes, right? Maybe across the team, there's enough work and maybe the work is small enough, right? That's really what it would take is the breakdown of the work is small enough that they can actually get stuff out that's valuable within the course of that day. So are they able to produce value in a day? It might. get to feel a little ridiculous as far as the meetings are concerned, right? Because that's one of the considerations when you try to choose your length of your sprint is, how often can I have these meetings? Take for instance, just the sprint and review, right? We need important stakeholders at the sprint and review. Can you have important stakeholders every day? If not,

Cort Sharp (22:48)
Right.

Brian Milner (23:01)
If what you're doing is no, that cadence is not wide enough that our stakeholders are too busy. They can't come every day. If that's the case, then you might want to consider a longer sprint. That doesn't mean you have to wait on delivery. And I think maybe that's something I'd ask them as well is, are we confusing the sprint length with delivery length? because you can deliver every day. You can deliver multiple times per hour. There's nothing that says in Scrum that it's tied in any way, shape or form to your sprint length. And if that's the intention is to just release things more often, then absolutely, right? If your system is set up to do that, it doesn't matter if you have a week long or month long sprint, if you can deliver things every day, It's a much better process because back to your original point about feedback, can you get meaningful feedback? Well, if we're delivering it every day, we're going to get more meaningful feedback because we're not only getting feedback from just the internal stakeholders, but we're getting it from external customers. ⁓ Let's just say if we have a week long sprint and we're delivering every day, we have feedback from actual customers by the sprint review.

Cort Sharp (24:06)
Right.

Brian Milner (24:14)
that would be an incredible position to be in, to be able to say, yeah, we've released these 10 things this sprint, and here's what the customers are already saying about it. We got this feedback, or this one has generated this much support, so now we have tickets to kind of handle that. Yeah, it's in general a good thing. I'd want to make sure on those other areas to make sure that it's not being confused maybe with something else.

Cort Sharp (24:37)
Yeah. Yeah. Just understanding the definition of what a sprint actually entails. through that conversation, it turned out they, were on the, you know, we just want to deliver every day and, and, you know, we have our sprint review at the end of the week and whatnot. And I'm like, okay, so you're not having day long sprints. You're doing a week long sprint. Yeah. Yeah. Yeah. We, we laughed about that a little bit, but, yeah, I think the

Brian Milner (24:50)
Yeah. So they're doing week long sprints. Yeah. Yeah. No, that's great. I I applaud them on that. That's a mature thing to do. And if your team can get to that stage, it's only because you've invested heavily in automation and DevOps and those kinds of things. It takes discipline to be able to do that. And I'm sure they were advocating it to you because they saw the benefit of what it provided them to release more frequently, which... is an admirable thing.

Cort Sharp (25:25)
Yeah, 100%. They were like, man, this is awesome. I know you're in this space court. Like, let's talk about this. And yeah, it was a great conversation. It was a lot of fun. But they were, yeah, they were just kind of confused with what it actually meant to hold a sprint. I think they also heard the term Kanban for the first time not too long ago. And they're like, this is the same thing, right? We're sprinting in Kanban, just like we sprint in scrum. And I'm like, I...

Brian Milner (25:39)
Yeah. Ha ha ha.

Cort Sharp (25:50)
No, a little different, slightly.

Brian Milner (25:51)
Yeah, not quite. Not exactly the same. Close cousins. Yeah. I mean, back to our original topic here, I mean, I think as far as AI, we talked about that with product management. And as far as the Scrum world is concerned, I am very interested to see how this

Cort Sharp (25:54)
Yeah.

Brian Milner (26:11)
kind of upends the cart a little bit as far as our teams are concerned. I don't think that it, at least from my own perspective, and I could be proven wrong, I don't see it as destroying the team. I don't see it as a complete re-imagining of the process. I think the process still holds. The question is just what does that team look like? Previously, we have a Scrum Master, a product owner, and then a set of developers. Well, would imagine there's teams would probably have less developers because they can boost their own capacity by using AI copilots and other things to help them generate code faster. So maybe a team that previously was eight people is now a team of four or five. And maybe that makes us reimagine a little bit about Scrum Masters and product owners and whether we need them to more frequently be across a couple of teams rather than just a single team. Yeah.

Cort Sharp (27:12)
With that, this question just popped into my mind and you got into it a little bit there with like, do we need our Scrum Masters or product owners to be across multiple teams? What would your ideal, let's say AI takes off, you're in charge of organizing 10 teams, right? And you have all the people that you need. So you can have as many product owners, as many Scrum Masters as you need. And we want to have our developer count be, you know, five developers per team or three developers per team. Let's, let's try to go down that path of saying we're small, right? We, we have AI. allows us to accelerate the speed of our development per developer. Right. So, would you have one product owner per team and then have the scrum master float around, or would you have the scrum, same number of scrum masters as product owners?

Brian Milner (28:04)
it would greatly depend, because I just different scenarios might require different things. in general, then I'd probably, I'd probably match them up as much as possible. because in general, I think there's kind of similar demands on both. They're different, but similar volume of demand. the interesting thing to me is, the volume of work that can be created by a team of eight developers or so right now, if that same volume of work can be generated because each developer now has the tools that their abilities are enhanced, again, I don't see it as replacing, I see it as enhancing, right? If... If they can do that and they had eight, now they can do the same volume of work with four. Well, it's not reducing the volume of work for the product owner, right? Because the product owner still needs to manage a backlog and prioritize and stakeholders and customers, right? That's not going away. The work from the Scrum Master, I think obviously changes a little bit because

Cort Sharp (28:58)
Right.

Brian Milner (29:10)
While it's one thing to try to manage team dynamics and get them to high performing levels when it's eight people, it's a lot more individual focus when it's four. So that's why I would say for a Scrum Master, maybe it does become more viable to be on a couple of teams because we're not contributing to the product. In general, we're not building things. Or maybe that becomes the new mode as well as the Scrum Master is more of a hybrid role with a combination of them and developer. I don't know. ⁓ I think time is going to tell that over the next few years.

Cort Sharp (29:43)
Right, right. Right? Where my mind went with that was, I would much rather have two teams of four than one team of eight, well, developers, right? Two teams of four developers that are as productive as my one team of eight each individually. and instead of kind of cutting the head count down, so to speak, or reducing head count, I'd much rather reconfigure the way that my teams are organized right now in order to

Brian Milner (29:56)
Yeah. Yeah.

Cort Sharp (30:13)
Utilize AI and I don't want AI to be replacing my developers. I want them to be I want it to be helpful to them I want it to augment their abilities and enhance their abilities like you were saying and in my mind if you know if I was running a company ⁓ We all think we all think we're in that armchair, right? We're all sitting in the armchair saying if I could make all the decisions for a day. What would I do? ⁓ In my mind, I would say okay

Brian Milner (30:28) Yeah. Yeah.

Cort Sharp (30:38)
I don't view this as a, I can replace my development teams. can instead effectively, let's call it double, you know, I get twice the productivity out of one developer with AI versus one without. I could double the amount of deliveries I get. I could double the features that I produce, that my teams produce, or along those same lines, you could probably figure out a way to cut down the delivery timeline.

Brian Milner (30:54)
Hmm.

Cort Sharp (31:07)
and cut it down in half, which goes back straight up to that top of the top of the hour question that we were talking about of product management is the roadblock. It's the bottleneck there to decide how do we get this sooner? How do we get these feedback loops quicker? Right. So.

Brian Milner (31:25)
Yeah. And to expand on that point, right? mean, if you're, if you have two teams of four that, you know, and that one team of four produces the same volume that previously a team of eight would do. Now I've got two teams. I'm doubling the volume that I can actually create. So to your point, there, there are some who would look at that as, I just lose four developers and To them, here's what I'd say. Imagine this scenario, two companies, right? And both these companies, they're competitors. These companies have the same exact situation happen to them. AI comes on the scene, AI enhances the productivity of their development teams. And one company says, hey, I can lose four developers and have the same level of productivity as I have today. So four people get pink slips, right? they maintain the same level of development that they have today. The second company says, hey, I can get twice as much done. So they start expanding the number of things they can produce. since they're assuming their discipline is in shape, they're producing things that people actually care about. Which of these two companies is going to win? It's gonna be the second one.

Cort Sharp (32:33)
Mm-hmm.

Brian Milner (32:40)
It's going to be the one that actually can now deliver more value to the customer. So I would not jump to that conclusion. And I don't think that's necessarily going to be a successful company that jumps to the conclusion that, I'm just going to slash my budget for developers because now I can get the same volume with less people. yeah, but your competitor is going to have double the volume.

Cort Sharp (33:03)
Right.

Brian Milner (33:08)
with the same number of people and why wouldn't you do that instead?

Cort Sharp (33:11)
Right, totally. I totally agree with that. Part of me is really excited to see the studies that come out and say, here's the differences between these two companies in the similar space. One reduced their development and replaced with AI, and one enhanced their development teams with AI and didn't replace anyone with AI. And just super interested to see the difference in... evaluations, in productivity, in releases, in whatever it is, right? And I'm going to try to see if there's anything out there right now because... ⁓

Brian Milner (33:45)
Yeah, well, this is my call out to everyone listening to you, right? Like if there's researchers out there, go research this and ⁓ let us know. Or if you're in the middle of researching it, please let us know, because I'd love to see that study as well.

Cort Sharp (33:52)
Yeah. Yeah, very fascinating, right? ⁓ Well, awesome.

Brian Milner (34:00)
Yeah. Well, this is, this has been great, great court. I think this is a great topic and, you know, we've, we've gone a little bit past our time, but it's, it's one those deep topics we could talk about for a long, long time. And, I, know, truth of the matter is time will tell, you know, like this is just, we're on that edge of the frontier where now we don't really, no one can say a hundred percent. we have to see how things kind of play out and, take it from there.

Cort Sharp (34:27)
Yeah, absolutely. I couldn't agree more, Brian. I think this was a great topic. Thanks for taking the time to chat with me today. you got me a little more that I'm thinking about now. So thanks for that.

Brian Milner (34:36)
you Yeah, absolutely. Thanks, Cort.

Cort Sharp (34:41)
Thanks, Brian.

Venise : la puissance contenue - Jean-Baptiste Noé

Conflits

La puissance contenue : stratégie de longévité

The AI-powered Podcast Player