Velocity can help a team plan, but it creates problems when leaders use it to judge performance. In this episode, Brian Milner and Scott Dunn explain why that shift happens so often and what leaders should pay attention to instead.
Overview
Velocity is one of the most misunderstood metrics in Agile. Used well, it helps a team forecast and make planning decisions. Used poorly, it becomes a productivity score that encourages inflated estimates, unhealthy comparisons, and a focus on output rather than value.
In this episode, Brian and Scott discuss why leaders often reach for velocity, why it gives them the wrong signal, and how teams can reconnect measurement to outcomes, learning, and business impact. They also explore how AI is making this issue more urgent by increasing delivery speed while putting even more pressure on leaders to ask whether teams are building the right things.
References and resources mentioned in the show:
Scott Dunn
#35: Metrics with Lance Dacy
Rethink the Refinement Session: Less Time, Better Outcomes by Mike Cohn
The Cost of Change Curve Is Outdated by Mike Cohn
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.
Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.
Auto-generated Transcript:
Brian Milner (00:03) Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm here again, Brian Milner, and today I have the one and only Mr. Scott Dunn with us. Welcome back in, Scott.
Scott (00:13) Thanks, Brian. It's always great to get to hang out with you again.
Brian Milner (00:17) Yeah, Scott and I ⁓ have been doing this together. We've been doing multiple episodes. If you've been listening to show, I'm sure you're aware of who Scott is, but Scott is a trainer and coach like myself. He is a CST and Rocket 9 Solutions is his company. Get this right. I want to make sure I don't say anything wrong. ⁓ So ⁓ we're here though, because we want to have Scott ⁓ on the show to talk about something that is
Scott (00:37) Yep. Yeah.
Brian Milner (00:47) ⁓ A question that comes up a lot in classes, ⁓ an issue that I know we both see all the time. ⁓ And that is really why velocity is the wrong metric for leadership. So to get us started, Scott, why do you think velocity gets so much attention from leaders?
Scott (01:13) Right, so I do feel like part of this is completely understandable because in the beginning we go through, might have had their scrum masters go to one of your CSMs and they hear about velocity as a core measurement and I agree. And so that's the one number they hear. And at the same time, I can admit it is powerful because they're actually seeing, this is a measurement of how much stuff got done, not a percentage complete, which is what we're used to. And I know a lot of leaders, I'm sure you've seen this too, they'll get those reports like we're a third the way done or we're yellow.
But they know it's squishy because it turns into we're greenish yellow or you're still 33 % done the next week. So they know it's not a real number when they hear this percentage. yeah, velocity measures, how much stuff we actually got done that is demonstrable that the product owner said, yep, that's what I want. This is good. And it's shippable. That is about, or that is really valuable. So I can see why they kind of got, one, they liked it. I think your point is that they get stuck on it and they didn't move on to something better might be.
the question we can kind of dig into a bit.
Brian Milner (02:14) Yeah. And I, when I, when I start thinking about this as an issue, like before you even talk about anything like story points or anything like that, I feel like you have to start a little bit further back to say, you know, for me, everything's purpose-based. What's the purpose for doing something? we, are we accomplishing that purpose with what we're trying to do? Right. And so what I want to ask is like, why do we think it's so important? Why do we think there's so much emphasis?
on trying to measure the productivity of people. There's so much focus on, from a leadership perspective of increasing productivity, increasing. And when I say increasing productivity, I specifically mean increasing the volume, the output from the team. And that's something I fundamentally start to question from the start is,
Is that really the thing that is important to the business? Is the volume that comes out of the team?
Scott (03:20) Yeah, easy to get fixed on. then I look at like the personality type or the culture type of executives is commonly ⁓ make it happen, get stuff done, right? They're very results oriented. They may not be as good at understanding the strategic value of some of this stuff. again, Velocity gives us a, hey, you got stuff done. And IT, my experience having been a developer, having managed ⁓ a development shop, all these companies that we've coached at is that
IT is still really bit of a black box. So I don't know how to get in and actually work with them to increase what we're really after. And I do go back to at times, it's a quick conversation with the ⁓ managers or leaders that go, what's the goal this quarter? Well, they don't know, or there isn't one. Or the leader will say, here's what it is. And if we go and ask any of their direct reports, it won't be correct. That's statistically true from a number of different sources. So.
The people doing the work don't have a line of sight on why we're doing this stuff. And that includes the manager. So the manager's like, well, I'm not sure. So how about just more stuff? But it's a little bit like, it's like measuring how many miles I've gone in my car. That's great, man. I knocked out a hundred miles in my car today. Did you get to your destination? Well, I'm not sure what the destination is. I'm just driving around, but boy, I'm getting more miles every day, right? Some of them miss.
Brian Milner (04:33) Right.
Yeah. Yeah. No, I agree. And I always think back to like in this conversation, I always think back to like, this is a pop culture ⁓ kind of ⁓ reference that that's not it's not ⁓ it's urban legend, right? ⁓ Because you hear like in movies, sometimes the whole concept of, well, you know, NASA
This has gotten an example of government overspending, right? NASA spent all this time and energy and effort ⁓ developing a pen that could write upside down in space. Well, what did the Soviets do? Well, they just created, they just gave them a pencil, you know? And it's a common story people will use to say, isn't it? If you dig behind it, there's actually other reasons and it's not as clear cut as that. There was reasons why it needed to be a pen and not a pencil.
Scott (05:13) Yep. Classic.
Okay.
Brian Milner (05:27) It's not a real good analogy in real life, but people make that analogy and ⁓ I use it here to say, well, look, both of them had the same output, right? If you were to take that at face value and say one had a pen, one had a pencil, that's one and one. But it's a good example of saying if that were true, right? If it really was just NASA overthinking things and
look at all the effort they went to to make this pen that wrote in space and zero gravity when they could have just had a pencil. That's a good example of this idea of why output is not really a good measurement because it's the same output from both, but what's the value of one versus the other? And how much time did it take to do one versus the other? ⁓ If that story was true, it would be equal value from both.
Scott (06:24) Yes. Yeah.
Brian Milner (06:24) but it would be
much different times that it took to deliver.
Scott (06:27) Right. And so the interesting thing is I'm sure there's, mean, obviously, your podcast has a lot of listeners, you know, on agile mentors, and those would include project managers. My project manager would be telling a story similar what you're saying, which is, before we get budget for a given project, you got to do cost benefit analysis. It's the same thing. So how did you define the benefit? Somehow that gets lost when it goes into the teams. think somebody just cut it off and like, well, now just go and, you know, scram away and then build the thing. But piece by piece, we don't. ⁓
Teams might say we're doing Scrum because it makes us more efficient. And the thing I love is that some people are actually, they have more insight and they say, actually it helped us find the right product faster. That's the efficiency win. So to your point, I could have figured out the pencil much quicker. In the end, we still end up with a thing, but if we don't measure like what's the effort in that, and the story points, it's kind of like, well, we just did stuff, but we have no value on the cost benefit. So one simple thing I like is you can just have the product owner just assign value points to it.
Brian Milner (07:07) Yeah.
Scott (07:27) Easy. Now they're going say, well, that's not perfect and exact. Well, what do you got now? And most of them, they don't got anything now. At least if I say, well, I don't know. I think it's 40 points of value compared to that other request I had that's 20 points of value. Well, if it's 40 points of value and it's, you know, the estimate is 20 points for the team, well, you know, it's a 2X. Easy. So I would rather say, here's our velocity and here's our business value. Now they might say, well, what are the stakeholders going to say? Yeah, that's a great conversation to start, isn't it?
How do we define value around here? But my friends who are listening to this, think about the fact that you're probably doing it in some form already at the project management level and cutting in to do even a little bit of what we're talking about, Brian, is a lot easier than they might think.
Brian Milner (07:54) Yeah.
Yeah. Yeah. So I mean, and maybe it's part of that fundamental kind of ⁓ leadership mindset that goes back to kind of more manufacturing based kind of work. so that obviously, when you're manufacturing, productivity is a very, very high mark, because it is about just trying to produce as many of the product as you can. Not in research development. It's just not the same paradigm.
Scott (08:32) No, no. I think also just as a cautionary tale for managers listening or project managers and you think, well, yeah, that sounds nice about thinking about the value, it's working for us well enough on velocity. I think it's a good metric. Here's the problems I've seen with them, my friends. Number one, if I'm not being pressured to do more, as you described Brian, like, hey, we've got to get our velocity up. I guarantee, I've seen this numerous times. Okay, let's take a look at this next story point. We're in the product back-alcohol refinement. I look at it like.
Yep, that looks like a 20. Oh, I'm sorry. It's a 40, right? I'm just gonna start doing story point inflation and guess what? The numbers go up and the sad thing is management inadvertently reinforces that behavior saying, wow, you guys got 120 points done to sprint. I know a company when I said, so what's your velocity on average per sprint? And he's like, you're gonna kill me. I said, what is it? It's over 2000. I mean, at what point does it get ridiculous, right? It's like, this is whatever. So that's one problem.
I think the other problem is you look at these people that are measuring velocity is that then they'll immediately and I mean it was for my earliest days, they immediately go, hey, that's great. I'm glad this team got 70 points done the sprint, but why is that other team only doing 30? What's wrong with them? Like it's a terrible comparison because that team might just have three or they've got newer team members or someone's, but management again oversimplifies to their own detriment. So now the teams get wary about scary points because they're being evaluated and they know it's not a fair evaluation. So I think that's a
That's a risk also that you inadvertently expose yourself to. I'm not against story points and velocity. I'm just, I'm worried that if you push too much to get more as you described, you're gonna get some unusual behavior where they might start to game it a bit, or they just don't feel safe anymore to see what they honestly think. And that's a problem.
Brian Milner (10:14) Yeah,
yeah, it's too easy to game. you know, I had kind of a situation, Mike tells this story about how he had a team that like, put a million on the end of every story point estimate, because they wanted to make the point that like, it's ridiculous to compare us to somebody else. So it was million story points, two million story points, right? Right, exactly. Exactly. ⁓ Well, I think that leads to a good question then, and to try to, you know, we're saying
Scott (10:34) We all deserve raises. This is great.
Brian Milner (10:44) kind of what it isn't. So what is, let's talk a little bit about what velocity actually does tell you. What does it tell you? What does it not tell you?
Scott (10:56) True, yeah, it's gonna tell you you did a certain amount of stuff of varying effort and complexity and risk and I think that that is helpful. My biggest one is it helps us immediately get better on predictability. Because that's probably the number one client request we get is we still can't give a date and actually hit it. Well, if I can't say this thing's a 20 and how much do I think I can get done in the given sprint is 60, I should probably get that done. You immediately true up, do I estimate well?
Do we execute well as a team to do what we say we're gonna do in the micro, because that's easier to fix than what your big three months, six month plan is. So I do love it for that. It gives you that better way to estimate. If you don't do story points, ⁓ one, you can't actually get your predictability down. If you say, we do, but we use hours, you immediately get into a problem of, well, it's X hours for this one person, because they gave the hours estimate, but someone else can't take it on. And those are just historically bad anyway. So I do like the reference of points.
I think that's good for predictability and some kind of a measurement. that's, that to me is the biggest value when I get, I think the other things I'm looking for classically, you can do all sorts of metrics like the obviously cycle time and lead time. How long does this whole process take? Can we just get the process down better? Scrum is great for unknown things, but Scrum doesn't necessarily give you efficiency. I mean, we're stopping and starting right every two weeks or so. So I'm not saying it gives you efficiency, but watching cycle time as an overall metric and lead time as an overall metric is great.
I still think in the end for my product people who are listening, you still want to go back to your core thing of what's the goals for the product. Are you trying to increase net promoter score? Are you trying to increase quality? Are you trying to increase a loss of churn on customers versus subscribers? We got to have those metrics too. They're going to be lagging indicators, but we don't want to lose sight of those and say, well, we're agile now, so we only watch velocity. You can put a bunch of stuff out there that nobody actually cares for. I'm talking to you, Windows Phone.
that no one used, right? So they built that thing and I had to use it because I worked at a Microsoft shop and it was terrible, right? So, bro, was that a win? I'm sure they had a lot of velocity building that thing, but your customers aren't happy and losing. And I'll just add as a side note, you and I were talking about AI a bit earlier, the pace of change now, this is what worries me. For those of you in shops where you feel like, I don't think we're really doing agile well. And now we're all talking about AI. The pattern I've seen that if you didn't do agile well,
you're probably not going to do AI well. It's still a new change to the way you work. I know it's a technology tool, but it's radically changing how we work everything from requirements to how we prioritize to how we build code to how we engage with customers. And every way I've seen it's radically changing. But if you don't get some of these foundational parts down, you're going to have more problems going forward. So it might be worth revisiting. I'm seeing a little bit of a resurgence of people revisiting the basics, like just quick feedback loops.
quick, take a bite of this. We're not sure how to move forward with AI. So just take a bite. Yeah, take a bite and see how that moves forward in two weeks. It's a lot better than like, you know, we're just going to see how AI goes and we'll revisit this all as a company in three months. Well, in three months, you lost 20 % market share or something like that. It's really, the speed is unprecedented. So I do want to say, consider these things Brian and I are talking about with that lens of AI, that this isn't just like old school agile. It's like, this is how we should be working in order to move forward. I so the company we just kicked off with their agile enablement.
They're in two week cycles. They're going to prioritize what they're trying to do with AI as a company across business units in these next two weeks. Do they really understand everything? No, perfect space, right? Complexity, take a bite and inspect and adapt. And then at the end of those two weeks, how did it go? How those teams do? Are they using AI the way we think? And it's a huge shift from these companies that are just saying, we rolled out copilot licenses. And then they wonder why no one's building great products and doing great stuff. Well, they just have copilot and that's it. You don't have a feedback loop to say,
Brian Milner (14:39) Hmm.
Scott (14:45) How did it go within two weeks? So I think those are still great foundational things to look at and just measure anyways, even for that new world with AI.
Brian Milner (14:54) Yeah, it's kind of like the in the fitness world, like the whole debate about getting in your steps, right? I mean, people will say, claim it has to be this number of steps. I remember back in the day, going through a mall and seeing this dude sitting on a bench in the mall with like super big gulp in one hand, and he had one of those fitness trackers in the other and he was just like shaking it in his hand.
Scott (15:21) No!
No!
Brian Milner (15:22) And he's like trying to
get his steps in, right? ⁓ But that's kind of like the effect I think that could happen here is a little bit is like, well, is the steps the goal? Right? Is the goal really getting that many steps or is the goal actually to lose weight? Is the goal actually to be healthier? And if that's the goal, then you got to keep your eye on the prize. Like that's what we're trying to get to. So.
If I'm sitting on the bench with my big gulp and shaking the thing in my hand, like, am I getting some exercise? I'm getting some exercise, right? But I'm certainly not getting what I need to actually get to my goal, which is a healthier lifestyle. And I think that's the same thing here for story points is it kind of becomes like steps. It's the thing where, yeah, you can look at it. It's a measurement. Yes, it does kind of give you an indication of overall productivity, but...
It is not a true, a good measure of performance. And that's, think, where people kind of lose sight of that. I mean, I think an important question, Scott, is, because leaders ask me this all the time, is, well, you're making this case against using this for performance. Well, then how do we measure performance? I think you already hit on it a little bit, but I just want to make sure we clarify for people.
Scott (16:23) There you go, yeah.
Brian Milner (16:44) what's kind of the right way to look at a team's performance and actually accurately judge that they're contributing what we need them to to our company.
Scott (16:53) Yes, ⁓ and I'm not one to shill on the Great Mountain Goat courses, but I will in this case, because I think it's great. So for those who haven't taken or don't know, like in the product owner class, we're gonna go and actually use, in fact, the cool thing is you guys have built AI into all the courses. So they use AI to see how quick and easy it to say, what is the product vision? So some of our listeners, you're old school, you love this stuff, you were in early, but when you went through training, the Scrum framework might not have had the sprint goal in the product.
goal yet. So I think those are wonderful additions. So now in the CSPO training, you're going to go through some of that. And then based on that product goal, that sprinkle, now we can actually get some better measurements of what we think that we could, you know, could be. And even at the end of CSPO class, we're talking about hypothesis. And I think that's the most powerful thing. And I know a lot of people have gone through that. Maybe some of the folks listening now went through my class. So don't, I don't want this to come across wrong, but I just want to say what I saw. Cause as a coach, I usually say, you know, permission to speak plainly, right?
Brian Milner (17:51) Right.
Scott (17:51) Because we would get through the end and we would do the hypothesis. And what I saw over and over again is the product folks didn't know how to say, if this is the big thing we think this product is going to achieve, like ⁓ up our subscriptions or get more page views or whatever, a small experiment to validate that before we spend all that money on the anti-gravity pin. The small experiment we're going to run is this. And we'll know we're on track if we see these early data indicators.
And they historically really struggled. They didn't know what it looked like to run a small experiment. I think you'd mentioned earlier, the problem is my friends, product management is still pretty much a wild west. So we're not used to and don't have that muscle to say, what's the point of our product? And therefore to your point, how would I measure we're making progress against that? Because velocity is output, but that real movement on your product is outcomes. That's what makes the revenue. That's what pays the bills and keeps everyone employed. So if I can't articulate that, and the truth is,
And I already said I can speak plainly. And if not, you could edit out this part, ⁓ But if the way you currently prioritize is loudest voice wins or highest paid person's opinion, then what measurements do we have? How loud? So I encourage you, by the way, this is something I mentioned to you as well, Brian. You can go into AI and say, here's what we're thinking. Give me the risks. Give me the concerns. Give me how I could articulate.
presenting this back to stakeholders. I know it's hard to say no and push back to try to get clarity on what is our strategic plan to move this product forward to the next level. But AI can help you do that. AI can give the words to use and you can edit it, of course. But it used to be the hardest thing in the world was to say no. That word no was really difficult. Or for me, I'd always just say, well, not now. But if I don't have clear goals now, how do I say no to anything? Because we don't have anything to measure it against. So I think what I'm looking for when you say outside of velocity,
Go back to your leaders and say, what is the goal for this quarter? And if it is something around quality, then what we're gonna immediately start to measure is not just velocity, but number of defects found either within that sprint or previous sprints. And you got the sprint review to put this in front of the right people, your stakeholders. If it is a better customer engagement, if it is more page views, we can run small experiments too. And I encourage you keep having small experiments every step of the way, measure those. Did the page views go up? Now in the end, when we do our hypothesis ⁓ exercise in the Mountain Go class,
I just say, look, it doesn't matter being right or wrong. You'll at least have a baseline and learn that, oh, well, we overestimate how much we think people would like this or we underestimate or whatever, or even in what you added to the class with rice, what's that impact going to be? Well, then how would we measure that? But those are the right conversations around output. And I'm just having a little bit of empathy for our product friends because by and large, they haven't had to do that. They simply did what we're told. And IT has been historically just, you know, an order taker.
Mindset and so we just don't have this we haven't exercised that muscle a lot
Brian Milner (20:47) Yeah. I think that that's, that's a really good point. And I think that there, there, there is a gap that I think, you know, we're, talking here about velocity, right? But I think that from the product standpoint, there's a gap that maybe is driving this that is, is not really talked about or seen. And that is kind of what's, what's your product discovery process? Because that's
At some point, right, at some point, your business makes the call that this is worthwhile of our investment. And what I see all too often is that basically, that's when the product owner is brought in, is when some level of leadership has given it the blessing, right, this is a worthwhile project, go forward. And that's not where it started.
Right? It started prior to that and there was some product discovery there to try to understand the business case. Is this worthy of investment? And I think there's a gap sometimes. There's a separation that's artificial between the delivery end of it, which is here's now go forth and do this and the value section at the front to say it's worth our investment. And that gap is crucial because now
If I don't have that visibility as the product person, then I don't really understand, what did we hope to achieve with doing this? And then I can't prioritize because I can't really even look at ⁓ what would drive what we're trying to achieve. ⁓ So.
Scott (22:20) Absolutely.
Yeah, you just have
your features set, like here's the requirements.
Brian Milner (22:32) Right, so
I think there's a lack of transparency sometimes in some organizations between where decisions are made and when the execution starts. And that wall has got to fall. ⁓ There has to be a tighter coupling there so that there's clear and transparent understanding of here's what we're trying to accomplish, now go forth and do it.
Scott (22:45) Yes.
Yeah. And I think on that point, so you're reminding me, there's a company I worked at when I was getting, we're going through the initial requirements and this large product had been given to us. And I said, well, I've got some questions. So how do I talk to the folks in terms of who put this together on the why behind some of that? And they just strip said like, yeah, that's a whole nother group. don't talk to them. I thought that's right. did just deal with it. So, one of our coaches, Bob Niwa, he's so great about saying we have lopped off that whole discovery phase. Cause I do love Scrum. I love Scrum to death.
You know, if it was a person I'd marry it, but we don't, just ignore that there's a discovery phase just because it's not encapsulated within scrum doesn't mean we shouldn't do it. I think that's really important. What you're saying. It takes time that I mean, I'll ask product owners. When's the last time you actually spoke to a customer? When's the last time you got out of the office and it's not happening. So we lose that connection. We don't know the wide band. Someone funded it and there we go. So one thing I do advise them is when we get some of those requirements to try to partner with the stakeholders, not be not come across as negative, not come across because
Brian Milner (23:32) Yeah.
Scott (23:53) Obviously, no leader's saying, given the go ahead for product that they think is a bad idea. They think it's a good idea. So we want to go to them like, hey, this sounds great. ⁓ How can we figure out even better ways to get the goal you're after? This feature looks great. I'm curious if there's other ways we can get that end result. So you're starting the conversation, say, want to partner with you to improve what we're doing right now towards your goals. And they are almost always happy to talk about what they're after. But honestly, it's usually up here.
It didn't get captured or ticketed somewhere else. So try to start those conversations. And I would treat them like, I'm just trying to clarify requirements. If you try to say like, I'd like to know why we're pursuing this as a value instead of, oh, that's not going to, they already, they've made their decision. Probably not going to get a lot of points by doing that. I treat her clarifying requirements towards the goal, which then they'll say, well, actually the reason we're trying to do this is X. We've seen the market shift because of these. Oh, okay. Okay. And now I'm partnering with you to try to help you get those wins, but you're right. Those parts get broken apart.
Brian Milner (24:38) Right.
Scott (24:52) and we skip it and we never feel like we have the right to do that. When I look at what makes a great product owner, normally one of those traits is authority and they always say, yeah, I don't have any authority. I don't have a voice in all this.
Brian Milner (25:03) Yeah.
Well, and fundamentally, I think that's what drives a lot of ⁓ anti-patterns from the product end of things. Because if I'm a product owner and I don't have that clarity into what is it this product is doing for us as a business, right? ⁓ Then you can see how my focus might shift into this area more about execution.
And you can see how leadership might view product people as more product manager, not product manager, project manager kind of oriented. I've encountered so many product owners in the wild that the organization kind of looks on them a little bit more as project managers. they kind of have a somewhere in the scope of their job, ensuring on time on
on budget, on scope delivery, Michael, that's not really a product owner. The product owner isn't there to push and drive the team.
Scott (26:11) No, right? So two quick comments on this. For those who are still listening, kudos, because the good stuff really kind of come. So one is what we're seeing is these roles, both Scrum Master and Product Owner, they kind of, they're getting morphed into, as one person called it, we're just becoming the junk drawer of all this stuff, right? Hey, make that person responsible. So I'm this commingled Scrum Master, Product Owner, Service Delivery, know, Initiative ⁓ Lead, all the things. So we lose that clarity. ⁓
Brian Milner (26:18) You
Scott (26:41) But I had a prior student, I loved it, Nikki. She said, I love the idea of product owner as mini CEO, which is very different from what we mainly see, which is I'm a glorified BA. I make sure the requirements are clear and get stuff done, but we lose that powerful connection of a mini CEO says, if I'm watching over this kind of spend, how do I make the most of that spend? And that's what I think is such a great point that Mike's bringing up about velocity is, I don't want to just spend on stuff. I want to spend on something that gives impact. But if I don't feel like I'm wearing that hat and have that authority,
I will just kind of be an automaton role player, like just do my thing. And it's not really on me that we didn't capture value, but everyone on the team probably saw that coming the whole way along. Like, I don't know why we're building this because we could have done X. And again, this is a clarion call for folks listening to make this perhaps an opportunity to escalate this and have this conversation. really, really encourage you just do something and see what happens because the speed of AI means you don't have one or two or three years to figure this out. I heard a podcast again from a CEO yesterday. He goes, Oh, we're just, we're moving so fast through stuff.
Brian Milner (27:22) Yeah.
Scott (27:40) It's fun to just see how much market share we're taking from our competitors. We just reinvest it, right? It's obvious, and we're talking months, not over years. So your company is in a spot that they might feel comfortable, but you don't realize that the ice is melting underneath you. You can use AI as something that they'll always want to talk about, but maybe kind of reintroduce this. Hey, given the pace of AI and how we're trying to use AI here, I'm looking for other options to get this feature done, but I'd like more clarity on what we expect to get once we ship this.
That's a great conversation to have. Like whatever that end can be, encourage you take it because what won't work, Brian, that we're kind of joking about is, you know, business as usual won't work the way you've been doing things and handling it the way we're talking about. Yeah, I know it's not awesome for people listening, but my friends, we don't have a lot of time to figure those things out. Your competitors are figuring them out perhaps with AI and it's, dog years faster on all that stuff.
Brian Milner (28:31) Yeah, when you were talking to me, maybe think about like with the mini CEO thing and that they they're in charge of, you know, this, the spend for the company, like, you know, if you've ever been in a school group or youth group or whatever, where you've been given that assignment where they say, All right, every team has $10, you know, go and see how far you can take $10 and see what you can get back. Like the winner is not the person who comes back with like the the greatest number of things. Right?
Scott (28:47) Yeah, I remember.
$10
of bubble gum, right? That's what some would do.
Brian Milner (29:02) Right, right. Like I've got all these pieces so
that I have more pieces than someone else. Does that make me the winner? No, it's what's most valuable. And maybe you only have one thing, but somehow you were able to change that $10 into something that's really, really valuable. And that's kind of what a product owner is trying to do is they're trying to take that investment from the company and turn it into something that's the most valuable return on investment.
Scott (29:08) No.
Really significant. For those who are listening, sincerely, if you've got ways you think are working, put them down there because I think there's so much we learn from different takes, either your company, your industry, that you're in, your sector. But if you figure something out, I'd love to hear that because these are some of the stories I'm hearing from the people in the class that I think are really insightful. And you're helping other people out when like, whether that's the, like you said, the number that we're going to use, what metric, it's not just velocity, or how you influence leadership, how you help kind of reset that conversation so that you have more of a voice to shape. Help me.
understand the strategy that we're doing. And that can help out a lot of people who might feel like I'm just stuck and they don't have any ideas. So I just encourage people put those down there. There's a lot to learn in that and same for obviously, if you went through the Mountain Goat classes, just the mentors community is really, really powerful for people are sharing those things too. So check that out. If you haven't like revisited your subscription, I encourage you check that out because there's a lot of experts that are sharing those same ideas. And for me, when I was starting up, Ryan, hearing that from other people like, oh, I think they just saved me six months of trying to figure that thing out. And they just said,
Brian Milner (30:25) Right.
Scott (30:25) Here's how I approach it and it worked for me. And then I can always say, well, this is what another company does. And that's absolutely valid. That's what they did versus like, I think that they'll do this. Well, I appreciate it. Although we say in the product owner class, your opinion, although interesting, is irrelevant. Because that's just your opinion, right? It's not data. If you could tell me what another company's done, a real data out there, that would really help start the conversation. Just encourage people who feel a little stuck. Try some things out see what you get. You might be really pleasantly surprised.
Brian Milner (30:53) Yeah. Yeah. Awesome. Well, Scott, this has been great. I hope ⁓ our listeners have gotten a lot of this. I have. I think this is just a really important conversation. Me as well. So, ⁓ but thanks for making the time for us. And I know we'll have you on again soon. So thanks for stopping by, Scott.
Scott (31:01) It's been great for me. I don't know what the listeners, but I've really enjoyed it.
Always great, thanks Brian.