AA113 - Debating Outcome-Based vs Output-Based Roadmaps

I have a problem with dates on roadmaps. You have an allergy to dates on roadmaps. Another way to say it is I'm violently allergic to dates on roadmaps. I think anything is not an outcome based roadmap is a Gantt chart or a release plan or a project plan, or a feature delivery plan or a feature factory or keep going, keep going. I can't That was, that was, that was it. Yeah, I'm hoping by the end of this podcast, anyone that listens to it will understand any roadmap where they put dates at the top; why I hate them so much. Hopefully they'll move closer to my side by the end of the podcast. Well, there's your learning objective, everybody. Let's see, at the end of the podcast, if you've learned, there will be a test. No, just kidding. All right, so you don't like dates on a roadmap, and let's just start there. Why? Why do you not like dates on a roadmap? Because everybody wants to put dates on roadmaps, right? So they know when they're getting stuff. Listen, everybody wants to sit around in their pajamas all day. They do. And not put pants on, but everybody doesn't get what everybody wants. Today is no pants day. is it No pants Friday? No pants? Friday? Wait isn't every day? No pants day? If you just decide only if you're working from home. All right. Well, listen, I despise non outcome-based roadmaps because, they're not roadmaps. There are menus handed to you by somebody else and says, I want that. And then you basically don't get to question it. so they're like, a horizontal dart board that you're trying to hit a number on with your eyes closed, basically. You are being dictated somebody else's vision of when things should be done. And, and you know, I, I think there's a lot that goes into it, right? People that are doing this aren't doing it just to stick it to the team. Some might. But for the most part, people are doing that because, they want to hit a date so they can get their bonus because that's how the organization is incenting them. So that's one reason why you might see dates on a roadmap. Well, that's, I mean, that is great from the perspective of, optimizing for, one individual to get paid. As opposed to the entire organization to be successful. If you're in that camp and just want a payday, Thanks for listening to the podcast. Please subscribe. We appreciate you being here. I'll send you my address. You can send a check in the mail. so you get nothing. You lose. Good day, sir. There we go. Perfect. So that's one reason, right? Another reason might be that those people that use dates on roadmaps, well guess what? That's how they grew up to be where they are. They don't know any other way. Yeah, right. They're not open to any other way except I'm gonna put a line and I'm gonna put a dot on it and go hit that. Right? That's your milestone, right? When we get through the rest of this podcast, that is probably the one that I'm gonna empathize the most with, in terms of someone that is like moving the bricks, from one location to another, brick by brick by hand carrying it. Struggling all day and spending the whole day when there's a forklift, like parked 10 feet from them. why would you do that? Yeah. Why would you? Because it's what I always did. Like I, I like they, I have the most empathy for those people that are just so stuck in there. Like they, the end of Shawshank Redemption where the guy gets outta prison and he just can't live, in the new world where everything's faster. I have a lot of empathy for that we'll, we'll get to that point maybe I might cut all this real, real cynical view Yeah. Outta the podcast. But also I might leave it, leave it in you want me to pull up some examples? You wanna zip through it? I don't know. I think I should pull up some examples. Let's, let's do that. All right. Yeah, so let's look at this one for a second. In the screen right now, you've got team A and team B. So you have two teams in here. And you've got, now, next, later, right? Assuming everything that's in the now category is being worked on now by your team, makes sense to me? It does make sense. It says now it makes so much sense, and you have outcome a one, outcome a two for team A, outcome A three, outcome A four for Team B. These would be as measured by, they'd be, metric based. So, decrease churn by 3%. These would be some kind of measured outcome. Being targeted by this team. And then everything this team takes on is in pursuit of these outcomes. So if you are using any ALM tool, could be anyone, could be Jira, but if you're using one, this would be like your epic level or maybe above that. But this would be at least your epic level to say, Hey team A is engaged in, outcome A one, reduce churn by 2%. Yeah. It should be measurable, right? Right. It could be KPIs, it could be they fit nicely here. Yeah. Yeah. I agree. So in, in this example, my leadership has given a goal. A goal backed up by, a metric and has put the team on it until the task is accomplished and we're through it, and then the team can pivot to another top level business priority, whatever the most important business priority is. The team can pivot to it at the time. Yeah. Right. Most important at the time, which is the, the next or later, I mean directly, or if something comes up that it, that everyone agrees is more important than reducing churn in this example. Right. We can just stop reducing churn and call whatever we have done enough and move off to the next thing is if we all decide that. Whatever metric we've come to, we're done enough for now, and we will revisit it later if we don't like oh, we we're shooting for 10%, we got to 8%. We have these other features. There were other things we need to implement that we think are probably more important. Leadership makes a call product, makes call. Boom. We we cut over. Yeah. And we may never get back to it. Sure. It depends, right? Sure, sure. Yeah. Good Enough's, good enough. Yeah, I agree. let's pivot over here and see what a nonsense based roadmap, oh, did I say nonsense? I meant, project based or feature based or time based or output based. Yeah. output based. Go over here. I'm just gonna type in a roadmap. Huh? What do you know? So this is the first result that comes up. Actually, I think this is the second result that comes up. So in the second result that comes up, you have I don't know, looks like milestones. The milestones are across from Are they those milestones? Are these milestones? Yeah. Yeah. Look at them. iOS, alanche and Android. Yeah, mobile. Yeah. Yeah. Those are milestones. And then those, these ones on, down the side here, they're, I dunno what they're large categories of, Groupings like web floor, they look like departments or some kind. Anyway, the point here is I've, I've picked things, Hey, in, in 2020 quarter one, that tells you how date this is in 2020 quarter one, we're gonna develop an Android app and it's gonna finish in 2020, quarter two for my mobile team and for the help desk team in 2020, quarter two, they're gonna update navigation regardless if the help desk team is on fire and all the employees quit. We are committing. I'm assuming this 2020 product strategy is created somewhere near the end of 2019 let's pick November, 2019 let's say quarter two's about to begin in March. I know quarter two starts technically in April, but, November. We're gonna say in four-ish months, regardless of what the team looks like and what they're doing, they're gonna update navigation for the entire, almost the entire quarter. Yeah, yeah, yeah. And, and they're gonna start on a given date. And they're gonna finish finish on a given date. Right, right, right. That has been trust upon them. They didn't come up with these and, and look, I've got lots of stuff, for each of my teams to make sure Om, at Brian and Om's old software development company. Oh yeah. To make sure that, no one's taken advantage of. Brian and Om in Brian and Om's software development company. No one's working 39 and a half hours when they should be working at least 40. At least at a minimum. That's right. So we just gave an example of an outcome-based roadmap and a not outcome-based roadmap. And quite honestly was like what I showed on the screen just now. Regardless if you're a feature based or release plan, or you do a Gantt chart it really doesn't matter. All those style roadmaps, they all pretty much look the same. Let's go into our, section of this podcast where we do, a little, a little back and forth debate. Back, back and forth is good. It's in the spirit of our Arguing agile. Let's, Let me start, to kick this off, by talking about, why I think you should only ever do outcome-based roadmaps, look, point, point number one, is the outcome-based roadmaps over the non-com based roadmaps they 100% focus the business and the teams that work in that business on what matters the most. They focus the teams on what is most valuable, the number one priority, the number one focus for the business and nothing else. So that would be the stuff that's in the now column, presumably, right? Yes. But the problem with that is I'm taking the other side here. Good. those roadmaps lack clarity. I don't see any dates, so there's no predictability. How are we churning through the work? I have no idea. It just says now, now I understand. It's now, how long is the now? When you say next, when does that begin? When does that end and later, will you ever get to my stuff when it's in the later column? What, what is well first of all have we had a discussion if your stuff is more valuable than what's in the now? Because as a product manager, I have. And I have qualitative as well as quantitative data, but also the stuff that's in the now column ties directly into the strategies for the business. So yes, there may be stakeholder management involved. Right. I understand what you're saying is like there are stakeholders, they have their own items and they have their own timelines and they have their own desires, however, Running a good business is clearing all that fog out and say, this is our number one priority. Right? This is our, sorry, I just finished. Good to great. So like in good to great. He's like, you have your hedgehog concept. This is our hedgehog concept, and all the rest of this stuff isn't important now. Now I'm not, I'm not saying don't tell stakeholders that their stuff is important. Do not say that. I'm not saying that on the podcast. Yeah, but what would the PMO do without their GA charts? Uh, not make a bunch of money th that's true. That's true. But they want predictability. Brian, how are you gonna assure them that this will be done by August? I will. 30th, I will assure them predictability by making sure I'm predicting that they will still have a job because we're focusing on the number one thing that matters, like predictability, like predictability. I guess I'm questioning what predictability even means at this point because we are staying on the top priority until we achieve the results for the business that we want. So like, I think about a sales team, get out there and sell the product until we get 10 million in ARR. Get out there and sell the product until we get X percentage of new customers, until we sell 10 new accounts or whatever. Like at what point are you gonna be like, At, at, at what day are you going to sell those 10 accounts? Like you would never do that to a sales team, right? Right. So all I'm lobbying for here is why are you ever gonna do that to a product team? They're working on the top priority. Top priority is let's say for example, the churn for the company is 2%, right? Maybe it's a big company. Churn is 2% cut that in half. Okay, well, I have to analyze why we have churn, why customers quit, what stage do they quit, stuff like that. So if your app isn't built with stats, I've gotta build some stats into it. First you need the telemetry. Absolutely. That's the first. And, and that kind of work, that is not sexy work at all. No, it's not. Yeah. That's retrofitting our app with stats. Yeah and then once I do that, I have to figure out what features are most important. So the problem with the, now that I see on from the contrarian standpoint mm-hmm. Is who, who's deciding what the top priority is. Uh you've got five execs and there are seven top priorities. Yeah. Work on 'em all at the same time. Yeah. Easy product managers are, they're, they're the person in the business that's accountable. And if you, if you're in a business where you don't have product managers, That's cool, like cool. Amazon didn't have product managers back in the day either. What they did was they, they appointed single threaded leaders for initiatives and they went back to those leaders, and then they went into like Amazon Alexa for example. When they launched Alexa, the individual in charge of Alexa wrote a wrote a uh, a six pager. For Alexa and then got funding and got a team and spun up and tried to get Alexa off the ground. There was a, a, there was actually a other initiatives that got launched that led to a, anyway, the, the point is at Amazon, they went back to that single threaded of leader that was in charge from the business and that was a go-to person. So that would've been the person to prioritize. In the real world. I'm not saying Amazon's not the real world. However all for the rest of the real world you have product managers and they make these calls. What happens to companies that have multiple product lines, multiple product managers, everybody's got their P one. What do you do then? Uh, well, hopefully all the product managers have their own teams, and that's not a problem. You live in Nirvana. But also like if you're a product manager and you share. The same team as other product managers. Whoa, boy I can't help you. Like I, there's not a lot of dead ends on the podcast where we're like, we come to a cul-de-sac and we just gotta turn around and go home. But this is definitely one of them what are you doing with your life at that point? learn, learn to code. Like I don't learn to weld. I don't know. You learned to weld? Yes. So one of those outcome-based roadmaps, it requires communication, right? How do you communicate what you do and when? I mean, see, I'm gonna keep going back to that point. I like the challenge of the back and forth of where you're going with this. But I like, I want to paint you down on what you just said, like it requires communication. Like as opposed to not communicating. Oh, no, no. Look, if you have a Gantt chart, you put it up on the wall, virtual wall, whatever. Everybody knows what's happening. I know when things are getting done right. Doesn't need communication, that's overhead. I will, I will take that. Don't get your teams in meetings. Get 'em coding. Also if we're putting the Gant chart on the wall, the challenge is you can't update it. Oh, I, I've got four people doing that full-time updating and ripping down old ones but, but, but also, like I, I, they call the pmo. I like where you're going with this everybody who does maintain a Gantt chart in actuality let me like, let me back up. Let me back up. Cause I have a, I thought of a stronger argument today. Anyone who maintains a Gantt chart updates a Gantt chart. Hold onto to that one. I'm checking my watch of the time because there may have been a side tangent that got cut out of this podcast. Maybe, but if there was the point of the side tangent was all Gantt charts I've ever seen get updated. Yes. Yes, they do. The technical term for that is called a re baselining. Re baselining, or in layman's terms, it's, we plan this out, but it's not working out that way. So let's just update the plan. Right. Right. That's called re baselining In the waterfall world of working, There's a human influence hack about to-do lists. Like if I give you a to-do list and it has too many things for you to do, like you start getting anxious and it starts stressing you out, that's like, no, uh when you have like 58 unread like emails or whatever oh, I come, come back to work on Monday and I'm kind of stressed cause I got a lot of emails or whatever, and I tell people like, mark all is red. And they, they look at me like I'm crazy, but I'm serious mark them all is read. The ones that were important will follow back up with you because the, the just the weight of those unread messages sitting on top of you Oh yeah. I've got all these tasks that I have scheduled for you to have done and you haven't done them yet. Just that weight sitting on top of you. You will not turn in your best work under that pressure. The better way would be to keep your work flexible. To where you choose based on the signal you're receiving, what to work on next. So rather than a Gantt chart, I tell you my top priority and I let you self-manage and or self-organize your way towards the most important work based on data, not based on what was planned by somebody else a month ago, three months ago. I mean, in the example we just looked at, it was five-ish months ago. Yeah. Keeping the work flexible, keeping the ability to go from highest priority to highest priority. Flexible and not tying you into things that were thought of months ago means if something big blows up, you are free to deal with the highest priority item and stay on it until it's no longer the highest priority item, because that is where the most value in the business is Not something that, not, not you have to do it because somebody planned it out for you. Several months ago before they knew about the problems of today. Yeah. So you're really saying that that approach allows you to handle emerging work. Right, right, right. To bring it back to your point, and I just went off in a different direction, bring it back to your point, your point risk communication, meaning like I'm gonna make this plan for you and then you shouldn't need to talk to anyone until you punch out your cogs in the machine. and my pushback to that, what you planned months ago has potentially no relevance to today because the world's moved on. Right, right. Yeah. Makes sense. Because the business needs to be able to move more quickly. I, I'll give you, I'll actually give you an example from experience I was at a company one time and uh, there the majority of the revenue of that company came from one customer. And that customer was threatening to cancel their subscription and leave, which basically would've forced the company to lay off. I mean, at least 50% of the workforce basically. And the product team, development team, executive leadership, had to come together and decide what we could do in the time given to try to save the contract. How are you gonna do that when you're trying to follow a plan that was built six months ago? Well, we, we would like to respond and do whatever, but we're following this plan that people listen to this example that like, are for Gantt charts or whatever gonna be like, well, of course you would throw out the Gant chart at that point and grant new one. Well, at what? Like, at that point, what w what was the point of expending all that time, building that elaborate plan months ahead of time? We could have been. Doing what I'm what I'm elaborating for right now. We could have been being flexible, responding to, to, to what's most valuable in customer input months back, and all that time that went into planning, we could have been using that to actually deliver. Yeah, you, you make a good point. It aligns with the agile ethos of, responding change over following a plan. Right? That's really what that means as well. I went into this a little bit in my previous diatribe here like five minutes ago. A Gantt chart does not allow the team the flexibility to experiment through continuous discovery. Continuous discovery, meaning we're gonna try something, we're gonna put some signal out there, and if we catch fire, we're gonna go deep on that thing. So like what, what I explained a little earlier about like, oh, we're gonna try to decrease churn by 2%, 3%, whatever whatever percentage. Yeah. Or we're gonna try to uh, the, the number of people that try to make it through registration or whatever, we're gonna try to raise that by 5%, well, if that's our goal, we have to start by saying, well, why don't people make it through the whole registration? Maybe it's this, maybe it's this, and then we can try a little bit of something and see if there's signal there. And if the signal doesn't pan out, then we don't do it right. This, this works for business strategy. This works up and down the whole, I know like I've, I'm trying not to be heavyweight with the strategy and vision and mission, , just go with me for a second and don't stop the video at this point. If you are trying a new strategy, oh, I think we could hit in this market. If we just did X, y, z, well, let me go, let me just go try to do X, y, Z for a, a little bit and see if we get any signal. Oh, when I change this and this and this for X, Y, Z, we got 20% more viewership. You know, anybody that runs a YouTube Different thumbnail, different captions, different titles, different subject matter or whatever. And if there's signal, boom, you go off in that direction and you build your, your brand or your product or whatever. You're describing what I call an experimentation mindset. Yeah. Right? Yeah. Try something and then learn from that. Mm-hmm. If it work, great. Do more. Yeah. If it doesn't work, fine. Yeah. Yeah. Have a hypothesis going in, right. Saying If we do this, we expect X to happen. Right. Well, the, again, the opposite of this is I planned for you to do number one, two and three, four months ago, or three months ago in my planning. Or dare I say my PI planning? Oh no. Oh, Brian's being topical today. And basically I told you, that's what I wanted to do. So you gotta get it done. Yeah, I mean, if you're really following the, the old fashioned way of working, it's worse than that because the teams are handed. Work breakdown packages. Yeah. That were designed by, I don't know, a project manager or somebody by the pmo perhaps. Mm-hmm. Go do this. This is how you work. This is your package. Right. That you start on this day. Finish on this day. Right. And. That's it. That's your, that's how you are, you're measured, right? I'll present what I think is actually a legitimate counter to this, which is sometimes you do have to do things that need to be done by certain milestones. Like like for example, if I, I was at a company one time. Where the corporate like holding entity came down. They did an audit of all the IT systems, old school organization, right. And they're like, well, these systems are very, very old. They're at risk for security compliance. All, all not scalable. You know, basically they're, they're very at risk. They should be at end of life basically. And you should probably replace them. And since we're the holding company, we're gonna press you to say, we want them replaced by X date. Yeah. That this is the holding company. They're, if you haven't done it through part of normally knocking down technical risk and keeping the risk of the business low or some people call this architectural runway or technical runway or whatever right. The, the somebody in leadership is gonna say, enough, I don't wanna deal with this risk. Here's your date. Right. Well, indeed there could be penalties, right? If you don't be c compliant by a certain date. So yeah, there's that. There's also other regulatory reasons why this is one of 'em. Sure. But like for example, GDPR kicked in it when it did. Yeah. See, you had to get, you had to by, by then, right? Uh, you had to make sure that all your systems were such that you didn't store personal data in Germany, things like that. But again, like I, I, I bring this up. Because I expect this would be the normal counterpoint that I would be kind of arguing against on this, but I, I see it as a, a, a milestone marker. On the top of your backlog, that just stays there to remind you. And you are now in your, now, next, later. You just stay on this until you hit that compliance and you can clear all your flags or whatever, and then you can move on to whatever else you need because that like being compliant is your business's top priority at that point? Yeah. It's in the A column and all you do is, to your point, yeah. You, you just prioritize those bits of work that gets you to that compliance. Mm-hmm. Over and above the other normal the normal Right pieces of work. Right, right. We've talked a lot about the business. We haven't talked to anything about the teams yet which is what my, my last two points have to do with the teams and the people that the teams are working for, which is number uh, number. I'm not on any numbers. I'm not doing any numbers. You can't, like ai has got nothing on me! Working on outcome-based roadmaps, it's better for the team members. It's better for their skillsets. It's better for the future of their careers. It's better for them, motivationally, organizationally, developmentally, physically, emotion . I like spiritually. But so here's a counterpoint to that. Okay? But, but, but there's no accountability when they fail. Who do I blame when they fail? You are correct. There is, we, we I need a neck to choke. We have a podcast we have a podcast on this. We have a podcast that answers this question about accountability of like, yeah, who do I blame? I need somebody, some person, I need one individual to blame, I would push back against this. Conceptually, conceptually, physically I need to, I need to push back against this whole concept of needing to blame somebody. If blame is required in your organization. You've already failed. First of all, If your organization is as such where you just can't fathom that something could have gone awry or something couldn't have been foreseen and, and you must blame somebody for it. And you don't have a culture where you can learn from mistakes. And you don't have what I was talking about in the previous podcast we did for Clint about these things are unknown, so we should mark them as capabilities and learnings and build them appropriately to the learning bucket where learning and development comes from. If you don't have anything like this and you think that training time should come outta people's personal time and on the weekends or whatever thanks for watching this podcast. So like, let and subscribe like. I, there's not a lot I can do to help if that's where your leadership is going I fundamentally disagree with that method of running a company, running a team, it's not gonna work. You're not gonna get the best people. You're always gonna get stunted results. You're not gonna get creativity. Yeah, so taking, again, I'm staying on. I agree with you, but I'm gonna stay on the other side for bit. Stay on, stay on it but it works for me because I told my management that. I'm gonna get something done by a certain date, and when that didn't happen, I cannot tell my management that I failed. Right, so what I must do is to sacrifice somebody. Sure. So I'm gonna look at the team or team members or whoever and say, you guys failed. You didn't deliver it to my Yeah. Gantt chart based roadmap. Right. If you're stuck in an organization like this, The successful tactic tactic, the, the successful tactic? Yeah. I'll call it tactic. The successful tactic that I've used where you have individuals in the organization, like project managers, psychopaths, narcissists, what, like who, whoever is exhibiting this type of behavior in the organization. And you have to live with them. that's okay. That's okay. What my suggestions for this is I wouldn't get caught alone. I would tackle this as in the entire team because people are naturally very uncomfortable going in front of the entire tribe. And being the one person telling everybody they're wrong and then standing firm in that opinion that the whole team is wrong. Don't let a project manager or a narcissist or whatever separate one person from the whole team and try to pin it on them. And, if your ALM tool or if your work methods, or if your work breakdown or whatever is structured in a way where work is assigned to one individual and it's made that way to be able to target one person, I'd make a slight change to that process if it's within your control first, where work is assigned to a team rather than to a person, and be able to push back on it. But I would try to change that culture from the inside. In tiny steps, if possible, if you can't change that culture. And that's just a culture organization. There's, there's not a lot I can do. I, I can't tell you that, in a culture where people are blaming, you're gonna have failures and you're never gonna learn from the failures. And if you can't learn from failures, you're never gonna develop. And if you're never gonna develop, you're never gonna go anywhere. So if you're okay staying static forever for the rest of your career, or as long as you're working in that place, I mean, that's cool. As long as you understand that like there will be people outside of your organization that are developing, that are learning, that are moving on with their careers, that are progressing and you will be stuck. So don't get stuck around people like that. You don't need that kind of negativity in your life. Nah, nobody's, ain't nobody got time. Ain't nobody got time for that. That's a, that's very true. I thought, I thought your tip was gonna be, if you're stuck in that environment, keep that resume updated. Get outta there. I I almost never tell people to keep that resume up. I almost, I almost never tell people, I worked in one place for a long time and I really liked where I worked, and I, I just, I don't like that advice however, Like narcissists don't have a, their nature is not to move. Their nature is they, they, they are not the planets that revolve around the sun. They're the sun and they think they're, all the planets revolve around them. They burn a lot of people, that's for sure. Yeah. Yeah. and then my last point is that an outcome based roadmap is better for the stakeholders, all of the stakeholders involved because if the team is going deep on whatever the top business priority is, if the top business priority is serving stakeholders, Users, customers, whate, whoever that stakeholder is could be internal developers, whatever. It could be anyone then they know that they're gonna get the full focus of the business and they're gonna get the, the, the results that come with being the full focus of the business. I don't really think you get that when you're trying to you, you're just trying to look busy and you have 87 priorities in the air and you're just saying, look at all my priorities. Don't I look busy? No, no. Yeah, yeah. I concur with that. Yeah. People that are in that mode of working where they've got all these balls in the air and they're trying to catch 'em and the. The focus there tends to be, utilization, right? Keep busy utilization, right? Yeah. Keep busy. That's it. Right? You know, and, and then how you're measured is on your efficiency, right? Yeah. Not on your effectiveness. Right? I like where you're going with this one because I could only imagine like it was my birthday, at Brian and Oman's development company and om gave me a a thousand dollars bill. I gotta go put it in the bank. There you go. Cause I've never seen a thousand dollars bill before. And I walk into the bank and I like, I'm so impressed that. Every teller is exactly 95.6% utilized, and everybody working in the back office doesn't spend more than 25 minutes a day on breaks or whatever. And they're exactly u like I as a customer don't get that. I could I can't think of, I can't think of anything that I care about less than that. I, I, I think about like, is the lobby clean? Is there somewhere to get like a coffee if I have to wait a long time? Like there are so many petty little tiny things that I think of. So if you're saying them being, fully utilized doesn't really do anything for your experience, I would say if I walked up and the teller was, shuffling papers because she had a paper shuffling quota or something like that, like mm-hmm. That, that would be an example of utilization that is in opposition to serving me the main stakeholder of the whole branch. And, uh as soon as I complain about it, of course everyone's gonna freak out and stop what they're doing. Sure. And then all the numbers don't matter anymore, but in an outcome based roadmap, the numbers are the only thing that matters. And if you're bringing customers in, if you go back to the, previous podcast that we did for Clint, what were we talking about? the numbers. If the numbers are the only thing that matters, like what does it matter what, how many cogs my team punched out, or how many stories my team put through, or whatever. The value that the customer gets outta coming into branches within five minutes of walking in the branch, all your, all your problems are gone. In fact, when you walk into a branch, you are probably gonna spend more time just talking about your day and just getting to know the people who work in the branch than you are actually doing business and conducting business and get it done. You're gonna stick around longer than five minutes just because you like being there. That's, that would be the customer experience I would shoot for yeah, I agree. So one last thing on the utilization thing, look. If we measured our, firemen by percent of time that they're utilized, we'd have to set the city on fire all the freaking time. Right. Hey, they're busy putting out fires. Oh, what do you mean there's not enough fires for the put out Light? Some more light. Light, some more fires. Yeah. Tell the firemen to light some fires. Why? Why are they called firemen? Om, if they're not lighting fires So, this podcast we've talked about, why I hate anything other than outcome-based roadmaps, and we've kind of argued back and forth, hopefully, this has kind of helped you and armed you and, , brought you a little awareness of bringing back to your companies, to push back against Gantt charts that they call feature based roadmaps or project based roadmaps or, yeah, hopefully now you'll have an allergic reaction next time you see dates on a roadmap. Yeah. Hopefully you will also have the same reaction that I have, when you see roadmaps like this and you can say, oh, I love working on feature based r oadmaps. Well, that's it. That's a wrap thank you everybody for staying with us and yeah and subscribe. Let us know. That's great. What topics you would like us to tackle next? Go to ArguingAgile.com. Fill out the form. You can even leave us a little voice memo there. That's right. And we'll respond accordingly.