#577 – Product Lifecycle Management with Michael Corr

Michael: This is The Amp Hour Podcast. Release February 13th, 2022. Episode 577. Product Lifecycle Maintenance with Michael Kaur. Welcome to the Amp Hour. I'm Chris Gammell of Contextual Electronics. Hi, I'm Michael Kaur, founder and CEO of Duro. Hey, Michael. How are you? Good. How are you? Yeah, great. I'm excited to talk about Duro. I think you and I met in San Francisco. You were working for a drone company then, I think.

Michael: That's right. Yeah. And I think coincidentally, your remote office was in the same building as ours.

Michael: Oh, yeah. That's right. Yeah. Yeah. So that's right. Yeah. Like on Bryant, 3rd and Bryant, that's where the supply frame office was. So much. Yeah, exactly.

Michael: Yeah, I was working for an industrial drone company at the time. Yeah. Leading their hardware engineering team.

Michael: Yep. Drones, huh? Are drones still a thing? I was just watching. There was a Wendover video about drones and like how specifically, I think it was like how Amazon Air is just like, we don't talk about that anymore.

Michael: You know? Drones, I think, went through a proper life cycle where there was a huge, huge boon of interest in them because it was new technology and it was cool. A lot of cultural pushback. I think. I actually think, and I can speak from my own personal experience, drones are, it's incredibly easy to get one built to fly. It's incredibly hard to get volumes of drones to fly consistently. Yeah. There's just a lot of variables in designing manufacturing drones. And so I think that also pushed away a lot of people from entering the market.

Speaker ?: Yeah.

Michael: Well, that's a good lead in because so now you run Duro, which is a product PLM site. We've mentioned PLM on the show before, but can you give us a quick rundown of what PLM is and why someone might want to use it in the first place? Maybe in the context of a drone manufacturer?

Michael: Sure. Well, so the PLM product life cycle management is a product category that's been around for actually quite a while. In essence, the core components of PLM is managing your bill materials and CAD files, a location for revision control, part number generation, and distribution content to various team members and suppliers. Yeah.

Michael: I think of change orders. When I think PLM, I'm like, oh, ECOs and yeah, stuff like that.

Michael: Yeah, exactly. Yeah, no, PLM, the core of it really is revision control and that's done through change orders. It's an opportunity for someone to submit their changes, have it reviewed by some peer committee and then approved or rejected to be pulled into the main production design.

Michael: As another anecdote, I remember actually before PLM, before actual digital PLM systems at my first co-op, they did everything on paper. And I remember, I forget her name, but one of the admins who was there, she was just in charge of just pounding the pavement and there was every engineer who was a lead engineer had to go and sign every one of these change orders and they'd have a stack at their inbox. And it was her job just to be like, sit down with them and just get them to review it. That's all it was. And she would just shuttle the things forward. And that was such a thankless job, but literally the company would have fallen apart without her. She was so important.

Michael: I know that role. I've worked with those people and they actually still exist, even though PLM and other data management tools are now digital. There's still a lot of antiquated policies and roles that are in the hardware industry. And that's actually one of the main things that Dura was tackling.

Michael: Okay. Interesting. So like, do they DM you and like, they're just like, you got to sign this. Like, yeah. Cause I'd imagine change orders sit in people's inboxes now instead of their paper inboxes. Yeah.

Michael: Well, so, I mean, so change orders, change orders, actually, it's a, it's an important topic. It's actually something that we've studied quite a bit at Dura. So change orders, the essence of change orders, as I said earlier, is that someone, whatever the motivation was, create a change, it needs to be reviewed. And as you clearly just highlighted, it's in the hardware industry, they're notoriously complicated and bureaucratic and lengthy process. And it really doesn't need to be. And so one of the things that Dura did was we looked at other analogies and one of them is from the software industry. They have something that's near equivalent called a pull request or a PR. Same thing. A software engineer makes a change. It needs to be submitted for some type of review process and approved before it can be merged into the respective branch. Yet software PRs can be submitted, reviewed and approved within minutes to hours. But engineering change orders are notoriously, you know, hours, days, if not weeks to get through. And there really doesn't need to be. It's really at this point because of these legacy policies that were designed when these data models or these processes weren't as prevalent as they are today. And so those are some of the things that we've changed. Like those methods where you had to rely on a person, whether it was a paper trail or a digital trail, but going to everybody's desk and saying, please review and approve this change order. Those days don't need to be here anymore. Like the technology exists.

Michael: Yeah. Literally, they can't be sometimes because now you're shipping. You'd be shipping envelopes across the country. Everybody working at home, whatever.

Michael: Fair enough. Yeah, exactly. And that's, you know, COVID or no COVID. You know, the industry has evolved where hardware companies are now made up more and more of outside suppliers and services. They're not doing all of the design engineering in-house anymore. And so it's even harder, exactly, to have that responsibility to manually prod every person to review and approve the change order.

Michael: If I could, if I could go back down memory lane a little bit more, another thing that was problematic, one of the reasons there was these paper packets of like things that went through is it's like, okay, so now we're going to go and change. So fancy resistor is, you know, obsoleted for whatever reason. Okay, fine. We know what that is. Now what we need to include is old data sheet, new data sheet, marked up schematic, like directions to the various stakeholders, manufacturing, how the reflow profile might change and all these different things. And like, that's in the packet. And so like, that is, that's a lot of, that's a lot to sit down to. I wouldn't want to do that. I wouldn't want to open up that packet and be like, oh, freaking resisting.

Michael: Well, that's it. So that actually is another reason that contributes to why change doors takes so long. To approve is because it's very overwhelming and it's a lot of work. And so someone who's been designated as an approver kind of procrastinates. So like, there's too much work here for me to do. I've got my other responsibilities that I got to get done today. I'll go to, I'll look at the change order later, later becomes later, just constantly procrastinates. And so that's, again, that's an antiquated process. There are technologies now that help automate a lot of that reviewing. And a lot of those comparisons so that when an approver comes in to look at their change order, it's very clear what has changed, what the impact is going to be. And so that they have that summary of information rolled up ready for them to review and approve in a more efficient manner. And that's where the hardware industry needs to get to. There's just too many manual processes and responsibilities in the migration and dissemination of hardware data.

Michael: Yeah. Yeah. One thing that, I mean, so I really liked the pull request comparison and we've had other people on, I think Kyle from Allspice is trying to do that kind of thing. But Upverter, they've talked about this sort of thing. I feel like just the general like software coming into the hardware world as a like paradigm. I love it. I think it's, there's a lot of good stuff there. One of the potential pitfalls I see is to use a pull request as an example is like there might be a change, but the hierarchy of a software, like inheritance, all that stuff. And like the API level of things, there's kind of a delineation where it feels like in hardware, there might not be as much. So if I'm now changing this resistor that's in the feedback section of the current measure unit in this widget that I'm making, I might have to see, well, it actually is, it's also near this other stuff in my design because of the space constraints. It just feels like there's potentially more context that is needed. Maybe that's a false equivalency, but it feels like there's less atomic changes that can be reviewed.

Michael: No, I'm with you on that. And the difference is, is I think what you're alluding to is the functional impact. Yes. And so, you know, how can, how can a reviewer functionally confirm that the resistor change is working as expected? And so you're right. I mean, software has the luxury of easier access and implementation of automated tools and test frameworks. Yeah. Yeah.

Michael: I was going to say, it's not a luxury so much as they put, I mean, they put a lot of work into it. It's, it's, it's very well designed in, in, in certain ways.

Michael: And I agreed, you know, it's not a one-to-one comparison. You know, some of those technologies just aren't there yet in the hardware industry. You do need to have more simulations and automations in, you know, validating circuits or, you know, FVA or for mechanical assemblies, what have you. But the point is, is, is there are bits and pieces that do allow you to do that. And those are getting cheaper and easier and more powerful over time. So they can become a commodity just as much as like an automated test framework is for software. And then further have the APIs and connectivity to automatically pull in those test results into a change order. Right. So, so those that are familiar with, with, you know, a pull request, you know, I'm sure they're all the same, but like GitHub does a very nice job of quickly identifying exactly what's changed in the codes, you know, you know, visual indicators, you know, color coded exactly what's changed. If you have a test framework, it automatically will pull in the resulting test builds. And so you can confirm that all the tests are passing and then the other, you know, analysis or tools that you might want to plug in. But the point is, is that they're there and you can have it automatically consolidated into a single PR review place for an approver to review efficiently and quickly. And that's where the hardware industry needs to get to.

