AA150 - Things You Don't Say Out Loud in Agile (with Mike Miller)

Senior Product Coach Mike Miller is back on the Podcast, joining Brian & Om for a fun and lightweight podcast discussion about the unspoken realities of agile software development!

Get ready to talk about all those elephants in corners - from the unspoken challenges teams experience, to budgeting woes, to inflated titles, to unclear goals and value propositions!

0:00 Topic Intro: Things You Don't Say Out Loud in Agile
0:19 Project Managers Retitled to Product Manager
2:40 Product vs Project
4:17 Truer for Scrum Masters?
10:33 Middle Management is Unnecessary
18:41 Peering is Rare
22:45 Systems over Agile Coaching
27:25 Annual Budgeting is King
34:50 Backlog Managers are the Norm
38:36 PO as Delivery Manager
40:21 Product Goals (Do they Exist?)
43:11 Strategy (It's Hard, and also Rare)
47:23 More on Backlogs & Prioritization
50:25 Customer Value - what Value?
52:05 Value Must be Defined
55:10 PO/SM with Technical Knowledge
58:48 The Typical Answers
1:02:50 Wrap-Up

= = = = = = = = = = = =
Watch it on YouTube
 
Subscribe on YouTube: https://www.youtube.com/@arguingagile
= = = = = = = = = = = =
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = = 
AA150 - Things You Don't Say Out Loud in Agile

Transcript

0:00

Senior product management coach. Mike Miller is back on the podcast. you're taxing my, capabilities right now. the podcast topic for today, which is slightly tongue in cheek, is things you do not say out loud in Agile. this promises to be good. What things do we not say out loud in Agile? I don't know. Om, do you want to pick one of these? I don't know. Right. Most agilists are former PMS looking to stay relevant project managers. Ooh, is that true? I'm not a project manager. Ohm was a project manager. I'm not a project manager. I'm not looking to stay irrelevant though. No, you're right. You see a plethora of the project management elite. They've now put on new hats. Cause they've got new certs. And they're suddenly transformed into project managers. Sorry, product managers. They were project, and now they are product. And they don't even have to change their initials. I, so I want to say in maybe 2015, at least like here in the South, like on the East coast Agile was picking up steam product management was people were beginning to question the value of, of, of project managers. And then I had a lot of Project managers coming to me asking, What is this Agile thing? Like, how do I, how do I get on that bandwagon? And, it's, for me, it's like, it's not a, it's not a bandwagon. It's just a, it's a better way of working. And like, when, when, when I was first introduced into Agile, like there was no, for me, like there were no consulting companies, there were no certificates, none of that was involved. Like we were we had found some stuff on the web. It seemed to make sense. We wanted to give it a try. We did. We, we wrestled with it for six months. Until finally we kind of like all the water in the tub kind of settled out. And we hit our stride. And then over the course of the next year and a half, two, three years, well, I mean, we, we started cranking. But that was because it made, it intrinsically made sense to us. We saw the value in it and we wanted to see how we could get it to work for us. I think a lot of what you see even with PMI so the, the, the Project Management Institute. So, they resisted and resisted and resisted and they were set up to increase the value of project managers. Eventually, they jumped on the bandwagon. They have Agile certifications now that, that, that you can get through PMI. And I have seen personally a lot of project managers switch over into Agile or try to, or at least go out and get a certificate and, so that they could somewhat credibly make the claim that they were Agile. And, and some of them do it with good intentions, and some of them do it well, but I, I just think that there's a whole boatload of them that did it just so that they could get the next job. Right. Or get the next raise, or get the, and for me, it's not, it's not about that. I, I've never been a project manager, so I'm, I'm on the outs of this bullet point. However, I will like to piggyback on top of this, I will say in product management. There is a lot of project management inside of product management. Like, product management has its arms around project management in some way, shape, or form. Like, there is a percentage of a product manager's time that is taken up with project management. I wish it wasn't that way. Well, you can call it whatever you want to call it. Like, cause some people call it like, Oh, you got to be a operator, have operation skills or whatever. But there is a certain amount of like this by this date with these resources and this, you know what I mean? Yeah, there is. And, and I mean, where my brain goes, like when you say that it's like for release planning. And so like with release planning, and I've seen this, I've got anecdotal evidence of this is that every product manager, like every real product manager that you're going to come across. That's been doing it a while. They have an Excel file or a Google sheet that they created based on somebody else's template that are, include all of the things that they have to do for a release plan for the organization where they're at, where they created it. And then they keep that. And then they go to their next job and they adapt it. And then they meet other product managers and other product people. At I think like two jobs ago my chief product officer, he had one. And so I got his and I compared that with mine. And so you see a lot of project management, Gantt and style start things in the release planning. But then there's a lot of things that, that you can do as a, that you do do as a product manager that, that aren't product management. Is this more true on the scrum master side? Do you think? Yes, definitely. So I think, yes, definitely. So absolutely. I can see I can see again, I'm on the. I guess here we go again. I'm on the product management side of the podcast. So I'm trying to apply this to the product management side. That's where I'm having difficulty seeing if it's true or not. They got, there's like, I can see a lot of like BAs who are now reframed or rec retitled. As product managers, but they're not empowered or whatever. That's for me, like the, the progression if you get involved with products, like you could start out as a business analyst. So a lot of times like business analysts, like what are they, what are they paying to do their. They're paid to hold a model in their head and keep that model current. And that could be the model of your product and how it operates. And so you've got like the, the BSA is the business systems analyst, but then they, but they, they could also be doing like the market or the customer or some segment and so that they become a resource now for. a product manager to go and talk to. So what's the natural progression from a BA? Well, junior product manager, right? And then, and then they go from there. So, I mean, for me, that's, that's very logical, but I think that, that. Agile when it came out and I mean remember it was like they signed the thing in what like 2001? 2001. Yeah. And then it takes time for it to spread you know, so it was probably, I want to say 2011, 2000, early 2012 before I, it was even on my radar. But by that point, like I'd been in IT for five, six, seven years and it wasn't even a thing and then I just started hearing about it and then we started looking it up and then we took it from there on our own but rapid growth. In, in agile and adoption of agile or companies that were willing to experiment with it, it scared a lot of the traditional project managers. And so then they jumped on a bandwagon and they didn't come at it from the angle. And I'm not saying that everybody has. to do it the way that I did it. I'm not saying that at all, but I got to see it without the commercialization. And so we were using it because we felt that there was value there. If you're a project manager and you're suddenly afraid of your job, because before you had 12 postings online for a project manager position, and now you've got eight for a scrum master and four for a project manager, that would scare anybody. Yeah. Right. And now you have to make a change. And what do you do? Well, you change the word, but you don't change the meaning. Now I'm not a, I'm not a project manager. I'm not, I'm a scrum master. I like, I like how you said that you change the word, you don't change the meaning. You also don't change your behavior because it's hard to do that like quickly. Right. Right. Definitely on the, on the scrum master side, there's a natural inclination for project managers to come in and quote unquote, manage the team, manage the project. So, all they've done before that is core project management. Treating people like resources, measuring their utilization, handing over work breakdown packages to people and essentially letting people work, but very closely supervised. I guess I'm trying to say that they were essentially taskmasters at the end of the day. Well, you, you changed your job title, but you changed literally nothing about the way you worked. Right. I've interviewed project managers who are making the transition into either product management or scrum mastery or whatever. And the thing that I will interview for is. You, whether you have had a revelation about there is a change in the way that you work or if you've just remarket, relabeled and marketing yourself differently. I guess the point, I think this was mine. The point is, is that I feel like that there are a lot of people that have remarketed themselves. Yeah. They saw the salaries that Scrum Master started to pull down. And, and, and right now I feel like there's a, there's a contraction in the agile space. Definitely. That's another. Conversation certainly is another podcast. Yeah. But they, they saw a growth in that area and they felt like the, the skills were transferable, you said, like if they didn't have that, aha moment, like I say, like it, it, if it doesn't click, right. If it doesn't snap into place, if it doesn't fit into place, then I mean, what you're looking at or. Project managers that are parroting agile vocabulary without being able to put the principles and values into practice. Yeah, the scary part of that is when they come through the interview. Pipeline, you know what I mean? They're like coming in through the interview pipeline. I like I can't I can't be around to interview every single one of these people To to check So you can find someone who can speak the language who really is just like they're I've got to think about a way to I think about a way to say this on the podcast they can speak the language, but they're really just they're really just changing directions with whatever way the wind blows. And that's, that is a, that's a problem. So, yeah, no, that's, that's, that's very true. You get these opportunists that jump on the bandwagon. They see that there's a chance for them to to get more glory, to get more money, to get more prestige, to get more power. And that was never kind of the intent, at least my understanding of it, behind Agile. It was, it was to work better. It was to make not exactly sweatshop conditions. I don't think software developers work, you know. In sweatshop conditions, at least not the ones that I work with. But to make it better as opposed to having a task master, that it became a more collaborative process between engineering and product. And that was why you had like the, the, the trifecta, right? The trifecta is like, you're the scrum master. Who's looking at the team performance, the product owner, who's looking at the product value. And then you've got the the engineer. That's telling you whether or not it's feasible or how we can best go about this. And so you've got that, that, that Holy Trinity of, of engineering performance and product, like that combination makes sense to me, right? If you're not able to engage in that process in good faith. I don't think you're going to get optimal outcomes. I think one of the things that also makes it difficult is at that time, in the timeline when project managers were transitioning into product, or scrum mastery for that matter, middle managers that were kind of above them were prizing and demanding the same thing that these people were doing before. You know, status reports and Gantt charts and utilization, things like that. Oh boy, buckle up and get ready for the podcast of the tyranny of middle management. That should, that should be a podcast. We go back so often, like Alphonse, where are you, man? Where are you Alphonso? Like we need you we go back to the, Taylorism podcast so many times because like this stuff hasn't changed in a hundred years It was it was conceptualized of hey, I need a timekeeper and I need a person who's standing there with a top Stopwatch to tell you how fast you carry the pick iron from the train car back, and if you're not meeting the optimal amount of time, we have the disciplinarian and they, and they tell you like, Hey, if you don't meet the time in the next two trips, we're going to fire you or whatever and kick you out and, the artifacts of that culture survive and they're unnecessary. They're completely unnecessary. Here we go. I'm throwing one out right now that, that middle management layer that is left over from a hundred years of Taylorism is completely unnecessary or the, the, the teams can manage themselves. The teams can organize themselves. Because what we're doing when we ask teams to manage themselves is we're taking a bit of leadership And we're saying we're gonna delegate this leadership to you the team the the cohesive body of the team and then like the The arguing power already throughout the arguing point now the the arguing point against this is like wow when you delegate to a team And it's a group of people you're basically delegating to nobody it needs to be one person's responsibility. Okay, fine It could be one person it could be the Product manager's job or the scrum master's job, whatever. The most senior person on the team engineer, whatever's job, it doesn't matter whoever, whoever, if you want to go to one person, that's fine. It doesn't matter. You should be the product manager, but the, the, the, the whole middle layer, this is the other thing you say in, in, in agile that you like, we work around. The middle layer of organizations a lot. Really, we need the top layer that sets the direction for the organization and the bottom layer that does the work. And we really don't need a lot of the intermediary middle layers. We really don't need that. That's like, and like a very few agile coaches are willing to say I don't need any of these people, get them out of my way, get them out of my process. You just, you, leadership, you, the people at the top of the organization, tell me where you want to go, communicate directly with me, and we, the team, will steer talking directly to the customers in the direction we want to go, and be successful. Yeah, I mean, in, when I was a director of of product owners, what I spent a lot of time doing was mentoring them. Making sure that they could do their job, giving them the tools that they needed, giving them the confidence, like building them up so that they didn't need me around. Like I was literally trying as hard as I could go to work myself out of a job. And apparently I did. So see, but it was one of my product owners that took over. See, that's a little bit different to me because , let's pretend for a second that Brian and Ohm's development software development company, we fire all the middle management, Ohm, get on board with this. We're firing all our middle, middle management. I'm already on board. So this is BO software. Yes, yes listen, I lose either way. This is Brian Orlando software. I lose either way. We're firing all the middle managers and we're going to delegate to the teams. Well, there goes my brain. Like, so I'm going to argue that you do need. Some senior people, but that they should, their behavior should be that of servant leaders and that their focus should be on building the skills and the, the, the capabilities of, of the people that they serve. Right? Right. And so like when, when I was a director of agile product owners, it was all about what I could do to empower them to be successful because they were working with the teams that were building the software. Now, I mean, did I, did I wield some influence? Did I nudge things here and there? Yeah. I did. Everybody's got, well, that's different because in, in the model where you're basically the first amongst equals Oh, I'll throw that one out. I don't say amongst often on the podcast, but if you're the weird, if you're the first amongst equals that basically, what does that mean? You're probably the hiring manager. You know, you're the gatekeeper for product management in the organization. You, you, and also, if your product managers, if your product managers leave the organization, and your teams are left without a product manager for a period of time until you hire a new one, you probably step in. And, and, leadership probably trusts you implicitly to say, well, well, Mike, we know he's such a good product manager, if we deploy him to Anywhere, we'll like, we'll have successful product management in wherever we deploy them to. So again, when you manage people, your job ends up being making sure those people are developing and people coming in and out and whatnot. It's, it's less of the day to day, Operations of product management and more of supporting the people in product management. But I think that, that middle layer that you're talking about that arguably needs to be downsized, they're, they're not. They have business performance metrics that they have to hit like, but they, they're not spending their time growing their people. They're not spending their time growing skill sets. They're not spending their time mentoring unless it's their protege that's going to take their place when, when they get invited to the to the executive suite. And my argument is, I mean, basically it's an argument for like a matrixed organization. Even if you don't have a matrixed organization, if you're responsible for a group of people that share the same core capabilities, professional responsibilities, then your job is to upskill them. Right? Branson said what was it that he said? He said something about don't train your people, rather so they leave or so they don't have, so they, train your people so they don't have to leave. Train your, train your people so that they can leave, but treat them well enough so that they won't want to. So they don't have to leave. I knew it'd get tight between us. So it's something along those lines. Yeah. It's some of the best bosses I've ever had were deeply concerned about where I was going with my career and my skill sets took an interest in me, spent time with me, sat down at my desk, not me sitting at their desk, they sat down at my desk and, and mentored me. And that was how my skills grew. And so, if you don't, if, if you have a middle management layer that is counting widgets produced by a team, that should be the product's job. The product performance is product's job. Right? And they're the ones that should be held accountable for that. I think it comes down to how the middle management is rewarded, right? If they're rewarded on Simply utilization of their subordinates, then you're not going to get them to upscale their teams. Because why waste time training them? They should be being billable and utilized, right? So it depends, right? Part of their assessment should be how are you growing the skill sets of people that you're above, right? And that's not often the case. I mean, how many, how many managers, senior managers, directors have a metric that says that their bonus is tied to how many of their people got promoted internally? Great. Unnecessary. Like, they're all gone. Sorry. Flag on the play. Nobody does that. That's right. Like, unnecessary. There is very little here that cannot be delegated to the teams that I'm hearing like, I don't, I don't like, Oh, my team doesn't know how to interview. Well, that that's why I have HR people. Let me put one on your team for you know, until you have your people. I think you need those skilled people. I think you need those, like the, the skilled agile coaches that's going back in training and working with the scrum masters to grow their scrum masters. You need a senior product manager. The product owner, whatever you want to call them, that's going back and that's teaching those other product managers and product owners like how to be better at their jobs. Like you need lead engineers going back and mentoring other engineers and bringing them up. You need juniors sitting with seniors so that the juniors learn. And like, I think that's something that it feels like our model is like fundamentally flawed. Like, like that mentorship, it's not a formalized part of the part of the model. It just, I mean, it kind of happens. That kind of happens on the side. And that's why when those people, when you do mentor someone and you make a huge impact, like you get Christmas cards, you get happy birthdays from them. Like 10 years later, like. It's because you made an impact on their life. Right. Instead of you counting widgets like you stopped and took some time and made an impact in somebody's life. Then it made their life, their career better. Oh, that's what we should all be trying to do. Speaking of having an impact on people's lives like this is not on our agenda, but I'm going to bring it up anyway. I'm like, this is my guerrilla agenda. I can't work this way. Too late. You're here. What's the Alistair Coburn quote. He's something about like, we never expected anyone to do, to do scrum and not do XP. It was Jeff Sutherland, I think it was in his first book the one about how to use three people to go to the moon or get a million, get a, get a million man hours done in a week. I don't know, but it was, it was that book. And I believe, I don't know if, I think it was Jeff Sutherland but it might've been Alistair Coburn, but we never expected people. To adopt scrum, like without adopting like XP without XP. Yeah, I like the core tenant. I remember reading the tweets saying We never expected that you would pick up this way of working and not also do XP, which is funny because like, I think about the work centers that I've been in and the development teams I've interacted with and how few of them truly are doing peering or mob programming. That first development team, where we were trying to do Scrum, they started to do the code reviews on their own because they thought they read it somewhere and it sounded like a good idea. And I think, and, and maybe I'm going to get this wrong, maybe I'm not, but it was, it was Schwaber that wanted to cut some of the hardcore engineering stuff like out of that scrum model so that it could be more broadly applicable. Sure. And I guess he won that argument. And so Scrum is intentionally half baked. I believe Mike Cohn has said that Scrum is intentionally half baked. But, and this is the difference between like a good Scrum Master and somebody who's like a Scrum Master in name only. A good Scrum Master already knows that Scrum is only half baked. And that there are other things that you have to do. Everybody talks about user stories. Scrum doesn't talk about user stories. That comes from XP. That's right. And so the, the code reviews, the, the write the test before you write the code all of that stuff comes over from XP because it was the Agile manifesto for software development. Right. It was not the Agile manifesto for feeling good. Yeah. Or baking cookies. Yeah. Or making widgets. It was the Agile Manifesto for software development. And so when you put those two, two bodies frameworks, I guess if you want to call them that, but when you put those two things together, you really start to see better outcomes. Like with, with your teams, with your product teams practices. Because now, you're striving for You've got the product owner or product manager pushing for product excellence. You've got those XP elements that are pushing for engineering excellence, right? And then you've got that scrum master that's pushing for team performance excellence. And that's when the magic really starts to happen. Here's, here's another thing. We didn't write this down on a sticky two is that like scrum masters, what I've seen like over the past five or six years as scrum masters. are scared to have team performance metrics tied to their bonuses. They're scared. I mean, and having lived and worked in product I'm scared every day of my life. I'm always being judged by the market. I'm always being judged by the market. But when you, if you do the work, you get it right. Or right enough. And having scrum masters that don't have any kind of time back to team performance. So then how can you measure their performance? That's what they're there for. Product owners are for products. Scrum masters is for, are for team performance. So, and I don't mean like. Oh, you know what the team has done on average 15 more story points this quarter over last quarter. That's not what I'm talking about I'm talking about whether or not like the team Matures whether or not the team's outputs are more valuable. Yeah This quarter than they were last quarter. Can we measure that? And that's what I think that the Scrum Masters money should be tied to. It should be, but I think some of that is attributed to the fact that, like you said, some of the Scrum Masters, a lot of the Scrum Masters perhaps, are basically treating the Scrum Guide as the Bible, you know. And just doing, it doesn't say that in the Scrum Guide, so we're not doing it. Sacred cows. Yeah. I feel like there's, there's something to be said here about if the system is broken, there's really nothing a scrum master or anyone in leadership, honestly, they're all just playing the game inside of the rules. Of the system. Which, which system? Which system are you talking about? A lot of people that call themselves Agile Coaches, they throw system around. Yeah, yeah, well, if you're playing a board game, and there are rules, Right, it's a rule set. It's a system. You're not allowed to think outside the box. Those are the rules. If you're in a large organization, I like to beat up scaling, and a lot of people online are beating up safe too, but But there is a lot of models that have popped up trying to sell their wares on the internet or whatever. Can I phone a friend? I'm going to have to call Dean Leffingwell. There's a lot of people trying to sell their wares about, oh no, we know the right way. To scale and have multiple teams contribute to your backlog and hit your deliverables on a faster basis or whatever. Cause we can add more teams and not slow down or whatever., like I would argue all the people you have working. On software development and all the people you have trying to hit your business objectives like and all the models that we have on the market for quote scaling that's not an agile problem. Scaling is an org design problem and I feel like you're not going to hire an agile coach who's like you have org design issues. I can't really help you. Like you, you, you leadership has to solve your org design issues before anything I could do is effective. So, I once gave like a talk, I think it was at like the Florida Open Agile or Open Agile Florida or whatever it was called. I think the title of the talk was like, so you want to be an Agile coach? I remember that. And I think a lot of people came out of that talk, and what I was saying just went whoop! Oh no. And what I was saying was that Like, for me before I ever dared call myself an Agile Coach in public, I might have practiced a few times in the mirror at home. But before I did that in public, I wanted to make sure that I had Wide experience, Scrum Master, Product Owner wide experience, multiple frameworks, and deep experience. Right? And, but I had been involved in some Agile transformations, that I had worked on multiple teams, that I had worked on multiple products, in multiple enterprises, that I had some kind of experience to, to, to fall back on, to use. To overlay with some of the models to see kind of like what was really going on. And I think a lot of people, some of the people in that talk, I know failed to pick up on that, that you're, you need to go deep and you need to go wide. The scaling frameworks And I have an SPC, I'm not going to lie. I had a scrum at scale cert that I didn't renew because it was just too expensive. And there are there market leaders in scaling agile? Yes, there are market leaders in scaling agile. Like right now I think safe has probably got the, the, the largest market share. But this, I agree with you, the scaling frameworks are not going to solve. Organizational problems. And you see this now when you try to institute safe and some places are doing it successfully, but a lot of places struggle with it. And then you start to see tension between this change where they're trying to adopt safe. And then like the, the, the C suite, right? There's, there's tension there. There's always going to be tensions there with middle management, middle management. Anytime somebody says agile, middle management, the first ones to feel threatened for sure, because they're not mentioned in the scrum guide and that terrifies them. But. The natural progression for me, bring this home, Mike, Scrum Master, right? Senior Scrum Master, Agile Coach, Enterprise Agile Coach. I think that the next step is, is you become some kind of consultant, guru, or whatever that's focused on org design to, to help people redesign their orgs that can, at, I don't want to say Agile, but respond at nearly the same pace as the market is changing. At nearly the same pace as the customers are changing. I think that's the natural progression. I don't think people are taking it there. I know that there are some people in the Agile space that are working on things like that, that have written a book or two I don't think enough people are talking about Yeah, I think what happens, from what I've seen, is A scrum master would call themselves an agile coach as soon as they have a couple of teams. Yeah, exactly. That's exactly right. And what doesn't help is people say, well, there's no shifts. Then you guys an agile coach you're doing coaching. If you're a scrum master, I got to interject right here. Something that you don't say out loud and agile. I'm an actual coach. Oh, so you, you've been a scrum master for two teams. Oh my God. Oh, that's too much. What else we got going on here? if the funding model is the traditional. Funding model don't bother trying to go listen like this is this is mine I will surely represent this topic if you're on a traditional funding model finance Yearly ask for the money you need and then if you don't use it by the end of the year, we're going to take it away or whatever. If you're on a traditional funding model, not any kind of like new fandangled micro budgeting or whatever. Like, and your people that are actually doing the work are not exposed to the finances or the organization decides, Ooh, that's sensitive information. We can't share financial information with you. You're going to be very limited in the amount of agility that you. can apply in that case. I can't argue with that because I've seen it too many times. It's the annual budgeting process that, and you just have to hope that that budget's going to be enough for that year, no matter what happens. Like, like there were people in the government that studied diseases that saw COVID coming. Like there was, I believe that there, there was a, there was a book, there was a plan, like. At the White House that was laid out like they knew that it was coming. It wasn't to some people It was not a surprise. Mm hmm, right to the rest of us. It was a complete and utter surprise and so the government, government's leadership, like whatever, they were, they didn't have that information. They weren't keyed in on that information. They couldn't act on that information. It's the same in business though. There are people that understand Agile Finance. Now, there, there are, and I'm, I'm not one of them. Like, I understand about that much in terms of like Agile Finance. I know how to get it started. That's about it. But there are some people that understand it and they, and they're people that understand. The changes that you have to make in the organization in order to make that work like on a, on a larger scale. But because their number is limited, because nobody's talking about, there's not widespread talk about agile contracts. Right? Agile contracts are They're, they're ongoing and they're contingent. We know, we did a whole episode on that. Right. We did. Absolutely. And it's not a foreign concept, but how many people, how many organizations, how many of our peers do you know that are using them? A lot of people that I've interacted with, they think that's like somebody else's job. Oh, contracts is somebody else's job. Finance is somebody else's job. You know, well, I've never been exposed to that before, so I don't think that I'm there's some it's not FOMO, what is it, it's I don't think I'm qualified. You're right, yeah, there's a little bit of not by job, but also a little bit of I'm not qualified for that. going on. You know, if you, I would, I would say that if you're any kind of program manager if you're in product management and your company has more than one product, if you're a safe RTE or involved in like That, that portfolio level of safe or whatever, I think these are, these are questions that people should be asking. These are conversations that people should be broaching. These are things that people should be pushing towards because that's when you have like a. A finance model that isn't the dead weight of 365 days of false predictions hanging around your neck. Like when you, when you're a little bit more responsive than that, when you can change. Even every business quarter would be a better change. Right? And we've seen this like when you have, it's like Shark Tank. I've been at companies where they had innovation committees, where they would go in and they would place bets on certain things, and those bets were usually in some type of funding. Yeah. And then they would place a bet for a business quarter, and then they would say, come back. Yeah. We, we think this idea has legs. We want you to go develop it to this point, A, B, and C. Then come back, and then we'll look. I think the, the discerning product manager Has the ability to step in now and say, Hey, we, we think this idea has legs. Okay. Like me, the product manager, I'm stepping in at this point in the, in the discussion and say, okay, cool. How much money are you willing to put forward to experiment, to test the market, to see if this idea has legs, because the, the, the finance people, the project people, whatever, the, the c-suite people, whatever, they have an idea of how many dollars they'd be willing to spend to, to test it. It's just that the, I feel, the, the, the quote agile people are not good at, at, at, at having this discussion right now. How much are you willing to spend to find out if there is market signal for this? And, and, and whatever your answer is, okay, well that translates to this many sprints, so we have this long to figure out if there's signal. It should be, I mean, if you really think about it, it should be a really easy formula. My team costs this much to fund. Yep. You're willing to spend. Whatever. 100, 000. Whatever. Do you mean to just figure out the signal? Okay. Well, a hundred thousand divided by my main team's cost, to figure out if there's a signal and then you're ready to try to, to, to, to go into that market. I think there's one thing that's missing from your equation. And that one thing is that is, is a defined. metric that they're trying to to hit with this experiment. So I think if you have those three things, right, I think if you know like the run rate of your team, like how much your team costs. Yeah. And again, companies, especially large enterprises, they don't, they don't want to tell scrum masters and they don't want to tell product owners, product managers even, what the run rates of the teams are. And when you're disclosing the run rate of a team, you're not giving someone someone's individual salary. No, it's a blended rate. It's just the cost of the team. He could easily derive it with a blended hourly rate. So some companies use like a stand in number. Some companies use the actual number. Or some, or maybe they use last year's actual number. Like, whatever. But, I mean, there's gotta be a number there. There's gotta be. You know, we're willing to make a bet in this many man hours, this many dollars, right? That that's got to have some relationship to the run rate of the team. And then there's got to be a metric that you're trying to, to hit. I mean, so my grandfather took me fishing my entire childhood. I loved my grandfather. He was a very important person to me. I hated fishing. Absolutely hated it. But, he would not sit in one place, and throw his rod out over and over and over and over again and get nothing. He wouldn't do it. He had a time limit, and he would get back in the boat, crank up the engine, take off, go to another spot, and try there. And there's no difference with that, between that, and he, he knew where fish lived. He knew how they behaved. He knew his target market and we, companies don't, they can't behave like that. they get into this for the fallacy of the sunk costs, right? They get into like everybody always in product management goes back to Blockbuster and Netflix. I still call Best Buy Blockbuster, by the way. They're both blue. And in my mind, they're the same. Netflix, the two guys walked into Blockbuster and offered to sell Netflix to Blockbuster and Blockbuster said no for no other reason than Blockbuster could not envision any kind of business or business model or activity outside of their current business model. They were not willing to make any kind of changes to run any kind of experiment to do anything differently than what they had always done. Yeah. And it sunk them. Again, this whole category, like as a product person, this a bad business decision that's going to sink my whole team? Like that, that, that, that like a small business owner weight should be on you as a product person, right? If, if the, if the, if the funding is there. If your communication with customers is there, if your understanding of the market is there all the variables being in place and watching you to have that weight on top of you. And this is why this is why like another, thing that you don't say out loud. In Agile, usually, and I think Agile coaches can see this from like across the room clearly is like, Oh, all these backlog items, all these PBIs or stories or epics or whatever, like none of these have the customer in mind. Like none of these are moving the needle. As a product person, I clearly see, you're producing features and they don't connect to value to the customer as like that's an existential threat for me but gosh, the majority of teams that I've seen out there that are flying around the majority of product backlog items and features that are out there. Oh boy, they're way off the mark. I've been, no, I've been there and, I've worked on products and worked with teams where the bottom of my backlog was a graveyard. That was, if I didn't like your idea, if I didn't see merit in your idea and you stopped me in the hallway I would definitely make you a, a, a product backlog item. Like, I'd give you the JIRA URL and that thing would be buried at the bottom and we spent all of our time at the top. And I've seen this first hand too many times, too many times to count where the idea of a product owner is less about owning a product and more about owning A backlog, of really being a backlog manager. You're not even a backlog owner per se, you're just a backlog manager. Yep, absolutely agree, and not necessarily even doing a great job at that, because you may have hundreds and hundreds of items in your backlog. Yeah. But just to go back to what you were saying, a lot of so called user stories have nothing to do with the user. When you look at the backlog. One of the big mistakes that I see, and it's becoming more important to me like the longer I spend in Agile and in product management, is that that whole value. So we were talking about the acronyms earlier before the podcast, so DOVE, right? The V is value. Like valuable. There has to be some kind of value in there. But what I see over and over and over again In all kinds of different Agile product manager, project management tools or product management tools is there's sometimes there's not even a way for you to input value without having to create like a custom field. Like it's not, it's not standard, right? There's no standard measurement of value. It depends on your business, but people aren't even trying. That's because a lot of those kinds of tools evolved from project management tools, which at that point we didn't care about value. We just cared about when's it going to be done. And if that's what you prize, then you'll get that. But what about the quality? Feature factories, so like when you have stakeholders that, that argue that, that where prioritization is not systematic, right? There's no math involved. If there's no math, I'm just going to say this, if there's no math involved in the way that you prioritize things, you're doing it wrong. I don't care what you're calculating, it could be the value, it could be return on investment, it could be projected earnings, it could be cost of delay or whatever. There should be some numbers involved. If there are no numbers involved, if there's no math involved, then it's, people, oh, use Moscow. Well, when you use Moscow, then And you have three stakeholders and they each have four things. Everything, all 12 things. Everything, everything's priority. Yeah, exactly. Everything's priority. What do you do when you have 12 must haves? You have to have a way to differentiate. You have to. And if you don't, you're not going to make any headway. None whatsoever. Very true. And then your backlog will turn into a garbage dump. This is what you're talking about right now, I think. Yeah. Most PO's are little more than delivery managers. Well, so, yeah, I mean, we were talking about the backlog, but yeah, I mean, they're, people aren't concerned with value, they're concerned with, it's almost like the management or the powers that be are more concerned with the number of features that you pump out. Opposed, as opposed to whether or not you're moving the needle on some aspect of customer satisfaction, customer delight value for the end user. There are, I can tell you now like in the credit and debit card industry, there are a small number of people already in the United States. And when I say a small number of people, I don't mean six. I mean like ten thousand. That have the same chip that's in your debit card in their wrist or a similar one and when they go to those contactless payment things, they just wave their wrist at the. Now I'm not an expert in that field, even though I have worked in finance for the past four or five years. There are a lot of questions. Oh, absolutely. I have a lot of questions. About that. But, that is obviously a direction that things are going. Whether it becomes mass market or not, I don't know. It depends on how easy it is to do. It depends on the transportability of the information or the updatability of the, you know. Every time I switch banks or get a new credit card, you are not cutting my wrist. Like, that's not how that works. So there, I have a lot of questions, but that is the direction that things are going. That's not where things are right now, but there are a small number of people from a societal point of view, that are already experimenting with this. There are companies that are doing it. There are companies that are tied, their financial systems are tied to that chip. There are companies that are implanting those chips. There are customers that are using those chips. How many people are betting on that? First of all you can keep your chips to yourself. But second of all, and second of all don't take your eyes off me. That's right. We'll get you implanted before the end of this podcast. Oh, no, it's fine. Everything's fine. The, the idea that most POs are not thinking about like a, Hey, well, most people take a chip implant to be able to just wave their hand. What are you some Jedi who wave their hand and pay for things? Here's the way I think about this. Most backlogs are not written with the stories contributing to a business outcome, most backlogs that I've seen are written from the perspective of there's a, a, a, a feature deliverable at a high level that we need to deliver. And here's a bunch of stories that when we basically when we're. The 80, 20 solution where we're 80 percent done with the features. We'll just cut it and say, this is enough and we're done. We were done delivering to this feature, right? Most people don't have a backlog where the epics or whatever whatever system you're using could be Jira. It could be anything like epics of the super epics. Whatever the high level is they're not like business problems. Mike Miller, the welcome to Brian and Om software development company. You're now the director of software development. Okay. You're going to sit in front of Brian and Om. At a very uncomfortable meeting. We're gonna make it uncomfortable. Don't, don't ask how we make it uncomfortable. I'm uncomfortable now. We're gonna say, , Mike, here's what we need from you. In order to buy the next size yacht, we need 20 percent more revenue out of the customers that we have. So go figure out how to extract 20 percent more revenue out of the customers that are signing up to our app or attracting new customers. We really don't care. Go get it, kid. So in your backlog, it could say. Do whatever you can to get 20 percent more revenue. Hopefully you have better goals I'm giving you a business goal. I want you to achieve this business goal. Right? 20 percent more, you I think about, like evil business goals, like Facebook, I want that time in session. Increased by 20%. Right. I'm giving you a solid business outcome. So where you're diverging from the real world and how the real world works is that you're already giving me a concrete goal. You're giving me a metric category and you're giving me like a target., So product goals, I mean, this is one of the things that I talk to product owners and product managers about is like, what are your, your product goals? Your product goal is not feature X unless feature X serves some larger purpose, right? So like when I've done things in the past Yes. Have I worked on individual features or a set of features? Like, absolutely. But there was a goal. We wanted something from all of these features, whether it be like higher customer satisfaction, more, more longer session time, like whatever it was, but you can only focus on like kind of one, I'm just going to say this, you should probably really only focus on like one metric at a time. Absolutely. Like if, if, if I'm, again, If I'm, if I'm a co CEO here at Brian Ohms software development company, and I come to you and I say, I want whatever, whatever I'm saying today, like I want 20 percent more user engagement on the content we're providing through our application or whatever. Now I've given you the single metric. So basically clear your backlog, right? One Epic. 20 percent more, whatever. And you stay on that until I come to you again and say Mike, thanks for coming to this session again. We see that you, I gave you I gave you the goal of 20 percent more whatever what, 20 percent more engagement you got us up to 17 percent more engagement. I'm happy with I'm happy and Om who couldn't be bothered to come to this. I was on my yacht, come on. He was busy sailing on his yacht. But 70 percent is good enough. We're going to take you off this and we want more new signups. Now, now we want 5 percent new signups in the next quarter. And that's what we want you to hit. So basically you're closing the work that you did previously on the, on the business and you're coming up with a new strategy. And this is where I feel, I feel a lot of people. If I'm calling out anybody, I'll call out product managers because this is my, this is my line of work is even if, even if like I'm coming to you with a super clean directive. Mm-Hmm. in this completely made up example. Your real leadership will come to you with very murky. Yeah. Real fuzzy, diluted. And if you're in a small company and you're the only product manager, it's up to you to distill what they're, what they have given you, what leadership has given you into an actual strategy and put that into your backlog. So your teams can be running on a strategy well, so, I mean, for me I, I get I get an upset stomach when people start talking about strategy, so, and, and the reason being is that a lot of people don't understand strategy. Like, for me, my take on it strategy is the answer to the first how. It's like, oh no we're, we're, we're going to war with Canada. How are we going to win this? Our, our, our Air Force is better than theirs, so let's use our Air Force. So that's the strategy. Use the Air Force. Well, use the Air Force to do what? Okay, well, we're gonna take out their infrastructure. I'm not advocating going to war with Canada in any way, shape, form, or fashion. That would be wrong, buddy. I love all six of the Canadians that I've met. They're great people. So, but Strategy is the answer to the first how, how are we going to do this? And so for me, like when it comes to product, like there are a limited number of strategies. People want to approach strategy, like it's Bigfoot, right? They're gonna go put cameras on trees and I have a big camp out and they're going to wait for however long. No, they, so what is like, what is your value prop? Are you high quality? Like, are you a premium product? Are you a commodity? Right. So those are, those are like pricing strategies. Like, are you customer centric and centered around customer service that you, whatever. Whatever industry business that you're in, you want your customer, you want to be known for your customer service. Right. That's a strategy. You know, do you want to be known for, so going back to quality, do you want to be known for durability? Like, our cars last forever. Like, our, our equipment lasts forever. Like, this is the best set of wrenches you can buy. You'll never buy another set of wrenches as long as you live. There are a limited number of strategies. And people, a lot of product people approach strategy Like, they have to pick one, and they have to pick the right one from an unlimited number of strategies. And I don't feel that it's that way. There are very few strategies, and then they're, they're, they're tweaked a little bit based on your context. But they always run back to those same ones. Like are you a luxury premium product? Are you the, the lowest cost product commodity? Yeah. Are you you know, like are you customer service oriented? Are you I don't, I don't know. I have a list somewhere. I keep it written down, like there, there's, so I don't have to remember it. But there's a limited number of strategies that you could be chasing. Which one are you chasing? And then, now it gets more detailed when you've picked a strategy and you said, how am I going to implement this? Like that's when, that's when the possibilities start to open up is how am I going to implement this strategy? But I think in a lot of places, especially large enterprises, where I've spent an inordinate amount of time, for some reason I must like it, The disconnect between the, the C suite or the executive committee and everybody else is a gulf. It's a, it's a, it's a canyon. It's a, it's the Grand Canyon. You can't hear what they're saying over there. We don't, what do they want? More. Better. Yeah. Faster. But the goal that you said we want to increase time of session by 20%. That's doable. I can chase that all day long. And it's focused. It's limited. Right? It's, it's not open ended. And a lot of people's backlogs, I think, are filled with Things that, ah, some stakeholders think are opportunities. It's filled with maybe a set of baseline features that they think they have to have or they can't compete. But you need to categorize all of that. Like, one of my favorite ways of prioritizing things is by doing a story map. Like that walking skeleton. Like, so a customer is going to engage with this feature. Well, what are they going to get out of it? And then they're going to engage with this feature. Well, why are they going to move from this feature to that feature? What are they getting out of it? What is the progression? If you want people to use the features in your product, like you have to sit down and you pretend that you're them. Or engage with them. Engage with them? Yeah. Do your customer empathy map. Do, do your customer journey mapping. Do your story mapping. If you can get your stakeholders to sign off on your features. feature map and your feature map is, is robust. So it's, it's the core of your product. It's not optimizing the product. That's like, it's the core of the product. If you can get them to sign off on that, you don't have prioritization issues. It doesn't have to have everything under the sun in it to start with. Because you're going to be engaging with them throughout, right? And it will change. It will change shape as you go forward, undoubtedly. Mm hmm. And you build out your core feature set, and then you have multiple releases Mm hmm. through that core feature set to build them out. Now the argument comes, well, do we put this in release one or put this in release two? Right. That's when you start having your conversations about capacity and the value of not a, not a full sized feature, but maybe of individual stories do we want this in release one or two or three, that's when you start, and it's much easier to have those conversations than it is to have conversations about the core of your product. And then if your bets are small enough and, and the target is clear enough. Like, I'll do that all day long. Yeah, you can pivot if you needed to. And if you waste something, it's not that big anyway. Yeah. That's why the bets have to be limited. The goals have to be limited. So that you can safely make those bets. So that you can say, you know what? We're not getting anywhere with this. You can afford to lose those bets. We're going to stop this one. We're going to go somewhere else. That's the responsiveness that agility promises that a lot of people are just missing out on. But you have to have, you have to have data for that. You have to have customer behavior data, right? You have to have that analytic stuff. You have to have Product telemetry. You have to know how it's behaving. You have to know how they're behaving inside of it. That information has to be made available to your product owner, your product manager, the whole team needs to see it. Yeah, so the whole team isn't done when they finish the story and get it done or deploy the feature into production. There's so much more left after that, and that's something that you don't really see teams do very well at. We covered this on the previous podcast. Mm-Hmm., where we talked about customer satisfaction and customer validation. Very few teams have like they have a done column that says like, Oh, we're like, we're done, and it got sent out to production and whatever., I want a post done column that says we validated that the feature that we released, that went out to production that people can use, it actually met. The, it actually met and satisfied the business need that we started and, and worked on the feature for, and I can again, I can think of like maybe one team in my whole career who was advanced, quote, advanced enough to, to realize that their job does not start Stop at done, like the done column on the board, they need to demo it and talk to the customer about, does this, do you think this really solves the problem? So this is a result of your agile. Project management tools being focused more on this development process. Done means development's done. Now, right, you build it, you run it, right? That's the mentality for Agile teams, Agile product teams. If you build it, you run it, you operate it. Now, most companies don't leave time for teams now to go back and look and look. At the features that they've created, that they've released, and see what kind of impact that they're having. They move on to fresh new things to build the next feature. Yeah, exactly. Well, those are developers. They don't, those are developers. They don't have businesses. They're craftsmen, not developers. Have you let 'em, have you ever let 'em try? That's right. Exactly. I was at a company one time where The a sales opportunity fell through the pipeline. And they said, if we only had this one extra functionality, I can actually tell you exactly what the function, I'm not going to, because it might single out the company, but if we had this one extra functionality, this, this company would have signed the contract and we would have , X dollars of revenue if only, and I'm like is that true or is it, or did they just not. Or did they just didn't want to sign the contract and they were giving you whatever answer. I don't, you, you people don't talk about like their value proposition enough. And like there's a, there's a new a newer method for capturing product vision, which is called like the vision narrative. And that feels an awful lot like a bunch of essay writing to me. I tend, I tend to go for like the shorter. Pithier kind of methods first, but what is your value proposition? Like what is the value that your, your, your product is offering to customers. Now your value proposition doesn't have to be a part of your, your, your public facing you know, company vision or company mission. It could be depending on how it's stated, but. You need to understand the value that you're offering companies. Like, if, if, if you're a shipping company and you have a bunch of boats and no planes and no trucks, then your value proposition inherently involves moving goods across water with boats. Right. And if you want to expand into air, freight, and land, ground transportation, then that's something that you could choose to do. But if the assets that you have currently are cargo boats, then that's where your business model lies, that's where your value proposition lies. And most entrepreneurs, they have gut feelings about Market opportunities sure, but you have to take that gut feeling and you have to put it down into like very clear words Yeah, you really have to define it of like what is it that you're you're going to do? So so uber eats so uber. Mm hmm, right you use the internet to call a stranger and get in their car Have them take you somewhere. Don't take candy from Uber went into Uber Eats. So now they're using those same people that are driving around looking for passengers. Now the passenger is food. They bought Drizzly and let Drizzly operate. And now they're shutting Drizzly down. And they're just, now you can just buy your booze through Uber Eats. And so they've, they started out with an on premise. They expanded that. Food delivery. Now they've expanded it again into alcohol delivery. But at each Step, right? There was a limited focus on the one thing that they were transporting. Which is probably why they were successful. You try and do all things to everyone. Well, but, so, the reason why Drizzly became a thing that Uber was gonna buy was because nobody else was moving booze around like Uber was moving people around. And so, that, that was a market opportunity. So that was their value proposition. We'll bring you alcohol just like Uber Eats will bring you food, or just like DoorDash will bring you food, we'll bring you alcohol. And then so, instead of running two different companies, I guess Amazon or, I'm sorry, Uber decided that they were going to fold it into their mainline operations. But, they were focused on one thing at a time. Get that right, move on to the next thing. let's go into the last item on our list. today, which is that a PO should know the technical side, at least conceptually, which also I'm going to blend this one just for the purposes of time with my company would never hire a scrum master who's never worked on a software development team before. You know, I was made a development manager. Early on, like in my IT career. Boy, that was a mistake. I'm going to say it didn't end well, but it actually did, because it ended with my movement into product management. But, your developers and your scrum master and your product owner should have a good enough relationship that they're If the scrum master doesn't know something, they should be free to ask. And the team should be free to respond. And I, I agree that, that scrum masters and product owners both, even if you don't know the technical stuff conceptually, behind the, the digital product, you should learn it. On the job, until you can hold that conceptual model like in your head. And it doesn't have to be, you're not, nobody's asking you to write codes and, and put semicolons in the right place or Get your indentation right. That's not just saying that this system the customer initiates a request by doing X with Y system. And then that data flows from here to there via whatever API, and then it's transformed, you should just be able to have a basic conceptualization of the components. Of your product, of your customer experience. And just kind of what's going on. Like, you don't need to be able to go in and administrate it. You don't need to be able to go in and, and, and repair it. Like, that's not your job. That's the development team's job. Like, the developers do that. But you should at least understand how it works. So that you can draw me like a little lightweight diagram on a whiteboard. And I can under, I can understand by what you're saying. How the whole thing works, I agree with that. I think your scrum masters, your product owners could definitely collaborate with the architects or the tech leads or even developers and just say, tell me in layman terms, what is this whole thing about? Right? And if a diagram like that doesn't exist, feel free to create one, even if it's rudimentary and wrong, people will tell you exist. Well, you may go into a team and you don't know about it, right? You ask and they all know in their heads what's going on. The diagrams that do exist are highly technical architectural diagrams, which you don't also understand. That's fine. I'm not suggesting you go down that level or DFDs or whatever, right? Just get a blank piece of paper and say, Where's the start of all of this? Start with other questions like who are we doing this for? Why are we doing this? Work with your product organization to understand not just the what but the why behind it. Then relay it to the team if they don't know it. They may know it, they may not know it. But yeah, start with something. Just do some doodles and say what moves from here to here. And ask just questions and build up that something, right? You may not get it right, you probably won't, but that's okay, you can refine it. And you, you, you have to know enough to be able to have meaningful conversations. Right. And I guess that's where's the limit? That's my point, is being able to have a meaningful conversation. And the impact of change in the train somewhere of these boxes, right? What is the impact of us, our team doing something at this level versus this level? Just high level. You know, we have a complex subcomponent in the middle here that's, that's doing something transforming data, which it's a third party application that we, we leased from somebody else. We're going to, business is going to end that contract. Oops. How is that now going to affect our product? Oh, they want us to build build our own. Well, how long is that going to take? Ah, 10 years. Yeah, typically that's how it goes. But no, that's a great example, right? That's what I mean by impact high level impact. The typical agilist. So we'll have a prepared response that says, I'm not technical. Does it, does a scrum master have to be technical slash come from a technical background and, and the typical even on this podcast, we'll say, well, they don't necessarily need, but I mean, they should be informed they should generally know. However, there are organizations out there that are like, I'm not gonna hire somebody who doesn't I'm not gonna hire somebody who hasn't been a developer. To sit with and coach development teams, this is not going to happen. Well, I don't think the scrum masters focus is on engineering excellence. And I've never thought that like for me, going back to earlier, the trifecta is like product engineering and team performance, but I'm not going to say team performance. I'm going to say Organization, like how the team is organizing itself, how the business is organizing itself, right? We still, we still run into a lot of instances where we have product owners or product managers that are leading a vertical, a business vertical, but they're not the boss of anyone or, or the boss of anything. And the bosses of Of someones and somethings, we'll tell them that quickly. And in that kind of an organization, like there's a, there is a tension between people that have budgetary control over people. And. You've the product people who are leading by influence, but are still being held responsible for some kind of a business vertical. And so going back to this issue of like, how technical should I be? Like enough to have the conversation with whom, who are you talking to? Is it a member of your team, a developer? Is it the scrum master? Is it a stakeholder? Is it a vendor? You have to be able to have the conversation. If you can't have the conversation, then go practice the conversation. Yeah, I think it's just, what level, to your point, right? So if you can hold a conversation in plain English. About the context of your solution that you're building. That's probably good enough. If someone questions you deeper than that, then you can go get help from your teammates, right? Bring in the lead engineer, does a product owner or a product manager need to know the maturity level of the team or how well the team is performing? It's not their focus. Should they know it? Yeah. That's like just information on the side. I mean it's when I'm driving my car I don't necessarily, I don't need to know the wind speed outside. Like, unless I'm in a hurricane or something. Like, I don't need to, that's not I need to know my speed I need to know if there are dangerous weather conditions. I don't need to know the exact wind speed. Or the, or the revolution of your tire. Yeah, how many times the tire's going around. Like, there's some information. That is it possible to go get this information? Yes. Does somebody use this information? Absolutely. As do I, as the driver, need to know this information? No. Yeah, that's right. And your dashboard should be tell all right to your example. If the, is the car overheating? Well, you have a dashboard indicator for that, right? It gives me the information that I need to make the decisions that I need to make to keep myself and my family safe, other people safe. Like, and that's the automotive industry, they've had, I'm going to say a hundred years, over a hundred years to kind of get this stuff right? And that's not a whole lot of time when you compare that to You know, how long have people been building things to live in that weren't caves? Like, we've spent a lot more time doing that. But in a hundred years we've got my, my dashboard's pretty slick. And I, and I have options on it, like the one that I have, it tells me how fast I'm going and it tells me who's around me. That's what I, that's what I keep mine on. Now my wife Has the exact same cars. We're cute, right? We both got the same cars. Mine's white, hers is black. You are cute. Very cute. She keeps hers on a different setting because she wants different information, but it's still relevant information. It's a set of relevant information. I don't need all of it all at once. But it's there and people do have how to get it if you need it. That's what I'm saying. If you need lots of lower level details who to go to for that on your team. Yeah. But I don't know the technical I don't know where, like the, the LIDAR devices are on my car. I don't know how that stuff works. I don't, I just know that it tells me if somebody is around me. Well, here at Brian and Om's software development company, we don't know where anything is. And that's the way we like it. Exactly. And in today's podcast, you heard that we make virile software. So there you go. It was something, yeah. All right. Anyway. So hopefully this has been useful for the 10 of you that are still with us at this point in time. Let us know if there's other topics that you're interested in, and don't forget to subscribe and like