AA151 - Hardware & Software Products and Teams: Agile in Manufacturing

0:00

If I explained to, , the listeners how crazy . our software system is and why it's so difficult for legacy car companies to get software right. You'd be I'll do it very quickly. So to save probably 500 a vehicle, We farmed out all the modules that control the vehicles to our suppliers because we could bid them against each other. So Bosch would do the body control module, someone else would do the seat control module, and we'd have about 150 of these modules and semiconductors all through the car. The problem is the software are all written by, you know, 150 different companies and they don't talk to each other. And so even though it says Ford on the front, I actually have to go to Bosch to get permission to change their seat control software. Right. So even if I had a high speed modem in the vehicle and, and I had the ability to write their software, it's actually their IP and I have 150, we call it the loose confederation of software providers, 150 completely different software programming languages, you know, all the structure of the software is different. And we can't even understand it all. So, you know, that's why at Ford, we've decided in the second generation product to completely in source electrical architecture. And to do that, you need to write all the software yourself, but just remember car companies haven't written software like this ever. So we're literally writing how the vehicle operates, for the first time ever. podcast, Clint is here to talk about, Agile in manufacturing and to talk about the manufacturing side of having software and hardware together in the process. I played this clip from the CEO of Ford, about something that's completely gotten out of hand. It's a great topic. I don't see a whole lot of podcasts out there tackling this topic. Essentially we're talking about making. Things that you can feel in touch, right? Physical products in manufacturing. So then, let's kick off. Can Agile legitimately be used in manufacturing? I mean, like all this stuff came from manufacturing exactly. I'm glad you said that. So we've gone full circle, really , it's about delivering value to the customer, right? And making sure that they're Involved in that process And that you don't run down too many rabbit holes of, waste and effort And everything else And a lot of people, a lot of organizations Get caught up in that And Agile being applied To those environments Can remove Some of those issues especially We started looking at post COVID we, everybody, the whole supply chain essentially broke in a matter of months. And then the recovery after everything started back up still took even more time. So trying to deal with everything in a manufacturing environment after that, when you're not the you're not Facebook, you can't go to a company and say, I need 5, 000 of these now. Well, if you're a smaller company and you go there and you say, I need 500 of these now, and they're like, Facebook just called they need a lot more and , we're gonna go with them. Yeah. Right. You're on a wait list. Yeah. You know, you have to be able to react to that. And then every, every facet of the organization has to be able to react to that. So your procurement team has to be able to turn and find a new supplier. Right. And even if they can't find a new supplier, you find another manufacturer of that product and hopefully your engineering team can turn too fast enough and your software development team can turn too fast enough to be able to push that through. And then on the product, product management side of that, you need the customer to be okay with. They have a hundred modules of your product and they all have this type of this type of And now we're going to change and they're going to have, they're going to have this type. Well, they want everything to match because when they walk through there, they want a nice, pretty, everything's exactly the same. And then stocking parts for maintenance after that, same thing. I don't want to have to stock two things. Right. A lot of people that deal with software, They just don't think about the hardware side of the equation and I've worked on development teams that where we had a hardware component. So I was at least exposed to it so I wanted to ask what do you think the biggest difference is? In manufacturing work with a, with a physical product as opposed to like purely software. Dependency. Is the biggest one. Because in software, right, you have your own developers, you can write your own code, you can develop your own product. In hardware, like in manufacturing, you're dependent on other organizations, other companies, possibly, to provide you parts to be able to build your product. And if that goes too far, you get Ford. Yeah, I agree with that. I think in software development a lot of times dependencies are internal to the organization. Right. You're waiting on a team or something, right? With hardware, as you said, dependencies are external to the corporation, right? The organization. So then you get into this This game of like, is there somebody else who's also looking for the same thing you're looking for from your supplier, as you were saying earlier? And is that, does that supplier have enough raw materials to build that, that stuff that you're looking for? Or are they also waiting on their suppliers? So you get that whole domino effect, which is what we saw during the pandemic too. But yeah, dependency is a huge issue with with hardware. My experience has been with Vendors that are providing a component, a hardware component. And the company, the assembler, I guess, is putting all of these together. And that includes hardware and software, right? And the biggest issues were really around just time to deliver, meeting those dependencies. Yeah, I mean, those are the logistical issues, but underneath that, getting people to talk the same language and understand the principles of being agile whether it's software or hardware, for me, it was harder to get all of those guys in hardware to come to the table and understand that we're trying to do this so that we can be more nimble. We can be more flexible. We can be adaptable. All of those things that. I guess it is now collectively called Principles of Agile in Manufacturing. Let's sit on dependencies for a second. Because the normal agilist out there will say, well, you got to drive out dependencies. You got to, you know mitigate, mitigate them. Yeah. Basically work them out of your organization. So, so your team can do everything and they don't have dependencies anymore. This is a great example. That people might not be thinking of, about times where it's just not possible. It's not possible for you to go to go buy and set up and maintain all the equipment necessary for you to produce all the hardware side of your product when you have a product that's hardware software. So you have to partner with people. And then when you partner with people there's a whole other side of it of like, how, how are you a big fish in a small pond or a small fish in a big pond? Because how vested are your partners, right? Yeah. There's a lot in the Deming literature about this topic right here about bringing your vendors into the ecosystem. Or if you're this small fish in a big pond, you joining their ecosystem to being like a good neighbor to say like, Hey, you're making these parts for this other person. And maybe we can just. Piggyback on what you're doing over here, but it requires your, your hardware vendor in that case to be a little open be a little a little I don't know how to say a little more transparent about what they're doing, you know what I mean? Rather than trying to extract maximum, like the, like the, like the Ford CEO was saying oh, we, we're going to bid all these vendors against each other and make them fight with knives, with butter knives you're not gonna get the best quality. That's how you get the lowest cost. That's exactly right. Yeah, that's how you get the cutting corners for the lowest cost. Yeah, I mean, if you take a look at the longer kind of time horizon, yeah, you're going to say 500 bucks per vehicle, and that's a significant amount of money look at the number of cars they're shipping, right? That's not insignificant. However, if the quality is so poor, and you have to service that under warranty, even one, One single incident is going to wipe away that savings of 500 bucks. So to me, it sounds like short term thinking. Yeah. Sorry. I'm running a query. How many, how many vehicles does Ford sell in a year? And it says 2023 Ford. So the media. ford. com. So this is Ford. Reporting this. 0. 23 sales totaled 1. 995 million vehicles. Let's call it two for what it's worth, right? Two million vehicles and they're saving 500 per vehicle. That is not a Insignificant amount of money they're saving, right? And that's a year on year year on year. Yeah. Yeah. So I think just just to kind of peel back what you're saying, if you, unless you're going to set up all the equipment to make everything needed yourself, let's say you have very deep pockets and you could do that. How do you then fulfill the, the knowledge gap? You need people that that have the skill sets to do all of that work, which you don't have, right? Even if you had the money to tool up, you don't have the, Expertise. So that possibility is just basically a non start, right? You have the partner. We're talking about dependency management. If we bring this up at like a random community event, it's like, what are you doing for dependency management? I guarantee you, if we bring this topic up at our networking event that's here in town that somebody will immediately come back with like, will work dependencies out of your system. Yep, buy more Red Yarn. Right, and then the elaboration on that will be, well what if you cannot? Because my hardware and software are different components. So you will never work. dependency management out of your system. So, how much horsepower do you put into dependency management? This is not an easy topic to solve. This is a question for Clint. How much time in your experience do people put into dependency management? Knowing that this stuff could sink you. So, we had the downside of starting from essentially ground zero. Because we had already had significant problems, no visibility, like So, high complexity, obviously with so many dependencies, right? So we went with, we went with Scrum straight off. Because we want to improve quickly. Scrum's gonna get you there, because as soon as you hit a problem, it's gonna light up like a Christmas tree. We had that, and it looked like Every warning light on your dashboard coming on at once. And Terrain! Terrain! Realistically, you would want the business unit responsible for the, for the dependency to start ironing out their process. It's not always what happens. And then that holds up a lot of other things, but you know where the problem's at. So at least you, at least you have that visibility there. And you can start working a little bit out of the system, dependency is not going to be gone, but you can optimize the process. And then that's the, that's the lean route there, is going through the process, ironing it out. So you just have to be honest with yourself about what the problems are and where they're at and humble enough to say, okay, we, we just got to fix this. So they'll, they'll never go away completely, but you have to, you have to be honest with yourself and dedicate that time because much like Ford, if you just keep pushing it off, it's going to cost you later. You're going to pay it now or you're going to pay it later, but it's going to be paid. I think the big difference between now and later is later it comes laden with rep damage. That reputation damage is worth a whole lot more than just simply the dollars that you're losing. Right. The other problem with later is like, now that you're in this nosedive that you can't pull out of now you have other problems. It's like when you there's a leak in my roof, I'm just not going to do anything about it. Like, now you've got mold and you've got walls that need to be torn out and you've got potentially other construction issues or problems in your foundation. Like, later, now it's compounding with other things that could have been avoided if you had just not made a bad decision in the first place. Like, I'm just going to ignore the roof leak. Yeah, I was going to use the terrain example, but it's probably a morose one. That mountain's coming at you fast. But look, the dependencies in a complex situation, you don't just have several, you have many, many, many dependencies. Just take Ford as an example, right? They have so many suppliers. So, you can't always Smooth out dependencies for everything. So then what do you do? Right. Right. Which I think, I guess if that question had an easy answer, he would have done it already. So what I heard is, typically, again, in the context of Ford, their history has been making cars, not writing software, as he was saying. And they started to write software internally. Well, this is the first time ever they're writing software. We can all kind of imagine how that's going to go, initially at least, right? There's going to be a learning curve. Until they get better, good enough. Let's just put it that way. During that time, you still have to ride this, this idea of being dependent or having dependencies. And what do you do? You know, where I'm going with all this is, my experience has been just getting the agile mindset. And, and getting people to talk about what we're trying to do here. That was a big challenge for me. Granted you're a 200 plus supplier so that was a big, big challenge but I don't know man, the CEO of Ford, I mean he even said that it's crazy. I mean that that's like really straightforward language for a CEO to use. And it, it makes it Seemed to me that they made a purely financial decision of how can we save? You know like pitting suppliers against each other basically. How can we save the maximum amount of money? Regardless of anything else in consideration. Whereas, if you came at it from the opposite perspective, we're going to take full control of the software for all of our vehicles. And not I mean, you can think of the same thing, the same thing for component parts. We're going to produce all the component parts. Oh my goodness. You're going to produce all the component parts? That's going to be an immense In terms of machine set up and labor that you have to hire and all all that kind of stuff. Like, Oh, you're going to do it all onshore, offshore Mexico, China, wherever you, wherever you're going to do it. That CEO would have to deal with a slew of financial concerns to go down that road. And the metrics to measure the number of tickets that come back in after a product is out in the field, the, how long our vehicles last, that kind of stuff. I don't know what kind of metrics they're using to measure themselves. If they're purely using the metric of profit year over year, then he made the right decision. The customer satisfaction doesn't matter, the amount that their vehicles maintain themselves or whatever, you know what I mean, like without breaking from their servicing or whatever, like doesn't matter, none of that matters. He made the right decision because the only metric they use to judge themselves is how much money did you make. Yeah, profit per unit. That's, that would be a problem. That's one of those rabbit holes that a lot of places are falling into right now. Because, yes, revenue keeps the business running. At the end of the day, that's what you're there for, right? Sure. But the immediate The, the immediate revenue versus things that are hard to measure beforehand, measure without hindsight, like your reputation impact and the, the sales impact of that reputation damage that you could be running into. Just don't get taken into consideration. It's all about the immediate profit. So then you do things like. You push a product out that's not fully developed. Sure, you get the customer to agree to it, but then you're going to pay that cost later. So, from the hardware side, if you push something through that wasn't fully tested when it left, or you pushed it through with Without parts that you didn't have, so you had to use used stuff to like figure it out, and you just shove that tool out the door. Sure, you're getting money for that, but then how much is it costing you to send somebody out there to fix it later? How long they have to stay there, the parts you have to do, the reputation damage of, We got this and it's broken day one. I should be able to plug this into a production line and go, those not immediately tangible things seem to be given. Low regard and consideration in comparison to, oh, this is revenue now. Right. Well, I mean, another one of these ones that you'll deal with, with hardware. That you don't deal with purely software is the, the up front cost, the high, the higher up front cost when you have hardware as part of your you know, total package basically. Total package is not a great way to explain that. There's a better term than total package. Yeah, you're right. I mean, you have to have raw materials to build something, right? Yeah, so you gotta buy those. And then you get into this whole nightmare of logistics and availability. You have equipment and setup costs and maintenance costs and stuff. In software, you just don't have any of that. You don't have any of that at all. I mean, like we talk about all the time on this podcast, we talk about MVP. Like what MVP is actually supposed to be and like examples that we give on a typical on a normal podcast will be Oh, just throw some Figma mock ups out there and send them to the customer and be like, do you like mock up A or mock up B? And then you, and then that, that's your quote MVP. I call that the, the optician's metrics, right? You like A better or you like B? That's exactly right. That's exactly right. Yeah. You can't do that with hardware. Right. Right. Right. Well, it's, I can't fathom how you'd do that with hardware. Send two things out or multiple that's just very cost prohibitive. Well, it's, you can't do it mid mid development like you can with, with other things. I mean, you can. But, ideally, right, that's done beforehand. That's your, your R& D and your testing there and then you announce new product. But, you're right, the upfront cost of that is significant. I think, I think other than the cost, it's this whole idea of Yeah. Work with your customer way before you even have a product. And I don't know if that's necessarily generally true in hardware. In hardware, mostly it's the, the units on sale that's, and you as a prospective customer can go find that, right, nobody consulted you ahead of time I, I think that's a big issue because it causes this idea of we're making it for them, what and there's a life cycle and if they don't like it, they can buy version two, right? And that's kind of not nice. I mean, it's, it's not nice, but people with version one of the hardware didn't necessarily get upgrades for free. They had to buy their upgrades which, which some users, depending on their kind of, their, their worldview they, they kind of viewed that as you know, not they were stiff. Yeah. They, yeah. They kind of viewed that as like they were kind of, but, but on the other hand, like you're getting version one, like you're getting the latest adopter, you're getting version, somebody out there has a version one of the iPhone or the iPad or whatever. And it it doesn't get it doesn't get iOS upgrades anymore. You know what I mean? It's end of life, basically. And it's, it's barely usable for anything in the modern world. But back in the day, it was really awesome, and they were willing to pay for that. Yeah, the early adopter cost, basically, is what we're saying, right? Yeah. Yeah, and I think that's, that's reasonable, right? If you really want to get on the bandwagon fast, you're gonna get what you're gonna get. But those customers, I think, pay a higher premium for version 1. Subsequent versions of the product, presumably, will be cheaper. Because you get economies of scale, right, as you're going through this. Presumably. Well, you have to, you have to take into consideration those situations. And those are some of the good, some of the times where it might be good that your sales team is out running your development. Like, they're going to sell a product that you haven't made yet. But you have to be agile in your development process to be able to keep up with that. Because when you offer a customer something and you say, yeah, we can do this. And if you're honest with them about we can develop that versus, yeah, we've got that. Hey, we have that. It should work out okay. Because yeah, you have them fronting that, that costs a little bit. But you have to be able to turn too fast enough where you don't lose it. Yeah, I think what's kind of flowing parallel to that is this is this current of competitiveness you've got to your competitors too. So those salespeople need to stay fast enough where you don't lose market share to the competitors, but at the same time, they've got to make sure that you can actually have delivery. Otherwise you have this situation, like in the automotive industry, you can sign up, pay your deposit for a future model that doesn't happen for a while. Gets delayed and delayed. That's not uncommon. Well, in a, if you have a, if you have a manufacturing work organization, that's started to adopt agile, you, you have your cross functional teams and no matter how you divide them by product line or anything else stage, that air of transparency has got to be there, right? So the sales team can make a sale on something that we haven't developed yet. That backlog somewhere. But they have to as soon as possible turn that over right? Hey, I I have a customer they're interested in this and then you Start doing the risk on that and see what the what the whole market looks like and if you can throw that together fast enough You're gonna easily outrun your competition here but that that honesty and transparency has got to be there throughout the whole organization that you're not gonna silo up anywhere or somebody's not gonna withhold their their best effort on things because they have something that they're more interested in doing. And then you have a whole team behind that salesman. So you can't just have that guy running out there on his own. You've got to have that whole team behind them and you've got to have that team alignment of we're going to beat everyone. Transparency and collaboration throughout is what I'm hearing. I have a, another person I work with that called the, they used to call these people undisciplined sales, but you can't have undisciplined sales. If you're selling something that is, doesn't appear on our roadmap and doesn't line up with any of our business objectives. Like now the salesperson is the issue because we, like we have a roadmap. We have a, we've, we have features that we're developing and in this case devices that we're developing, they're. In line with our roadmap that the business is set and we've all set together and you've got a salesperson basically out there doing whatever they can do to make a sale because they have different incentives and all that kind of stuff. Like that's undisciplined sales. I want to take that off the table for a second because like that should be easy to point out to be like, you know what you sold this feature, but I don't think, I don't think that's the funny thing is that the product management, like the. Point in my career that I'm at now in product management, like I will a million, billion percent point that out to the salesperson. Because like you can get, if you want to get a feature factory PM in here to just build whatever you say, like. Cool. Like, I hope you're bringing in enough new business, and I hope the churn rate is low on your new business. Because if you're bringing in new business, but the churn is 100%, so basically you bring in new business, and then they sign up with a yearly contract, and then the next year, 0 percent of them renew, we need to talk about that as a business. Like the whole business needs to talk about that. It's like, why are we selling customers that really, like they get sold on our stuff. But after a year, they'll they're, they're like when we really didn't use this we really don't care about this product. That's a big problem. Huge problem. Yeah, we talked about on the podcast that you don't stop it done when you deliver, right? You have to measure after that, how it's landing with the customers, are they using it, etc. So I think this is wrapped up in that too. You got to figure out, is their experience worthwhile such that they would invest money in your product again. I like, I like, I like where you're going. When you have a product that's hardware and software combined, like the end to end user experience is even more important at this point. Even in the Marty Cagan four risks. They're like, Oh, the, the can't usability. Can a user figure out how to use it? When it's a software plus hardware product, it's not like times two, it's to the nth degree. It is, it's exponential. Yeah, right, yeah. Yeah, it's, it's very difficult to get your mind around getting a customer in to test. It's not at the end, but you know, throughout the journey. Yeah. Both the software and the hardware. And do it in a way that, as you were saying transparent. Bring the customer into your org, so they become part of the org almost, right? Such that they, they start owning some of this stuff. Like they start feeling ownership of the hardware that's being shown to them, of the software that's being shown to them. The earlier you do this in the cycle, the better it is, because you can pivot faster. And you're getting feedback from the actual customer. But all of that said, this, that all sounds like common sense almost, but It's very difficult to do this when the hardware development effort is on a different schedule than the software development effort. And then you have integration challenges, right? At what point do you show something to someone? What is the functionality that, is there mechanical functionality as well as the software functionality, right? So I think this is where you know. We could consider things like, well, you said MVP, but I'm thinking about just simply versioning the product and showing a carcass initially with very little software, if any, and building up from there. To the final product evolving it really with the customer at your side and not bringing them in periodically just to show them what you've got because that's not really an experience. That's a snapshot in time, right? And oftentimes I'm old enough to know what we used to do this at trade shows. Where things would break or they'd simply out there and somebody behind the scenes will throw up a screen on your, on your monitor or your projector. Ignore the man behind the curtain. That's not transparent. That's not, that's not what I'm talking about. I'm talking about having the customer in throughout the journey. The other benefit of doing that is your solution will be aligned to their needs much better because they've been with you the whole time. Well, you also have the challenge too in In more of a startup environment that that's how you can, you can work that if you're an existing organization, that's got say 50 years under your belt, already a large install base of your machines of various iterations and versions, right? The lack of I don't want to say discipline, but I can't think of another word. The lack of discipline in your product management becomes super apparent yes, you need to approve, like you want to support the customer and what they're doing, but if the customer is running a 30 year old version of your product and you're like, Hey we can't get a lot of those pieces anymore, but you know, if we were to do this in this, would you be interested? And then reaching out to the install base as a whole, gathering that information from your customer and developing that. You like this tool, it ran for this long. What can we do to make that better? What would make this easier for you? So that we can get you another one that'll run another 25 years. And like you said, bringing the customer in on that and, and asking them and bringing them into your, your product management, crucial. It's the only way to move forward. And if you want to pick up and be exponential growth over five years. You're not going to do it by telling the customer yes to absolutely everything you've got you have to say no But what can we do to you know, make that better? I wanna pivot us into a category that a lot of people don't think about in software development., but inventory management is interesting when you have a hardware and a software component to your product because When you have a harder component, you have to manage inventory. So we, we, we want to sell, like if we're creating a hardware and software product that we're putting on shelves, or that we're shipping out to people that use our software. Around the country there's a forecast of how many people will buy it because if we have people that want to buy it and then we can't we can't produce things for another I don't know what the lead time would be like two weeks, three weeks whatever it takes to send a ship across the sea, literally a ship across the sea. That's our lead time. It's like, oh, we're all out of the, the, the, the things I was talking about that they plug into the truck and they tell you like when you're driving and when you're not, if we're talking about that and we're completely out of them, oh, I have a carrier that comes on. Oh, we want to buy ELD devices from Brian and Om's software company. We have a thousand trucks, we need a thousand devices, and Brenham Software Company says well, we only have like, a hundred on the shelf. Yeah, yeah, and our ship can't get through the Red Sea. And our ship can't get through the Red Sea for another three weeks, or whatever now we're kind of like, oh well like, AR/AP, like we can't, claim any of that money. Until a certain amount of time and like, the closer you get to the end of the year, the more hectic it becomes, you know what I mean? Because we want to write that money on this year's budget. That's right. Anyway, the point is, in normal software development, you don't deal with inventory management. No, that's very true. So, I'm super interested, like Clint, if you have any experience in dealing with inventory management, well, it ends up being like a significant problem, especially when you're forecasting like you. You might have a sale that comes in and it's a significant amount of orders and then something happens with that customer. Oh, no, we we can't do this right now. We're in a reduction of force. We had a bad quarter. So we're we're gonna cancel these orders. Great. I got three million dollars worth of inventory in the warehouse now or you know, then you look at obsolescence too. Anytime something changes or a supplier of yours for something you don't make. This is obsolete now. Okay, good. You design a replacement. We still have inventory currently. And then when you design the replacement, are you designing to eat up the cabling and everything else that supported that device? Or are you switching to something else? Then what do you do with that inventory? Ends up being a big problem. Cause you could you're that customer, like I said, cancels and you end up with three to 5 million in. Slow moving inventory in the warehouse and that's just money that's sitting there. It's not going anywhere. Then you can't pay your suppliers. Then nothing coming in that you need. You can't use the stuff that you have. What do you do? I would imagine the easy way out of that is, you just don't put in the order on the hardware side until you've until the AR has shown up. You know, until you receive the money for the devices you know, for whatever you're producing for the parts, basically. Presumably you're taking something from the customer to begin with instead of pay later right at the end. Yeah. So that should help a little bit. If you have other customers that use the same, consume the same things, there's a little outlet there you can start selling. Yeah. I've seen strategies like You know, tell the customer, Hey, look we're going to reduce the price substantially to make it viable for you to buy this, even though you're going through bad times. And then the worst case scenario is we're not going to let that stuff sit on the shelf for more than X number of days. We're just going to throw it away. We'll, we'll, we'll write it off. Right. I've seen that too. Yeah. Yeah. Companies do that too. They write it off, which isn't seen very isn't seen much in software development companies writing off. Inventory. Yeah. Yeah, that's true.' cause you don't really have physical cost, right? No. Yeah. For, for, I mean, you don't have physical storage. That's, you know. Yeah. It's, it's accruing cost. All of this also relies on a steady stream of information that not a lot of manufacturing companies have right now. Right Ford and major automakers and things will have that. They'll be able to tell you down to the screw. Like what their consumption is a lot of the smaller companies won't, won't have that necessarily. And then if you don't have that information, you can't see how are you supposed to be? You're just locked in a room in the dark and hoping you don't hit a table. So getting the infrastructure and just recognizing that there's a problem instead of moseying through delusion. Of, oh, we'll make it. We'll make it. We're gonna make it. We always make it. You're happy to speak. Yeah. Recognizing that there's a problem, trying to bring visibility to it, and pushing a concentrated effort towards, let's resolve this, rather than smacking feet trying to get everybody to go and you recognize that there's a problem and you move on it quickly, so you can get your sales team out and This is the, these are the components we can make, these are the products we can make, this is how many go. And then you usher your sales team out into the world and hopefully they're good enough to sell at least a portion of it. And then that eliminates part of the problem. Or you spin up an eBay store and start selling parts that way if you need to. Well that's another strategy is to sell en masse, right, at a reduced cost. If you're really smart about how you're designing your product, presumably you've got modular components that can be reused in different models or different products. That, that's the best, I guess the nearest to salvaging this situation, right? It's not a total waste, you can still use it in something else. It's also, again, being able to see what things are actually costing you. If all you have is It costs me, I sell it for this much and the components are this much, and you're not, you don't have full visibility of, this is how much it, it takes to build this tool from purchasing the components to assembly, this is how much it costs me to assembly, this is how much it costs me in testing, this is how much it costs me to QA, and you have that full visibility, because then you can turn out the individual components and start calling people, hey do you want a couple of these sitting on your shelf in case, You go down, it can keep it up. And then again, in the, in the information, have an information ready. You, you should be able to see what problems, and if you're communicating with your customers properly, like you would be in an agile organization. What problems have you had? Can we, can we sell you a few things so that we can get a tech there and instantly throw this, this component on, bring your line back up. And then we'll replace it after where you get that components that mailed back so we could do a failure analysis on it and figure out what's going on. It's all part of a fully, fully integrated agile organization that moves as one instead of your legs fighting your hand. I have an example I can share around that. A company that makes CAT scan machines. They actually have, a lot, a lot of times, they actually have their reps embedded in large research hospitals or other health institutions like that. And the reason is they can see first hand what the problems are. So if you're selling a CAT scan machine and the machine is capable of doing all of these different types of scans. Lo and behold, there comes a, an opportunity one day when they're trying to do a scan that your machine doesn't have the capability to do. Right. So what do you do in that case? Well, most of this stuff is not necessarily changes to the hardware. It's mainly the software and how, how you move in what intensity of radiation. Right. So if you could sense the need That is not currently met by your product. You can go back to base, back to your company and say, this is what we need, right? And there are experts that get involved, and they can quickly give you the software that does the scan that's needed. And that person is on site, can install it, or it can be installed remotely, and whoever the health professional that needs it can have that scan quickly. That, that's an example of how you shorten this by, we talk about bringing the customer into your organization. What they've done is they've gone into the customer's environment to see first hand. Which is easier to do in software than hardware, but still possible. If you can't bring the customer into your organization, because there might be various reasons why you don't want to be fully transparent, right? And that's okay, in some instances. Um, be the customer. Like you said, go to them, see what they're doing, ask what their issues are. What are you trying to do? What can you tell me about where you guys are trying to go? Oh, we have this for that. See what they're missing and move towards that. Because then you're developing for something that's there instead of something that you perceive to be there maybe sometime down the road eventually. Well, exactly. So you're not developing something in the vain hope that someone's going to need that one day, right? Or they may need it one day. You're actually fulfilling a real need that you validate. And then it's not just in manufacturing too. It's not just trying to get organizations to understand this too, is the customers aren't only outside the company. You've inside too. Yeah. Right. So every section of that team, every section of that organization has to work together and be brought in on what the others are doing. All right. That's how you get transparency. That's how you build trust. Like you want to make sure that everybody's acting and everybody else's self interest and that's the only way you're going to move forward quickly So you want to you want to know what your customer needs so in manufacturing, right? It's it's easy to hire people in off the street that don't know anything about what you do really But they have the qualifications on paper and they sound like they know but eventually that person needs to go and and do what's being done to know what what's going on because they're That's a customer aspect. So you still have if you're an engineer and you're putting a tool you're designing pieces to a tool, but you don't go build the tool. Right. What could, okay, great. I can, well, you could build this tool eventually, but if you, if you get called out to the, to a manufacturing floor and the tech is like, how do I put this together? Well, what do you mean? Well, if I put this piece on first, I can't get to this screw. And if I put this piece on first, I can't put this piece on. How am I supposed to do this? Oh, just, it'll fit. Don't worry about it. That's the way it's always been. We've always managed to do that. Great. It's going to take me two days to get this fully together. Whereas you can make a couple of changes. It's not going to cost us any more or, or very minimal. And then we save probably six, eight hours on me putting this thing together. That's, that's more in line. That's where you're starting to get into one fluid motion in an agile organization. Yeah, I think you've touched on the integration challenges, right? Within different modules. I mean, you've got those in hardware, as you illustrated. You've also got those with the overall machine that's using hardware, but it's also using software. Right? And the challenges are The software, I think we mentioned this earlier, the software team is on a different cadence and the hardware team is on a different cadence. So at what point do you bring that together and what is that core functionality? And then, if you've got customer in, you've got to show them that, right? At the same time you're doing that, hardware people are already building stuff. Ahead. Software people are writing ahead. So, how do you do this? That's the delicate challenge we have. I don't see that as, it's not like an existential problem. It's just your hardware people and your software people are on a different cadence. Just like if you had multiple software teams on different cadences. Well, what I'm saying is, yeah, so in the software world, multiple teams can collaborate in that way. It's their, all the teams are building software at that point. You've got hardware teams, you've got software teams. Mm hmm. And they have different considerations. So for them to work together towards, you know the delivery of a given stage of the product. Yeah. That requires a lot of close collaboration. Yeah. And. Also requires an understanding, or at least an appreciation of The other side, right? So people that are building software need to understand some of, some of the stuff that's happening here in the hardware side and vice versa. I'm just not sure if if that's prevalent out there. That's a, it's a, it's another thing that goes back to when you're looking at taking your organization to agile, what scale do you want to do that cross functionality? Because. It's really easy to say, Oh, engineering team is going to be this way. They're going to use kanban, right? Planning team is going to be used kanban. Manufacturing is going to use scrub and we're going to do this, this and this. Or have your team all the way through. It's like, are you going to horizontally slice or are you going to vertical, right? Do you want to be able to deliver one product line really well? Or do you want to be able to be You know, fully cross functional and be able to manufacture everything, but everything kind of goes through its, its individual filters when you're maximizing dependencies at that point. So if you get that, if you get that cross functionality built into your organization, those, those the conversations that you need to have you develop a solution, that fits your business and the structure of your product. The structure where you're trying to go, your customer, those all need to be looked at and you need to adapt instead of trying to shove yourself into a box. And if you have that cross functionality, then it goes with that understanding too. And I seen that when, when trying to do it in our organization was. Sometimes they just don't care. You don't think as the person of, you've had so many problems with trying to get your job done because this guy is doing things that only matter to him and then you try to align and your priorities don't line up. They, they don't care about something that your hair is on fire for and you don't care about something that their hair is on fire for. But if you both just took the time to put each other's hair out, like , nobody's on fire at that point. fire the guy that's setting fire to the hair, that, that's what leads to the integration challenges that I was talking about. Right Home. Never has to worry about it. Oh, I never have a bad hair day. Never. He beat us. He reduced his dependencies. I did. I am totally ready to pivot us into the category that I'm super excited to talk about the whole time, which is quality. Oh boy. Which is QA and QC. QA and QC, both. Yeah. The issue with quality with regard to software is already hard enough and now we're introducing hardware into the mix. I can only imagine this plagues literally everybody. Quality. Yeah, you're only gonna miss it if it's not there. No, absolutely, look. As you said, it's hard enough with software, right? And it's hard enough with just hardware also. So when you combine them, it's not the it's not times two. I think it's much worse. We were blessed with really having a software team that was really on top of it. They could turn really quickly, but we had like, I think I've told you guys earlier, like we had a senior developer, leading senior developers who were all capable of. Fixing their own problems on their platform and then collaborating with each other if they intersected so they they had that discipline that collaboration Everything was everything was good the hardware side. Oh boy the way we were planning to manage quality because it goes with that definition of done right and What do you want to be? You want to be able to deliver something that'll function on its own. And in manufacturing, that could be as small as one component. It could be as large as a whole system. But, when you cut it down to size, this one component has to be able to go, go to the customer and do what it needs to do, and you don't want it to have a long setup time, and you don't want it to break, and you want to make sure everything's good. So your testing, before at least, has to be solid. And, anything that happens in the field that's weird, or one off, or anything like that needs to be recorded and investigated but it's clearly defining, and having the whole team agree upon, this is what done means. This is And you have to stick to it. You can't, well, revenue is going to be down a little bit this month. We're going to, we're going to deal with quality later. You have to, you have to be disciplined enough to take the hit for the quality because you're not going to sacrifice your represent, your reputation. And it's that, that piece of transparency. You know, there's, there's not many customers out there that'll be. Truly, truly upset if you're like, Hey, take an extra week. I want to make sure this is fully tested before it gets to you guys. So it's that we had that component was able to be tested and function on its own. So that say, if I had a lid, well, I want, I want to make sure that lid is. You know, sealed up properly. I want to make sure that it's gonna do what it needs to do when you put it on. So you're gonna do all those tests before it leaves, and when it gets there, yeah, there's a little setup, maybe you gotta level it. When you put it on there, it's gonna be done, and it's gonna function. Because you want the same thing if that lid is used for a whole module. When it rolls into test, you don't want to take, you want to find those issues, yes, if there's any. And then report those back and have that feedback. To the build team of, hey, pay more attention to this. Okay, got it. And the, never had any problems with people being difficult on, on the feedback. Hey, we had, I ran into this problem in test. It added a lot of extra time. Do this differently next time. Pay attention to this. And then you're developing your people too. So you, you always need that going. That, that feedback and letting them know what's going on and you want to make sure that that testing is done before it leaves and gets to the customer and that's, you have to be disciplined in that. I feel like in hardware, You have better requirements in terms of what it needs to do, whatever the widget is or part of a widget. Do you have a lot of NFRs in hardware? I don't know. Just putting it out there? I have no idea. But in software you do, right? The thing's got to scale. In hardware it's got to perform for for its design fitness purpose. As soon as you put Hardware and software together, I think the challenges become magnified. Just because you've got other people involved, you've also got these integration challenges throughout. I mean, I, I think that's, that's the thing coming out of this whole podcast is like as soon as you put hardware and software together. Like you magnify all of your problems it does. Yeah, I mean, I agree, first of all, and then if it's not your software someone else's software that you're putting into your product, is there a partner? We go back to the Ford situation, right? And that's one, I mean, you've got dozens of these suppliers. So it's so difficult to integrate something like that together to the point where it all functions all the time for every use case. So in the end, it may come down to this. You accept good enough. Om's dealing out hard pills to swallow on the podcast today. I can, I that's a hard pill to swallow,, it's good enough because we can't get out all these vendor relationships, and we're trying to save 500 a car, and this is really the only way eugh. The hardware and software together yet. It'll it'll amplify all those problems that you normally have just on the software side Like like Brian said, but the solutions are kind of the same you need your process optimization you need to clearly define all all the KPIs that you're gonna look at for success or failure , you still want the customer feedback, but every aspect of the customer is you need to recognize where value comes from and then make sure that what is value is defined. As long as you start laying the good foundation and you work towards a solid one, even if you're not on solid footing right away, as long as you're moving forward, you're going to make exponential improvement. You just have to stay with, it's going to be painful. It's going to hurt, but that's that radical candor that everybody talks about, right? You got to be able to accept that so that you can get better and move on. And if you want to take a company from 25 million to 500 million in five years, that's, you're not going to do it by holding on to old ways. You have to put big boy pants on and You got to do what nobody else is doing a lot of manufacturing companies all turn towards TPS and Six Sigma and lean and they Try to cram themselves into that box. Well, you're you're not gonna beat Toyota by trying to be Toyota, right? You're gonna beat Toyota by doing things that work for you and you can't follow it to the grave GE was a prime example, right? They were the Six Sigma poster child for a while, and it, they followed it into the grave. And, I don't know if they're still recovering from that, but, you can't beat that drum enough. You can lay the foundation, you can get that mindset in there, you can build the agile mindset on top of that, where you're valuing your people more. But, I literally had somebody tell me like, Oh, Lean is the foundation for Agile, and I was like, Right, but you and I, you being Six Sigma, and me being Agile, we have different considerations entirely. If you're going to do an improvement, where's your focus? Well, process over people. Okay, this is, this is why we're never going to agree. Because mine is people over process. So you have to be radical in what you're doing. You have to be committed to it. You have to clearly define everything so everybody knows what's going on. And then, you can't, if something's not working, change it. I agree with that. Ruthlessly pivot. There's there's no point dwelling on Fixing bad practices. Just get rid of them. Yeah. So that, that's it. Right? That's, that's, that's a, that's the podcast. That's the podcast. It's a wrap. If you liked it, don't forget to like, and subscribe and let us know other topics that you want us to talk about