Michael: Yeah. Yeah. So how did, I mean, one of the things I think about is like, you have a small change. So again, if we're, we were just talking about a resistor change in the hardware space, but let's talk about a, I don't know, an input variable to a function that the changes and we need, we were able to test all that stuff, whatever, but it is just that one singular change in the actual code is maybe it's going from you went eight to you at eight 32. And that's, you know, there, there are lots of downstream effects from that, but it's just that one change that is in the code. How do you view that same? Now, if we switch back to the resistor example, how do you view that change when there are tools that are binaries and equivalent, you know, maybe it's an FPGA or maybe it's a old CAD program that's very binary focused.

Michael: Yeah. Well, actually you just hit on one of my Achilles heels, one of my major gripes about the hardware industry. Oh, okay.

Michael: Well, you're not alone.

Michael: You're not alone. Well, so here's how I, here's how I see that problem, right? So I'm going to keep pulling examples from the software industry because that is exactly what Doro is doing is we're trying to pull in what has become best practice for agile workflows and software development and bring those into the hardware industry. And so one of the things of why, you know, Git was so, so effective was because it made it so easy to see what's changed and allow software developers to collaborate very quickly and see who did what, when, and how that impacted things. But that also was made possible because the source code is text files, ASCII. It doesn't matter what language you're programming it in is it's always going to go back to a text file, which is an open source technology. And anybody can build tools to process that information. And that is what helped proliferate the whole agile movement and GitHub specifically is because it made it so the transparency was there and anybody can contribute or had an idea of how to further process that information and provide value. They could with very little impediment. The hardware industry, as you noted, our source files, so to speak, are CAD and they're binary and they're very large and they're proprietary. And so there's friction. There's some exceptions, but the majority of them are, right? Yeah.

Michael: I would say actually, you know, so obviously I'm a big, you know, I'm going to, you couldn't hear, I was on mute, but I pulled my soapbox out. I'm sure listeners are used to this sort of thing. And, you know, KiCad has ASCII-based files. But I think even at the end of the day, if you see that like resistor one move, you know, say you just have to do a layout change and like now you have XY coordinates of where it changed, that alone as a review item is not that useful because again, you don't have the context of what's around it. You know, what actually is impacted, how that might change reflow profiles and all that other stuff that we talked about previously.

Michael: Agreed. But, well, let me get back to the other point though. So sure. KiCad is an example that it is text-based. You think it's XML, but the majority of, of CAD softwares are not. And that has been a major impediment to other people building more tools that help engineers or help managers, what have you. Right. So yeah.

Michael: Very closed ecosystem generally, I think. Right.

Michael: It's just the CAD providers for all intents and purposes, intentionally or not, they have a monopoly on their files. And we are at the mercy of their own innovation to provide more value for processing those values. Whereas the software industry wasn't. It was technically open source and anybody who had an idea or the capabilities can contribute to that community to empower it. Right. The rising tide raises all ships. The hardware community needs to encourage CAD companies to open up their CAD files, making them more accessible, provide either zero cost or low cost standards, which they can then process the data so that other people can take it and innovate. Right. I think there's, there's a lot of restrictions that are holding back the hardware industry from actually just, just healthy innovation. And those restrictions need to be taken away.

Michael: I've actually never considered that as like a, like, oh yeah, they could charge for that. Like totally. Like, but it's still, if it was like, if there was a translation key or whatever, like. Something.

Michael: Right. I mean, you know, with all due respect to the value that a lot of these CAD companies have provided, like they're not the end all be all for innovation. You know, they, they should open up to large community who have other ideas or have other contexts of how they want to process and use their files. Hear, hear. I'm on, I'm on board, man. And I just think that's, that's a, that's a chip that needs to fall soon to kind of unleash some of these restrictions that the hardware industry has from reaching some higher levels of innovation that I think it needs to.

Michael: So this isn't the only thing you guys, so like we're talking about the, the, the CAD piece and how that plays into like change orders and things like that. But that's not the only stuff because then as people may have heard bubblegum tap shoes for those playing along at home, that's our code word when we're about to talk about part shortages. There are part shortages. You know, it's just like a trigger warning around here. Uh, there are part shortages that people have been dealing with over and over again. And that's another piece that Duro obviously plays into because there's all of this kind of side loaded data. You know, if you just look at a bomb, you also need to have that as a control document, or you need to have some way to control on the resistor change from part A to part B. And you need to indicate that to your, your teams.

Michael: Yes. Yeah. So supply chain information, regardless of the recent, you know, world events that has increased shortages and lead times has always been opaque to the engineers. It's often handled by a separate team. It's often handled, you know, downstream or weeks or months later after the engineer makes the initial design decisions. You know, engineers will often leverage, you know, commercial off the shelf distributors just for initial part selection or references. But it's the common model is some other team certainly wants to probably get into some volume. We'll go to other sources for purchasing. Yeah. The problem is, is not only because it's a separate team, but often because it's, you know, weeks, potentially months later from when the engineer made that design decision. When there is an issue with a supply chain, the parts not available, doesn't hit the company's requirements, you know, AVL lists or price or lead time requirements, what have you. There's a lag and a procurement person often doesn't have the information required to, on their own, pick an alternative. They have to go back to the engineer and say, can you, can we use this part or can you switch this part? Can you test this part? And that creates a huge inefficiency in the whole workflow from design to manufacturing, because now the engineer has to stop what they're doing. There's a context switch, you know, who knows if they remember how or why they picked the initial part. Or maybe they have to run some tests. And so it's a basic inefficiency into that whole workflow. And so Dura's philosophy is let's empower the engineers with as much information as possible so that when they make the initial design decisions and part selection decision up front, well, of course, some of this data may change, but they have access to even more information than they would today to make better decisions that hopefully won't have to go through those iterations. And so there's a lot of really interesting things that are happening in the supply chain industry where more and more part suppliers or service suppliers are digitizing their catalog and services that are now making this possible. And so granted that information wasn't even technically available as easily to an engineer not that long ago. I mean, you could flip through a catalog. But like, you know what I'm saying? How about paper? Offshore suppliers, right? Or, you know, of course, you have, you know, every engineer, they use, you know, the household name, certainly in the US. You know, DigiKey, McMaster, you know, Arrow, Future, Avnet, you name it. But there are many, many other suppliers out there that they just don't have access to and probably would be the ones that are used for final volume production. And so some of the things that Dura is doing is, you know, one of our fundamental philosophies is there should be complete transparency across all teams and all data. And so by leveraging this increasing number of suppliers who are now digitizing their catalog and services and making APIs available, we do that. And so now engineers, when they're making those initial design decisions and part selections, have access to not only many more suppliers and part information, but real time did. And so if they see that the lead time or the prices don't meet their requirements, they can immediately take action and make, choose a different part or set different criteria in the initial design, right? Versus waiting weeks, months later to find out. Look, I'm a double lead. I can tell you how many times I had to re-spin a PCB because the part I had selected is no longer available. And, you know, even a functional equivalent didn't come in the same package. And so I had to re-spin a whole, you know, PCB board just to be compatible with what was available in the supply chain. And that, that impacts the bottom line to get for a hardware company to get their product out to market, both the cost and the time associated with it. And had I had more visibility into part shortages, I could have picked another part much sooner in that cycle.

Chris Gammell: Yeah.

Michael: I think about the downstream effects right now too, of just like, I mean, I've been talking to people on the consulting forum and just, you know, friends and it's just 20, 20 spins for a board, you know, just like doing whatever you have to do to get, to keep production running. Like, I get it. Like that, that sucks. But like the long-term like scarring effect of that, like that, the maintenance of that and like, depending on, you know, say you're just switching out the memory that's on board and you have all of these different memories you have to keep now in your firmware and track in your firmware, you get 20, 20 versions that you're pound defining, you know, like your, your pound including rather based on this sort of thing. It's just, it's terrible. It's just the, the maintenance cost. It's not just the immediate cost of parts going up. It's also the long-term maintenance costs that are significant.

Michael: Yes. I mean, this, look, you know, it's, it's not that long ago that it was acceptable for a hardware product to go from design to production in 20 months. Right. And, you know, I don't do it any other way, Michael. I think I'm older than you, but, but like that's no longer acceptable. And, you know, while there have been incredible improvements in tech, you know, technologies, manufacturing technologies help reduce those timelines. A lot of that 20 months is just the human time it takes to do a lot of this data management. Yeah. Yeah. Looking up parts, you know, spinning these, you know, spinning boards because of, you know, in response to supply chain issues, not because of functional issues, migrating the data from one team to the next, you know, through email and Excel.

Michael: How many, how many walls you have to throw it over and throw the design over and then they get thrown back.

Michael: Or just, yeah. Or you're blocked because you don't have visibility into what someone else is using. Again, the, the digital CAD, you know, the binary CAD file issue, not everybody has a CAD license. And so they can't see what other team members are working on. And so they're blocked. You know, like a lot of these things that are contributing to these long lead times designing, manufacturing hardware are not because of the inherent capabilities of, of manufacturing or designing engineering. It's just the overhead it takes to manage the project.

Michael: Yeah. Yeah. Another thing that, that I, I'm kind of mixing together my different experiences now. When I was at Keeflee, the, they had in-house manufacturing and the thing that I loved about that. I mean, there's a lot of things I loved about it. There's some things that I didn't love, but the purchasing group. Literally was just like on the other side of the floor and you just went and talked to them and, you know, you designed in a maximum part and John came and yelled at you and he said, don't do that. You're going to get screwed. We always get screwed. You know, like that sort of thing. Apologies. You know what? Maxim's gone. They're good riddance. They're now ADI. And, and like just that, that kind of back and forth was like a shorter cycle. Yes. Another thing was the visibility into, you know, the true cost of a part. There was like a data management piece of that as well. Right. Where it's like, okay, you're going to design a part in, you might see it for a dollar on digi key, but when you actually look at the cost and we're going to buy, you know, however many reels and we have all these relationships with the TIs and the arrows of the world. And actually we're gonna get that thing for 25 cents. And you should work that into your bomb. And like getting that pulled forward in your design cycle, that is super valuable because now I'm not telling my boss that like, oh, this board is actually going to cost $500. It's actually going to cost $300. And that means I might be able to add another feature that a customer really wants. And it enables other things that are, because you have more visibility, you know, you're kind of peering into the future.

Michael: Yeah. Well, there's a lot of things, really interesting things you said in that last bit. One of my own, for my own personal career. So I started my career actually in R&D. I got a master's degree in EE and then I worked for SRI International in Menlo Park, which was a fantastic place for me to start my career and just had access to so many amazing technologies and projects.

Michael: What is SRI for the?

Michael: It's Stanford Research Institute. So it's kind of the government and industry research arm of Stanford University. And so, but we were known to really, as a company that solved tough problems, but really just did prototyping. You know, we weren't really known for a company that brought things to mass production. And so that's kind of how I learned to design. Like I learned to design products based on functional requirements. And while cost was important, it wasn't as much of a driving function. And when I left SRI and I started, you know, I joined a buddy's clean tech startup company and I was responsible for the hardware design and manufacturing of our products. And that's when I really started to learn about volume manufacturing. And one of the most important ahas I had was, you know, when you're dealing with productions in hundreds of thousands or millions of units, every penny you save on the parts you select is another engineer you can hire. Right. Right. So if you think about like, if you're, if you're producing a million units and you can save 10 cents on your bill of materials, while 10 cents doesn't seem like worth the time it took you to find that part or make the design change, that's a hundred thousand dollars you just saved. Yep. Totally. And that's another engineer. That's another person that can help you move faster or do another responsibility. And so that's a very, very important part of designing early into your, your system is how do you reduce those costs because, and how do you repurpose those costs that you just saved, you know, to provide better value for your company?

Michael: Yeah. I, this is, I, this is, this is the primary reason that I, I say hardware engineers are cheapskates. It's just like this reinforcing effect of like all the things that you can do if you learn how to, you know, find that unknown supplier and take a chance on them, or you put two resistors in the place of one because it, you know, like you're costing down total number of placements on a machine sort of thing. It's just, the mentality is, is pervasive.

Michael: But there's, there's one thing that I also want to highlight where there is other costs associated with reducing your bomb that I think people don't really recognize both on, you know, the engineering, the OEM team, as well as on the supply chain. So, recently, you know, this came up at our company where, you know, we have some of this, you know, I talked about earlier how more and more parts suppliers are starting to digitize their catalogs and making them accessible through APIs. And so that itself not only gives engineers or the users access to more information to make better decisions, but it greatly reduces the time it takes for them to get that information. And so one of our customers was asking for us to do an integration with a supplier that they use. And I said, well, they don't currently have an API, but you know, we'll monitor it for you. And they said, well, you know, I said, but their, their parts are the cheapest. You know, you should definitely still use them and just manually enter them into your bill materials. And they said, well, just because they're the cheapest in the catalog, they're not the cheapest landed. Because if it takes me 10 minutes to go to their catalog manually, copy that information, put it into my bill materials, the actual landed cost to purchase that part went up. Interesting. And that was incredibly powerful soundbite for me, because that is now empowering me to go out to that supplier and say, Hey guys, I got customers who really love your parts and your products that you provide, but you're putting friction in the process for them to get it. And while you might have the best parts or the cheapest price, you know, people take the path of least resistance. And your competitor has an API that shaves the time it takes to get that same information from tens of minutes to tens of milliseconds, because we have this API integration. And I think that's where suppliers need to catch on. It's like, Oh, like we're going to lose business just because of the convenience factor that our competitors have.

Michael: Yeah, that's a really good point. I definitely move that way too. I mean, like I, I think in a, a, an adjacent thing that I've been seeing in my own designs is like accessibility of like supporting libraries or supporting 3d CAD models. Like I know that, uh, like, like Keystone's one of the ones that like, you know, they, they're not like the cheapest stamped metal out there, but man, getting that, getting like a 3d model into a design is like a lot closer to a design win than someone where I have to go and model it myself or, you know, whatever there's lots of different examples like that.

Michael: Yeah. I mean, look, you know, time, time has become such a critical factor for hardware companies. Now it's not just getting the best product to market. It's getting the first product to market. Right. You know, the, the software, I'm going back to the software industry. So the software industry timescales is now minutes to hours to spin a revision of a software product. And, you know, look, you know, we all have smartphones now with, with apps and every morning you wake up and your phone's telling you, you have 15 updates that you have to update. Right. So this, the cycle that products can be updated, software products can be updated is incredibly short. And the community, larger community expects that now for everything. And it's, it's transcended into hardware products. And so there's even a market pressure for hardware companies to get their, their products to market faster and anything that impedes that is going to hurt them. And so again, it doesn't matter if you have the best parts or cheapest price, but if there's friction to getting your parts or services designed into a product, customers can go somewhere else.

Michael: Yeah. Yeah. That's, yeah, it's really interesting. How are people, so obviously people can sign up for Duro and try it out, but like, could you walk us through like what it might look like on a small team or even a larger team to like use Duro in a, in a daily context? Oh, absolutely. Like when, when are they logging in? What are they clicking on? What are the, you know, how does it interact with CAD? That sort of thing.

Michael: Yeah, sure. So, you know, Duro's process, you know, our whole philosophy is we want to make it easy. Right. Let me keep talking about this friction. There's, there's too many friction points in, in the hardware industry. And there's many companies who are tackling it from different angles and some, you know, are doing a great job and we love working with. And Duro has its own angle of how to, how to remove some of the friction. And by friction, I mean anything, again, that impedes progress or getting your products to market. And that includes just setting up your tools, right? The, the hardware industry has these legacy products for managing their design and manufacturing, everything from CAD to PDM, product data management, PLM, product lifecycle management, ERP, MES, inventory management, you name it. And they all, in essence, need to connect one way or another. But they were designed decades ago when, as I was saying earlier, it was acceptable for it to take a while to get a hardware product to market. And there was more development done in-house, less outsourcing. And so none of these tools were designed to work together out of the box. They're all quite capable and powerful and in their own right, but it takes a lot of effort to set them up, configure them and, and get them to work interoperably. And that's no longer acceptable, right? It's, it's quite common for a hardware company to take six or more months just to set up their tool chain before they can really start, you know, managing their data properly. And that's a fundamental problem. And so that's one of the things that Duro tackles is we have the first completely out of the box PLM solution for teams that just need something that works. Like we don't need high configurability. We don't have a very high customization requirement. We just need something to. Just get me bootstrapped up, right? Just get me something that like allows me to store my CAD files, my bill of materials, my supply chain information does proper revision control, automatic, you know, part numbering systems and, and communicate with my suppliers. And there's a lot of people out there that want that.

Michael: And I think on the consulting forum that I run, like we've, we've had this conversation before where it's like, what do you even do? Like, like, I'm not going to arena. I'm not going to go start an arena person, you know, thing. Like I've, I've had a friend who told me, he's like, you need an entire person. If you want to use it arena to like go and like have like a dedicated employee for that. You're not going to do it as an individual. So then like, I guess there's spreadsheets. That's, that's a common one.

Michael: That's it. That's, that's the alternative. And, and it's spreadsheets and spreadsheets because not because they're a better product, but again, they're lower friction.

Michael: Yeah. There's no costs. You know, it's like the lowest common denominator of a file format, right? It's like everybody can open them and okay, that's enough. Everybody can open them. Everybody has sufficient proficiency in how to use them. So we're, we're, we're extra, we're, we're cloud connected because we use Google docs instead.

Michael: Exactly. Right. And so that's one of the main things that Duro set out from the beginning to solve is how do we give, you know, it's an 80, 20, right? So there's 80% of the, of the customers just need something that works and early certainly just to get started. Right. They acknowledge that maybe they want it to be more configurable or complicated later on, but they don't want to be using spreadsheets. They don't want to be using windows file directory naming conventions to revision control because they know the risks, right? We've all done it. Oh yeah. We've all done it, but it's, it's, it's not because they don't know that there's better technology. It's because they know that other technology is just too complicated to use and too lengthy to onboard and set up.

Michael: Well, I, I'd like to put another pitch in for cheapskates again. Uh, I think there's, there's sometimes a cheapskate thing, but I think, you know, obviously you guys make a pitch for the, the cost, like the true cost is another thing that's in there.

Michael: Well, but again, like the spreadsheet solution has those hidden costs, right? So yes, immediately it seems faster, cheaper, and easier, but just, I mean, everybody, I guarantee you, every one of your listeners has a horror story where they're engaging with a supplier through email and exchanging itself files or CAD files back and forth and, you know, making revisions through email. And then the supplier picked the wrong attachment. Oh yeah. Right. Everybody has that horror story. And so those are the hidden costs of using email and windows directory structures and not using a proper PLM system because that's what the PLM is for is for engaging with your suppliers and making sure they have access to the right revisions that they're supposed to. And so that's one of the fundamental things that our product provides is that completely out of the box solution that has industry standards that, you know, every supplier understands and you can immediately upload your, your bill materials using some of our CAD plugins, integrate some of your CAD files and through proper engineering change orders, you know, release your, your suppliers within an hour. Right.

Michael: Yeah. I think, and if we could maybe attach like a, a hard example here, so like maybe we could like come up with a, you know, a fake widget and we're talking about a supplier here, but that involves both in and out. Right. So like a PCB manufacturer, there's a assembly house, there's the distributor, maybe a direct relationship with like a chip vendor. Like, so this would play with all of those. It sounds like, or it might, it might have ins and outs from, from each of those things.

Michael: Correct. Yeah. And, and, you know, over time we're adding more and more integrations. Right. And so we have a handful of integrations now with various CAD products, you know, SolidWorks, Onshape, working on Altium now and several other ECADs. We have integrations with all the major parts distributors. We even have integrations with some MES suppliers or functional, you know, management software tools allows you to really pull in all the necessary information to, you know, make those engineering decisions earlier or process your engineering files to get to production and, and everything's designed to be plug and play. And so there's very little configurations that are required, certainly for, you know, the vanilla happy path and customers love it, you know, and because they're not spending so much of their time every day, just managing their tools and data. They're actually working on engineering, which is what they're hired to do.

Michael: Okay. So, so I'm going to give an example here of like, uh, so we're working on a drone and we need like some lighting underneath. So there's just a standalone circuit board. It's got a connector. It's got four high power LEDs and then maybe like a driver on it. And that's all that's on there. You know, it's just a standalone board, but that's something that's in your larger system. And that's what the LEDs go obsolete. So now walk me through the life of an engineer freaking out because of that. We've all been there. Like Michael said.

Michael: Of course. Yeah. Yeah. No, of course. It's always the 11th hour, right? Because as an engineer, you wait 11th hour till you're about to hit prints. So you actually look up to the parts I pick actually, do they still exist? Yep. Yep. Yeah. Yeah. Well, so the various ways to tackle that, you know, so assuming that the parts are available through one of the distributors that we have integrations with, they can very easily find out that information. And in fact, we can even warn them ahead of time. So it's not an on-demand thing, but it can be, you know, interrupt driven where you can set these alerts like, Hey, let me know if any of these parts, you know, exceed these criteria, whether it's a price or stock or lead time. Yeah. And so you don't have to wait for someone to manually check, you know, are these parts still available? And so that alone helps reduce those, those timelines we're talking about.

Michael: So. I'm pretty sure I've asked DigiKey for that before. Yeah. I think they're, yeah. I want that. I want that from all distributors. I want to, I want to push notification.

Michael: Well, that's it. It's like, I think a lot of these distributors are starting to catch on, on the power of APIs and automation and how they can help their, their customers make better decisions. And again, it's, it's a friction point. The easier it is for, for consumers to access the data and process the data, the more likely they're going to use you as a supplier. And so anyway, so with Duro, you can be notified much sooner that this part's the obsolete or lead time is no longer acceptable. And so then through our integrations, you can find an alternate, pop it into your design and then through our, our CAD integration quickly release it back into Duro. It auto-populates change order. You add, you know, it sets it as a draft mode and you, you can add your approvers. You can pick from, you know, your team or outside suppliers. If you have a relationship with them like that, the Duro change order will automatically generate a visual diff of what's changed. So it's not relying on, you know, manual comments or, you know, how verbose the author wants to be that day. Once the change order is created, you know, Duro will pull in, you know, our existing tools or we have some partnerships that add value to the change order, including automatically comparing the revisions and doing a visual diff and pulling in any other additional information that's relevant to the change order. Again, going back to the analogy of PRs where you're empowering the approver to have access at their fingertips to all the information they need objectively and not having to rely on, you know, how verbose or exhaustive the author of the change order is on documenting what they did.

Michael: So that's, that's really good then. So, okay. So now you've had this change order, maybe have a zoomed in view of like, here's the LED changes there before they were this size after the, this size, you know, Chris did the layout change, so the board, the bare PCB looks a little bit different here. Here's the new, then like what else is in there? The data sheet or purchasing information as well? Like what? Yeah, exactly.

Michael: So through the vendor integrations, we, we often get access to everything from, you know, data sheets, price breaks, lead times, uh, parts, specs, thumbnails, you know, everything that you typically see on the digital catalog itself. Um, most APIs provide you that information and we, we pull it in. So you have that context as well.

Michael: Right. And some of that's just a convenience thing. Cause like as an engineer, I could go and I could screenshot a DigiKey and, you know, show before and after, but then it might be harder to put side by side or, you know, like there's a compare buttons that are on there or whatever, but there's just, there are probably more rich data type things you could put in there. Yeah.

Michael: Yeah. Well, just, I mean, even just parametric comparisons, right? So I, I've been burned by this in the past where, you know, I'm, I'm trying to replace a passive or resistor capacitor or something like that. And I look at the primary specs, you know, the, it's a capacitor. I look at the capacitance, the package, you know, and the voltage, but I've been burned where it's a different capacitor technology or it's different tolerance. I wasn't paying attention to it because that information isn't always as accessible. Some of that information is kind of buried depending on the catalog. And so where I've been burned by that, where it no longer met, you know, one of the specs requirements. And so having, again, having this automated capability to compare exhaustively all the information, you're no longer at the mercy of the subjective review of someone.

Michael: Yeah. Yep. Yep. Yeah. And how thorough they are, right? Like you're, you know, your boss is hung over that day and they're like, yeah, yeah, whatever, I don't care. You know, like that's not saying that's, you know, I'm not saying your boss is a drunk, but you know, you never know, you know, maybe, maybe it's a different drug.

Michael: But like even in this context, right? You're under duress and you're trying to make things do it, do it quickly and resolve it quickly. And so you're going to take shortcuts. You're going to miss things. You're not going to be as complete. Whereas software doesn't take shortcuts. Right.

Michael: Okay. So then how does it know? Okay. So the LED changed. I would imagine there's a change that's going to my assembler. I'm probably revving the board overall. So I'm probably revving the PCB. I'm revving the assembly. If we play a little bit of fun and games here, maybe like if it's a programmable LED, it has a different set of code. So maybe the firmware engineers need to know about it or something like that. That's probably a stretch in this, this made up example, but, but how do you know who to send this to? Like, how do you, how do you determine who's on the distribution list for this sort of thing?

Michael: That's a good question. So there, there are certain limitations, right? So we don't, Dura can't always assess the functional element that's changing. You know, we can, we can certainly compare the, the, the components or the parametrics, but the functional purpose or the context of the change we don't always have access to. And so in that specific example, it might, it might be difficult, but what we do offer are certainly like templates. And so, you know, if it is an electrical change, a functional change, you can create a template of who needs to be on that approval list. If it's just a process change, you can, you know, preset who needs to be on that specific approval list. And so it certainly makes it easier to confirm or comfort for the author to know that they're pulling in the right people. But the, the simplicity of our change order does make it very, very easy to augment or edit if need be. If someone wasn't added to the change order, it's, it's trivial to make those changes.

Michael: Yeah, that makes sense. Okay. And then, so now the thing I wonder about is, you know, you said third parties can kind of see this data too. So now does it send them an email and say, log in to see changes or what is their view? Because I would also think some of the things is the, like the kind of visibility sensitivity, you know, an led on a, an led on a board like that, not a big deal, but some people are quite worried about external data security, things like that. So like, so then how does my assembler, how do I know that just my assembler is seeing the stuff they need to see?

Michael: That's a fantastic question. So remember one of the premises of Duro is to promote transparency. And we feel that a lot of legacy products actually inhibit that. And they inhibit that through functionality or even through their, their pricing models, like how they sell their products. And so a lot of software products sell on a per user license basis. And, you know, and there's different fees associated for different types of roles. And one ends up happening. I can speak, you know, personally about this. Cause this happened to me when I was a manager and purchasing the software, you're trying to plan for a year ahead, buying the number of licenses, but you have no idea, right? You have no idea how many users are going to need access to your PLM system. You have a rough guess of what your current team is. You have an estimate of what you, who you're going to be hiring, you know, over the next 12 months, but you never know if a supplier, you know, wants access. Cause they have some value proposition to offer, or you have some emergency and you have to hire some additional consultants, you know, to help you with a problem and you can't give them access cause you didn't buy enough licenses. And so again, there's a lot of friction in the existing hardware, you know, data management tools that are really slowing down progress in the industry. And so Dura just has a very different model. We, we don't really sell by the per user license model. We, we sell more based on the features and the value we're providing to a team, less on the number of users. And so we make it so much simpler to distribute licenses either on a temporary basis or on a permanent basis for anybody, whether it's an in-house engineer or, you know, a third party supplier, because there's value. Like there's a lot of value in your contract manufacturer or your CNC shop or your EMS to have access to the changes much sooner in that life cycle, because they're the ones who are going to be responsible for building it. And so any kind of...

Michael: I really want them to be like, no, no, that's a terrible idea. That's what I really, that's at the end of the day, that's all I want them to do is I want them to tell me immediately when I'm getting approval from everybody, Chris, that is the worst idea you've ever done. That is, that LED is going to explode. It's going to ruin your product and we can't make it and we can't buy it and all these other things, you know, like I just, I want to know that as soon as possible.

Michael: And they want that to go to your Twitter account to all your viewers do that. You made that mistake too. Oh, they all know. We all know. We have that technology. We can do that. Yeah.

Chris Gammell: Yeah.

Michael: No, but, but, but, but what is being inhibited is some of the fundamental principles of hardware design, you know, DFM, DFA, design for manufacturability, design for assembly. And who better to give you that feedback than your actual assembly or manufacturing house. And so by giving them access much earlier into your design decisions, they can give you that feedback much sooner and you can course correct much, much more efficiently versus, you know, having to throw it over the wall and getting feedback from your, you know, I have other anecdotes where, you know, I'm working with a CNC shop or in checks and molding. And it was just a simple feedback. Hey, can you change this draft angle from like 2% to 3% because we'll be able to release it faster. And you just, you'll have a higher yield. It had no functional difference, you know, to our product, no aesthetic impact. It was a simple change. It was like, you know, five minute change. But because in this specific example, I'm remembering because we didn't give a copy of the CAD file, the step file to our CNC shop until it was already been designed and already been through our review process. And then they gave us that feedback. We lost like two weeks of productivity. Yep. Yep. Yep.

Michael: And it's worth it. It's worth it in that case to, because of the long-term nature of the manufacturing and the, you know, the million shot mold that you're making, it does make sense to do that, but you've lost that, that time's not coming back.

Michael: Well, you're not getting that time back and it can compound really quickly because a lot of these manufacturers, you know, they lose money when their machines aren't operating. Yep. Totally. And so, you know, if you have a good relationship with them, you've already scheduled ahead of when you're planning to do some build and they've slotted you into their timetable. And anything that, you know, bumps you out of the timetable, they're going to have to fill it with another job. And if you're lucky, you know, you get bumped by like an hour or two or a day, but it's not unreasonable to be bumped for weeks.

Michael: Yep. Yep. Actually, I have another cost example there too, where to get around that specifically to get around that, a mechanical group I used to work with, they just sent a guy to China where they were cutting on the molds because he was designing the molds, you know, from a, moving it from a, uh, industrial design to more of a mechanical design, actually make making the molds. But he was sitting next to the actual mold makers. Oh, that's great. We're going to be cutting them with CNC in China, in Shenzhen. Yep. And like, he's just like, yeah, I just kept changing stuff when he told me that's a bad idea. And it's like, well, first off, that's fantastic feedback, but the cost of sending that guy, if you can now reduce that, that's also, you know, a huge cost savings because of his amount of time and time differences. Absolutely.

Michael: Look, all right, here, here's just another opportunity to go back to software. Right. So the software agile principle is fundamentally all about that feedback loop, right? That's what agile means is being able to have these tight loops time, time-wise of design, tests, evaluate, right. And, and, and, and, and responding to those tests and responding to those evaluations in a quick, tight loop, you know, timeline loops so that you can evolve much faster and learn much quicker. And so the tighter you can make those feedback loops in a hardware space, the better that we can evolve and the more that we can innovate. Right. And, and so the difference being is in software, it can be the same person or like using automated tools to kind of create that feedback loop, or at least there's fewer people that's involved and hardware, as we, as we've discussed, takes multiple teams and different people. And as in your anecdote, you know, in different countries and different cultures. And so the tighter we can make those loops, you know, the better we can perform, the more efficient we can get to a better product design and reduce all those overhead costs that are associated with it.

Michael: Yeah.

Michael: Yeah, definitely.

Michael: So what is the end of this cycle? Let's, let's, let's wrap up this, uh, this change order. So we've changed an LED. It's gone to everyone. They've given me feedback. They said, that's a terrible idea, blah, blah, blah. Maybe I, I revise again. I find another one, you know, I do another cycle, which is something that's happened. I, you know, I remember like shopping around an idea on a change before doing that, because I knew the cost of trying to circulate paperwork, for example, that was very high cost in terms of time. So I would shop around an idea first, but maybe I have to do another design cycle. Then it gets approved. Then like, what is, what is it? What does a true release process look like then?

Michael: Well, we have quite a few options. Uh, so at a minimum, you know, once the change order is approved, everybody on the approval list, and we also have additional notifiers, people just need to be made aware of the change order. They'll get an email, uh, with the final decision. And if it was approved, they'll get a link. And this is something that's also, it's, it's subtle, but it's an important difference. So this automatically generated email will not include an attachment of, let's say the Gerber files in this case, it'll include a link. Yep. And the reason why that's different and important is because if it's an attachment, it falls into that same risk of it always being in someone's inbox and being able to be accessed at any time, which means they can accidentally grab the wrong revision.

Michael: Yeah. I call that the source of truth problem, right? Like if, uh, if you have 50 different bombs floating around to different, uh, vendors and whatever, but it's really the, if the schematic is the source of truth, that's where all the data lives. Or if your PLM is the source of truth, whatever you seem to say, this is the official thing. If you don't check this, I can't be, I can't be held liable for whatever the hell you do with this data.

Michael: Correct. Yeah. And so that's exactly. And that's why making it a link allows you to control that because now you're guaranteed that link will point to that single source of truth. You can control the link. You can disable it, right? Once either based on different criteria, it can be, you know, time-based after 48 hours is no available. If there's a newer revision of that Gerber available through whatever, you know, history, the original link can be disabled. You have more capabilities of reducing that risk of the wrong file being put into production. Huh. And so those are some of the things that you have options, but, but again, it depends on the integrations you have with Duro. You know, we have integrations with several ERP systems. And so the change order can automatically also push that information to your ERP system. If that's what you're, you know, you use for procurement and order placement, or we even have integrations with several MES suppliers.

Michael: Can you explain the ERP thing a little bit deeper? Cause I think that's, that's important as companies scale as well. Right? Absolutely.

Michael: Yeah. It's, it's larger companies will often separate out, you know, the inventory management and the order management of, of production from the engineering team. And typically ERP enterprise resource planning tools are used to manage that. And so ERP often contains information about your suppliers and any contracts you've negotiated with them, any terms, as well as the production versions of your bill materials and CAD files for actually, you know, placing the orders. And so it's kind of a stop gap. It can be considered a stop gap between your PLM and your, and your suppliers. And, and, and sometimes for good reason, you know, because you kind of do want to divide responsibilities for purchasing procurement and planning from the engineering team. It's just a different responsibilities and just so they can focus their, their expertise.

Michael: Well, I think about the, uh, the accounting piece as well. Right. So like at some point money needs to change hands and you're probably buying stuff in bigger quantities. You know, if I have a design that gets released to production that has a hundred thousand resistors on it, that's probably not the only 10 K resistors that are, or sorry, a hundred, a hundred thousand resistors per year rather for it, because there's 10 resistors on there or making 10,000 a year, that sort of thing. Then like there might be other people at the company though, where they're trying to buy 10 million resistors total. And that's in the ERP system versus what's being released per design.

Michael: Correct. Yeah. So PLM is more of where you keep the designs and, and certainly preferred suppliers or information, but in ERP can be where you pick, you consolidate across different teams and different projects, as well as have the formal relationships with your suppliers, any price breaks or, you know, terms for payment. Yeah, exactly. And your, your formal, what's called your AVL approved vendor list. Oh yeah.

Michael: A couple, a couple of acronyms here, huh?

Michael: There's so many three other acronyms in our industry. Yeah. And so again, you know, traditionally PLM and ERP have been siloed products and there's important information, even that's stored in ERP that an engineer should have access to. And around supplier information, you know, again, if, if you have an AVL and it's stored in your ERP, you're not giving, you're not empowering your engineer to pick from that AVL if you don't give them access to it, right? They might unintentionally pick a part from a vendor that's not on your approved list. And again, it just creates another delay. And so having that information more upstream just allows the engineer to make better decisions soon. Yep. So in some cases our customers use, you know, ERP system. And so Dura, through the change order process will automatically, you know, migrate that information to their ERP to then, you know, the procurement team or operations team to do their job.

Michael: Yeah. So at the end of the day with this, okay, so we've had this change order and we're going from rev A of the board to rev B of the board, because it's significant enough, whatever our internal thing is to say, yeah, it's not a rev A too, it's a rev B now. Yeah. And then someone in production or operations or purchasing or whoever's in charge, they now see that it's rev B has been released.

Michael: And then they kind of kick off that almost like a mini NPI or what do you, what do you see in that, in that realm then?

Michael: That's really case by case for each company on how they do manufacturing. You know, in some companies, the contract manufacturer will take that information and they'll see the rev change. They'll often use, you know, the part numbering to help guide where it goes. If it goes to an engineering team or operations team, electrical or mechanical, and then each respective team will do their job. They'll see that the rev change from A to B and then do their own tasks to see exactly what's changed. Yeah.

Michael: Yeah. They might change it. Like the manufacturer is probably going to change out the job on their pick and place machine or whatever it is. And correct. Yeah. Testing probably has new testing capability or. Yeah.

Michael: It depends on the magnitude of the change and the impact. Yeah, exactly.

Michael: Right.

Michael: But I do want to highlight, you know, the third option that Duro has is, which is fairly unique is we do have direct integrations with MES software packages. And so for customers who do their own manufacturing to manage their own shop floors, you have a direct connectivity from CAD through Duro to your shop floor, all pointing back to that single copy of that bill materials that Gerber files. And that's, that's pretty novel. It's in my experience, when I was managing manufacturing, it was always an air gap from PLM to MES. Right, right, right, right.

Michael: Yeah, they, they might, they might have the, so the MES might say, all right, we know we're on job, you know, 4499 and that's going to be making rev B of this LED board, but we don't know what the schematic looks like.

Michael: Or they have to email, you know, get, get access to that information to the Gerber or, you know, whatever the, whatever the windows drive, go to SharePoint. Or dig, you know, dig through and find that email that have the attachment. Exactly. And so by having complete end-to-end connectivity, it's, you know, certainly shortens that timeline it takes to go from CAD to your shop floor, but also just guarantees accessibility to confirmation so that the team on the shop floor knows that they're working with the right revisions. They're not crossing their fingers.

Michael: Totally. Yeah. Because they want to, I mean, yeah, exactly. I mean, I think that's, that's like every, if you start from the assumption that everybody wants to do the best job at their job possible. And it's like, not just about having access. It's not about having access to all information. It's about having access to the right information exactly when you need it. And like, that is a really tough problem, I think. Yes.

Michael: Yes. But it's getting easier, you know, and, and it's, it's, I've.

Michael: Well, there's more data though. That's, that's the downside. Right. I mean, like if I say I was like a manufacturing engineer and I was like, oh, well it changed from, you know, the LED A to LED B and all right, now I want to go in DigiKey. What the hell? I just imagined that.

Michael: Fair. There's, there's more information, but you know, with proper filtering and, and, and processes, you can get to what you need much quicker. I'd, I'd rather err on having access to more data than not.

Michael: Hmm. Yeah. Some days I'm like that. Sometimes I'm in the other direction. I mean, that's the thing. Manufacturing is like just super, it's just tough. I mean, it's just tough to do this stuff. And, um, you know, I think one of the things that I always think about, uh, is the bigger companies that have the shorter timelines, especially in consumer, it's not necessarily they have better tools. Sometimes they have internal tools or things that are more like vertically integrated or whatever. But from the experiences I've seen, it's just, they have more people grinding. Yeah. Stuff. That's it.

Michael: That, that, that, that was a huge, huge, uh, eye opener for me. You know, when we first started Duro is I, my career, I just personally liked working at smaller companies and startups. I just liked that environment.

Michael: Yeah.

Michael: More so. And so I always thought, you know, when I had these frustrations about how inefficient the tools they were using, I just thought that that was just because the nature that I was working for startups and we had less resources and that, you know, the enterprise companies who had effectively unlimited resources didn't have these same problems and they were walking on easy street. But so, you know, a little bit of have NDAs for all their other employees.

Michael: They can't talk about it. They can't talk about how much work's going on behind that curtain. Exactly. That's right.

Michael: No, but so some of the origin of, of Duro was, you know, when I moved to LA five years ago, almost six years ago, I met my now co-founder, Kellen O'Connor. And we were both mentors at a hardware accelerator here and we're just, you know, shooting the shit and talking about our respective industries. And he was an early mechanical engineer at SpaceX and he confided that they had the same problems. Like it's, and, and then was now a well-known anecdote that, you know, SpaceX built their own PLM system because they were so frustrated with what was available in the market. And that even that, you know, has its own stories of, of success and failures. But the point is, is, is that even the big guys, the, the, the unlimited resource companies still had these problems and it got further proven that it was a problem is when we started talking to, you know, colleagues and peers who worked at more established enterprise companies. And I'd asked them like, you know, what do you use for managing your data? And they said spreadsheets. Yep. And I said, why? Like you have unlimited access. You can do, you can design and procure whatever you need to manage your data. And they said, nothing out there works as fast as we need it to. There is so much time pressure on our team to get products out to market, especially during the NPI process. The only thing that can move so fast is a spreadsheet. And that's, that's kind of was the aha that we needed to really start doing. Like, okay, there's a really big opportunity here. It's not just for small teams or limited resources, you know, hardware companies. It's for even enterprise companies have this problem. The legacy products were just, they were built for process. They were not built for flexibility or speed. And that's what the industry needs today.

Michael: Totally. Yeah. I, I've seen it too. When I was at ABB, formerly Bailey, I, you know, moved, moved there, got into the company. It was like, I'd like, I liked it. You know, they had this weird PLM system though. And it, and it was, uh, it was homegrown.

Michael: Yeah.

Michael: And, uh, and I was like, oh wow. Like where's the team working on it? And they pointed it over to this guy's desk and then they're like, it's him. And he had been there 25 years building that one thing. I was like, what the hell happens when he retires? Yeah.

Chris Gammell: Oh yeah.

Michael: Or just, I've worked with companies where it's that one person, the only person who knows the naming and the magic, the magic person.

Michael: Like, and, and then like, they know, I'm sure they've all done, you know, they've all woken up in a cold sweat at some point, you know, they thinking about the hit by a bus problem and they just must push it to the back of their mind. You know, it's super more morbid, but like, but there, you know, this kind of stuff happens and like, you are completely screwed when that happens.

Michael: Yeah. It's just, it's terrible. Of course. Well, so I, here's, you just opened up another opportunity for me to point back to software. So imagine someone joining a software company and saying, you know what? I'm going to build my own kit. Your own kit. Yeah. Yeah. Yeah. People have done it. Yeah. You're on GitHub. Sure. Sure. Sure. You know, but, but, but there's no reason to, right? Like, it's like, it's just, it's unheard of. Like, get, you know, GitHub and all the, you know, the derivatives are very, very powerful. They're free. They come included, you know, with every Mac laptop. And there's just, there's no reason for that to be, you know, someone.

Chris Gammell: I think, I think you mean Unix based systems. Yeah. I don't want, you know. Oh man. Soapbox. Go away. Soapbox. I'm done with you for the day. I promise.

Michael: Hopefully, hopefully my microphone has not been popping this whole time. The last episode we recorded and I was like, at the end of like, oh, I'm all on Linux now. And the whole time I'd been recording, the microphone was just like, pop, pop, pop, pop, pop, pop, pop. Cause like my Linux is all crap. So don't get me wrong. I hate it too.

Michael: So of course, but the point I'm making is, is like the software industry has figured out how you get the commodity tools cheap and readily available and easy to use. Right. So that developers, engineers, software engineers can do what they're hired and trained to do and not spend so much time configuring their underlying tool chain. And it's, it's just time for the hardware industry to catch up and figure that out. Totally.

Michael: Is there a similar layer that is open source now, or is it kind of just more gluing together? Like just saying APIs are the open thing, you know, like, so like you're saying, Git has this compatibility layer, you know, it's, it's revision control, but it is a compatibility layer with GitHub specifically and other, you know, tools built on top of Git. Is there the equivalent thing, you know, like open marketplace type of thing or still working on it?

Michael: Good question. I don't know. I know there's been certainly a couple of stabs at it in the past for creating, you know, a common standard for interoperability of data. I don't know any that has really seen any much success.

Michael: So Duro stuff is not, there's no like open Duro piece then?

Michael: Not yet. I mean, we have an API and that, you know, certainly lets people, you know, integrate their accounts with any tools that we don't currently have integrations with or other software providers who want to be part of our platform. They can use our API and, but that that's, it is where we're going, right? We need to, in order for Duro to see its full vision, you know, look, we have certain capabilities, we have certain expertise and we have certain areas where we think we can provide real value. But it takes a village to build a hardware product and we're not going to, we're not going to be, you know, the best in all those different disciplines that it takes to design, manufacture hardware. And so we'd love to partner with other companies that are taking other pieces of this big pie. And so absolutely, like we want to make our, our platform as compatible and easy to use as possible. And that's, that's maturing over time.

Michael: Yeah. I mean, I think about like just the, you know, you have to kind of, kind of like putting your own life, your oxygen mask on first. It's like, you know, you're building this company and then over time you can be sustaining enough that you're like, all right, well actually we can open source pieces of this. And then that helps to build out the ecosystem as well. More people join in and it just starts to snowball and that sort of thing.

Michael: I hope never to be called a hypocrite, but it allows us to practice what we preach, right? So my gripe earlier about, you know, CAD companies controlling their data and making it harder for people to take CAD files and innovate further. We want to allow people to do that. So Dura wants to own the bomb and the revision control, but if other people have other ideas or, you know, room for innovation for how they process that information, albeit, you know, here's our API, you know, build another comparison tool, build another simulation tool, build another, you know, proposition that helps making change orders, you know, go faster. Please do, you know, and here's the API to do it.

Michael: I think there's a lot of place in, in the market. There's a lot of room in the market rather for, even if it's just kind of like a little bit of boast at first, not boast, like it's a little bit of like chest thumping, just being like, this is the standard now. You know what I mean? Like, and just publishing an open standard about something that you're hoping to do, that helps. It has its own gravitational attraction. You know, whether or not it's going to have ultimate success is completely dependent on other people being like, yeah, that looks good enough. We'll use that too. But like, that is something that needs to happen over time as well, where there's, there's standards, whether or not they're legitimate or not. Like, how about, for example, the open parts library? That's probably not a good example. I'm trying to think of a good example here, but like, you know, where people are like, we're going to have an open piece of information. And then other people adopt that as a, as a quasi standard.

Michael: Yeah. I, the cynic in me is, is if there's a lot of smart people get in a room and say, you know, let's put together a standard, but nobody uses it or finds it practical. Like it's, what's the point. Right. So I think, I think the industry is just going to naturally gravitate to whatever's practical and easy to use. Yeah. Whether it's a formal standard or not. And so that, that's what we're striving for is, is how do you make it super simple to get your tools up and running quickly? How do you make it super simple to get your data into our platform, run through an iteration and validate it so that you know that when you release your bombs, your supplier, they're clean. They're good to go. There's no issues. Yeah.

Michael: As we, as we finish up here, like, so people are listening to this and they're like, all right, these problems seem familiar. What, what is kind of the archetype of a engineer and or company that would really like take off from Dural on day one? So like, is it a one person company to let's do a Fibonacci sequence. One, one, two, three, five, eight, 13, 21 person company and on up. Yeah. Yeah.

Michael: No, it's, so there's, there's the short answer and the long answer. The short answer is anybody who's actually building something.

Michael: Ah, we knew you were going to say that. Come on.

Michael: No, no, no, no. There's a second part of the class.

Chris Gammell: Oh, the whole world is my client base.

Speaker ?: Yeah.

Michael: I once, I once walked into CES and I said, this whole conference is our customer. Anybody here can use Dural, right? Sure. Sure. At a technical level. No, what I'm getting at is, is traditionally companies don't start adopting PLM until, in my opinion, much too late. And they only do it once they start to see the pains of using that spreadsheet or they actually got burned by some production line. Yeah. And a lot of that reason is because I credit to the fact that PLM systems, existing systems are just too hard to set up. And so, again, when engineering teams charter to move fast and get things to product, you know, to get products to market fast, anything that impedes that is considered a distraction. And so, it's been a little bit of a chicken and egg. Like, it's because the tools are so hard to use, nobody uses them, yet they need to. And so, by making the tools, oh, and then the culture just assumes that you don't need them until much later. Because the culture just kind of assumes that mentality. And so, by making it much easier to adopt the PLM system, there are hopes to break that stigma where engineering teams, as soon as they're at some decision to be a mature company or mature product, they realize they need a PLM system or vision control, part numbering and centralization. I mean, this is a perfect, I'm going back to software again, right? So, every single software team, the very first line of code they write is Git init. Meaning they lead with setting up the revision control system and then they start writing software. Because that's just culturally what is considered to be the best practice and Git has made it so easy to do so. Yet, almost every hardware team, the very first thing they do is just dive into CAD. And they start doing design iterations and they'll do some local file revisioning on their Windows laptop, whatever it may be. And then only once they have a moment to pick their head up or they realize they're at some risk point that they feel like they're flying without a net, will they then retrofit it with the PLM system. And so, the hardware industry lags with revision control.

Michael: All right, I'm going to anecdotize this. I actually start from Git every time. I start a repo anytime I start a new board.

Michael: Great.

Michael: But that's not a PLM system, right? Correct. Yes. So, how about this as an indicator of when listeners maybe should think about a PLM system? Because I think this is when I've started to panic in the past. When I am making two boards with an interconnect between them, I should be in a PLM system. Because now, if board A changes, the top board is talking to the bottom board and the bottom board changes, that impacts the top board as well. And then the whole product is a combination of boards now. So, I would think at that point, I'm screwed. Because like, yeah, I could have two Git repositories or even a single Git repository that has these two boards in them. But I need to then be able to track what's actually being sent to my manufacturer. And more importantly, what two boards are getting screwed together and being sent to an end customer. Because that's when all hell breaks loose.

Michael: Well, there's a couple of things there. So, first off, kudos to you. You're in like the 1% of hardware engineers who know how to set up Git. And growing. Absolutely. And so, seriously, like kudos to anybody who has recognized that Git is a valuable tool for managing their CAD files, right? Git will fall apart because it's not known to handle large binary files at some point. And you obviously can't leverage all the benefits it provides because, again, those proprietary formats don't let you do like comparisons and mergers and diffs easily. Sure, sure. But still, kudos to you for setting up proper revision control on those files. And so, yes, we need to get more people to just recognize that they need to revision control sooner. And hopefully, they'll adopt PLM or maybe Git will get better at managing CAD files. But the other thing is, yes, I think I would define it a little better. So, you said when two boards need to interoperate. I would say when two people or two elements need to interoperate.

Michael: Okay. All right.

Michael: Where you need to have transparency and awareness of what each entity is doing and how they relate.

Michael: But, I mean, in a practical sense, I feel like I could get away with it. Like with one board, you know, like that's, I'm sending it to my manufacturer. I'm getting it back. That's pretty standard. You know, like it's, I send it out to JLC or Oshpark or whoever. I'm getting it back. I'm sending it over to, you know, it's a hassle. Don't get me wrong. It's a hassle.

Michael: But with using your Git, you know, tool chain, there's still a lot of manual steps that you need to take care of that the PLM will take care of for you.

Speaker ?: Yeah.

Michael: Okay.

Michael: All right. And that includes managing. So, Git revisions are just hashes. They're not human readable. You know, they're not the hardware industry standards of numeric or alphabet. You know, you'll have to rely on your own note taking to know what changed.

Michael: I could tag revisions, right? I could tag revisions. I could do release notes. All the things that are there. Sure.

Michael: But my point is, it's dependent on, again, on how verbose you feel that they are if your boss was drunk. Sure. And, you know. That's right.

Michael: Yeah. Yeah. No, I think you're right. And I think when it goes from, you know, so now I'm a single engineer and I've got a product with two boards in it. And then my boss comes to me and says, actually, we need to do a revision. Or sorry, we need to do a modified board now and actually keep that same bottom board. Now you have two top boards. And it's just like, it starts to just spiral out of control from there. So that, yeah, I mean, that's crazy.

Michael: Oh, of course. That's a perfect reason to use it. But the other thing, too, that I think doesn't get as much notoriety as it should, the value that PLN provides is a centralized part numbering system.

Michael: Yes. Yes. And we've had Jan Richter on the show. He talked about it from PartsBox. And, you know, he was big about having centralized part numbering as well. And, you know, it's just, it is the right way to do things. And, boy, that's still, I'm still stuck in the past on that one.

Michael: Okay. Well, so the value of a part numbering system is because it alleviates the ambiguity. Because, you know, a formal number is immutable and there's no chances of misinterpretation. Whereas if you rely on part naming, there's huge, huge vulnerabilities of conflicts, naming conflicts, or misunderstanding, or just, you know, miscommunication of references. I've literally seen, you know, when I was a consultant, I would help engineering teams kind of get their ducks in a row and get organized. I've literally seen bombs where the part name was a screw that Bob knows how to install.

Michael: Wait, that string?

Michael: That string was in the Excel bill of materials. That was the name of the part, right?

Michael: Oh, what was your reaction when you saw that?

Michael: Well, I, again, I was like.

Michael: I just peed a little.

Michael: I couldn't believe like how out of touch I think even the most modern engineering teams are. Just awareness of the risks of conventions like that. And so by leveraging part numbers, you remove all that ambiguity and all that room for interpretation. And so that is something that Git doesn't do, right? That's something that PLM is responsible for is it assigns automatically generates part numbers for every part assembly that you create in your library. And so then when you discuss parts or assemblies, you can refer to them by their part numbers. There's no risk of ambiguity, misinterpretation, misinformation, or conflicts, right?

Speaker ?: Yep.

Michael: Yep. Yep. No, that's great. That's great. I think that's the sort of thing where it's people can bring this stuff, you know, as solo engineers as well, they could start to bring this back into their lab and set up this sort of thing. It just, it's, I feel like it's kind of like a muscle you have to work out as well. You know, like just of like, you know, you're looking at a bomb and you're like, oh, why is everything with MPNs instead of, I kind of think this when, you know, I do a bomb upload to a service. And they're like, well, what's your, what's your customer part number? Like, what's your part number for this? I'm like, I don't know. MPN is the part number.

Michael: Yeah, no, exactly. Right. And so that's, that's another reason to use PLM much earlier. And I feel that, you know, there are many, many engineers who understand that value. But again, because a lot of the legacy tools just make it so complicated to get them set up and start using, they just procrastinate.

Michael: Oh, I'm great at that part. Well, if people aren't procrastinating and they want to get started with Duro, what should they do next? It's very simple.

Michael: You can go to our website, getduro.com. Certainly read through. We've got a lot of great blog articles. I even have some articles where I talk about the value of part numbering systems and the pros and cons of them. Feel free to browse through the different package options we have. You know, I call them like the small, medium, large. You know, more formally, it's the PLM starter, the professional or the enterprise packages. And they're specifically tuned for any kind of stage that a hardware team is at either. They're just so early and just doing some design iterations. They just, as I said, they just want something to centralize their information. That's not a Google Sheets. It includes our CAD integrations, our vendor integrations and proper part numbering and revision system. Our professional package is a complete PLM system, you know, out of the box. You can literally be up and running in an afternoon, just create an account, upload your spreadsheets and integrate your CAD files. And you can release your suppliers in an hour. And then our enterprise package is for companies that have either outgrown those two smaller packages or just have a more complex, you know, configuration that they need for their existing team.

Michael: Yeah. Yeah. Hooking into the other systems like you're talking about. I'm sure that's.

Michael: Yeah. Hooking into more systems, you know, more downstream solutions, ERP or MES or, you know, more complicated tools or routing or numbering conventions. Yeah.

Michael: Yeah. Yeah. I like the comparison too of like the cost of engineering. Like you're basically buying your way out of hiring a manufacturing engineer. The first operations person, maybe internally or something like that, or your first purchasing agent. And I would also say you're, you're probably buying your way out of your first product recall.

Michael: Well, I mean, what we hope is that you're not, you know, you're not watching a production run go into the garbage can. Right. Yeah.

Chris Gammell: That's true too. Oh yeah.

Michael: And I've had that, like, you know, that happened to me. I still have nightmares and flashbacks to that day when I was in China, you know, watching a production run of, of one of our radio modules. And once, you know, the first two went through the end of line functional tests, we realized that someone had installed the wrong radio module. Oh my God. Visually they were indiscernible, but there was just a suffix in the part number that was wrong frequency or something like that. It was the wrong frequency. It was the European versus the U S version. And because it was such a large module, it wasn't able to be reworked without serious damage. And so I literally watched the units come off the assembly line and go straight into the garbage can. And it was, we rooted it into the fact that it was an email using Excel to export the information important to another system. And the part number got jarbled.

Michael: I know those feels, man. That's.

Michael: And so that's, that's what Duro is striving for is to reduce any risk, certainly of a production mistake like that, but even minimally a delay, you know, any kind of, you know, as I said earlier, any delay can compound really quickly. And certainly impact customers capabilities to meeting, you know, their own, you know, time to market demands.

Michael: Well, Michael, thanks so much for joining us here today. Thanks for all the stories and talking about PLM. This, you know, I feel like it's always like this, Oh, we're going to talk about PLM, huh? But like, it actually, you know, it's just like boots on the ground. Like this stuff matters and it, it just enables people to look better for their bosses and get their job done and like go home and have dinner with their kids. And just, you know, like all of the work life stuff that's better because, because manufacturing sucks sometimes and this makes it suck less.

Michael: It's it's manufacturing is really hard and it is literally hurting cats. And the more we can rely on technology to take care of a lot of the fundamental underlying tasks, the better we can become at focusing on being engineers.

Michael: All right. Well, thanks so much. And we'll, we'll chat with you soon. Thank you, Chris.

Speaker ?: Thank you.