AI-Powered PLM: The Future of Hardware Product Lifecycle Management

Discover how artificial intelligence is transforming Product Lifecycle Management (PLM) systems in this insightful conversation with Michael Corr, CEO and founder of Duro. From eliminating PLM horror stories to streamlining hardware development workflows, learn how modern cloud-based PLM platforms are revolutionizing the way engineering teams manage data from design through manufacturing.

Michael shares his journey from electrical engineer to PLM innovator, revealing the critical pain points that plague traditional PLM systems and how AI-powered solutions are solving decades-old data management challenges. Explore how intelligent automation is reducing manual processes, improving supply chain integration, and enabling hardware teams to focus on what they do best - designing innovative products.

Watch the Episode:

More Resources:

• Connect with Michael
• Get Duro

Transcript:

Zach Peterson 

Hello everyone and welcome to the Altium On Track podcast. I'm your host, Zach Peterson. Today we're talking with Michael Khor, CEO and founder of Doro. Doro is a company that produces a PLM system and as someone who is always eager to learn about manufacturing, lifecycle management, these types of things, very excited to talk about to Michael today. Michael, thanks so much for being here.

Michael Corr

Thanks for having me, Zach.

Zach Peterson 

Absolutely. So you are a new guest on the podcast, so welcome. And of course, when we have new guests, I always like to ask if you could tell us a little bit about your background.

Michael Corr

Thank you.

Michael Corr

Yeah, sure. Actually, my background, I started my career as electrical engineer, designing and manufacturing various products, more in the wireless RF technologies. I designed telecom equipment, radios, wireless lighting devices, drones, IoT, you name it. I spent quite a healthy career actually using LTM products and various other technologies.

Zach Peterson 

So you started in wireless. And I think one thing that I see often with folks who have more of a hardware background is they don't often transition into software. So if you could tell us a little bit about how you made that transition into doing software.

Michael Corr

Yeah, well, as electrical engineer, and I realized this wasn't ubiquitous, I did spend a considerable amount of time in embedded systems. So I was keeping my software development skills tuned in developing firmware for the products I designed. But one of the reasons, or the main reason, you know, I eventually moved into complete software and SaaS technology was as a user in the industry using existing CAD, PDM, and PLM and other software products to help me do my job.

I just saw a big opportunity for improving the status quo and becoming evolution that was happening in our industry. And I got very motivated to help the larger community into building more current and more agile like technologies. And so that really moved me away from electrical engineering and into software.

Zach Peterson 

OK, so you're seeing this opportunity to develop a cloud platform. I guess I just have to ask, why PLM or PDM?

Michael Corr

Yeah, it's a great question. Honestly, felt that a lot of, know, there's that saying hardware is hard and I actually don't agree with it. I don't think hardware is hard. I think it's the data management that's always been hard.

compounds itself into a lot of overhead and complexities for building hardware products. There's a lot of herding cats, so to speak, to managing all the disparate data that's used to design, procure, and manufacture your product. And I felt that the root of all that problem was really in the centralization in what was the PLM product category. And so I felt the best impact to improve the larger hardware.

industry was to focus on PLM. And one of the things that I noticed how in the software industry, there's a lot of analogies that in the mid 2000s, you know, what I refer to as the whole agile Renaissance where the software industry saw an explosive growth of technologies innovation that really what became today's cloud and agile workflows and APIs.

One of those catalysts was GitHub, you the centralization of source code and the power it provided for everyone to kind of come together and bring their capabilities and bring their resources and source code to rally around a product. And PLM is that analogy in the hardware ecosystem to revision control and GitHub. And so that's where we thought the biggest impact for improving the industry would be.

Zach Peterson 

That makes a lot of sense. And I think before we go further, if you could maybe just tell all the viewers out there, because we have viewers of a wide range of experience, folks who have worked at OEMs for a few decades, all the way down to students and new designers and freelance designers. What is a PLM system? And on top of that, why do hardware people need it?

Michael Corr

Yeah, no, that's a great question. think a lot of people across the demographics who just described have their own perspective of what PLM is and their own personal experiences with it. In some circles, PLM is considered a four-letter word. It's not something that people like using and or enjoy participating in setting it up or administrating it. And I think honestly, that's an artifact of its history, know, historically.

PLM was a very complex product category that had so much extensibility.

that almost kind of backfired, know, the expression, give yourself enough rope to hang yourself with. There was so many ways to configure a PLM system and there were so many integrations that were required that were provided by so many different parties that it added to the complexity and the inconsistencies and the, you know, the lack of interest in it. And so that was basically Dura's approach is how do we simplify that experience? How do we make, you know, the,

an 80-20 rule, how can we solve 80 % of the industry's needs with only 20 % of the functionality? Because we found, certainly in earlier stage companies, whether they're startups or NPI teams and larger groups, companies, they all have the same motivation. They just needed simplicity in getting to products faster.

as soon as we began to price to market faster. And they didn't need that level of complexity that some traditional PLM products offered. And so by stripping it down to the core functionality of what PLM is, which is really the integration of CAD data, procurement information and manufacturing information, all centered around the change order event, the presentation and review of changes and revisioning those changes. That's what PLM is, making that whole system simpler, out of the box,

Michael Corr

out of the box industry standards for part numbering and revision control, out of the box plugins for the most common CAD and ERP packages, it really removed that complexity that had historically plagued the legacy product providers.

Zach Peterson 

So you just mentioned that PLM being a complex product category. And you said further that there's a variety of ways to set it up and configure it. And I'm wondering, was that your direct experience? Did you see people do very odd things inside of PLMs because they are a complex product? Can you tell us any PLM horror stories?

Michael Corr

Yeah.

Oh, I've got tons of horror stories. I don't think we have enough time in your show. And now being in this position of working with many more customers, I see even more horror stories. Well, I think there's multiple angles to approach your question, but I think one of the purveying issues was there really wasn't any standard for how to do things in hardware.

you know, because there were no existing APIs or interfaces that were established to really, while there are some communal best practices that were agreed upon, they weren't really taught as part of engineering. Your education is more of like on the job training or just trial and error of learning what worked or didn't work. And as a result, there are so many bad workflows or partnering schemes or revision, you know, change order workflows that

added complexity for complexity sake and added more issues than solving problems. And so that was, you know, very simple examples on just like, you know, partnering systems, know, CPNs, customer part numbers. There are 52 ways of doing partnering systems and I'd argue 49 of them are wrong. You know, it's just people don't, and it's not to people's discredit. Like some people just don't have the experience in

market to see all the issues that incorrectly designed partnering systems could create. know, redundancy, inconsistencies, or you know,

Michael Corr

one off, you know, issues with a particular part or assembly that doesn't fit the CPN scheme. And so there's all these little asterisks like use this scheme except that this case, right. And what ends up happening is when you have all these issues, ultimately it's the manufacturer who bears the burden of interpreting the information and the more complex it is, the harder it is for manufacturer to understand your bill materials, to understand your nomenclature and to have confidence that they're putting your product

its production correctly, right? Remember, what's unique to hardware compared to the analogous software products is it's a different team that manufactures, in most cases, different team that manufactures your product that designs it.

they don't have that inherent intuition of what is correct or what's not, or all those little, know, mind meld notations that a design team has when they collaborate together. They only can reference the documentation that you passed to them. Often that documentation is transferred from the design team to the manufacturing team through PLM. And so PLM is a great opportunity to clean it up, to normalize it, to make it consistent, right? Otherwise, if you don't, again, if like the electrical engineering team uses one's

and the mechanical team uses another standard, they all have to come together to a common bill of materials for the manufacturer to read and interpret. And the more discrepancies there are, the more onerous there is on them to make sure they're interpreting it correctly. And so the more complicated it is, the higher the risk that they misinterpret it and put a mistake into production.

Zach Peterson 

Yeah, I can already see a horror story arising here because you've brought up multidisciplinary teams that potentially have different part numbering systems, even though they're referencing things that are going to end up in the exact same product.

Michael Corr

Yeah, exactly. And then again, going back to what, you know, one of the original motivations for Dura was, was we intentionally restricted CPN schemes to only a handful of what were accepted industry standards. So to minimize that risk that a customer would come up with some convoluted scheme that would put them in the same issues that we just described. And so again, by being intentionally opinionated, we help customers A, not have to worry about it, especially if they don't have the experience to know how to set up a system like that.

They can just trust that Dura's out of the box selections will suffice. But again, it helped clean up the data and normalize it so that it greatly reduced the probability of misinterpretation and mistakes getting into production. And that's really what customers love was that simplicity of putting all that burden of configuring their accounts and making sure that the workflows they selected were appropriate, putting that burden on Dura.

so they can focus on what they were truly hired to do, which is design and manufacture of cool products.

Zach Peterson 

Yeah, I can see now where you guys enforcing what is a generally accepted best practice is that has a lot of value. I think obviously there are some companies that probably get the optimal workflow for these legacy PLM systems. Somebody has figured out how to do it right through making tons of mistakes and years of experience. But that knowledge is so tribal.

There's probably two people that know how to do it right in a company of 10,000 employees. And so how do you get that knowledge out to the broader world? There's no way, right?

Michael Corr

Yes.

Yes.

Michael Corr

Exactly, right? And that's what we were seeing was there were just so many companies, not to their fault, were just making uneducated decisions that were leading to production mistakes. And that was Duro's motivations. How can we help that market? How can we help that community take the burden of trying to figure out how to set up their configurations off their plate and onto Duro?

So they can trust us, they can use our system to get started. Later on, know, has the flexibility and extensibility to add more complexity to it as you wish. But the point being is you don't have to do that to get started. You can start with simplicity and grow and add the complexity as your own experience, you know, matures or even as your own product requirements and team requirements mature.

Zach Peterson 

Okay. So I think that's one of the big differentiators about duro is, kind of, you know, enforcing these best practices and not allowing people or not giving enough, enough rope to people to hang themselves. What are some of the other features in duro that make it really different from the legacy PLMs?

Michael Corr

Yeah, exactly.

Michael Corr

Yeah, so that's a great question. You know, one of the advantages of a unique opportunity that we discovered, know, shy of a year ago was so first off, there was in a great way, the hardware community was rapidly evolving at a faster clip than I've ever seen in my 20 plus year career.

not only were more and more hardware companies entering the market, you know, in certain segments like robotics and aerospace, but there are more and more software for hardware companies entering the market as well, you know, offering complimentary products to Duro. you know, it takes a village to build hardware, right? And Duro has no intention of trying to solve every problem. We do what we can, we're where we feel we can provide value, but there's other companies that are entering the market that are taking other pieces of that pie and helping our

and customers, you accelerate and improve their own product maturities. And so with that, there's so much innovation that was happening in the market and so many other ways to handle data and to create what's now called digital thread.

On top of that, SaaS technology itself just evolved so much in the six years since we've started. And then the third ingredient being AI now being very mature and obviously a necessity in your product, not just AI capabilities to your customers, but using AI to build your product yourself.

And so with those kind of ingredients, mix of that, we know about nine months ago, we realized, Hey, there's so much more we could be offering to the market than this very restrictive opinionated product. And so we did, you know, we did a little soul searching and we did some major refactoring to our platform that while it still continues on that philosophy of offering simplicity and out of the box capability, it's really meeting where we feel the hardware community has evolved to.

Michael Corr

And what I mean by that is in a good way, more more hardware companies today have the in-house software development skills, whether it's electrical mechanical engineers themselves who are now very competent software developers or just within the larger engineering team. And we're seeing culturally a difference where more hardware companies want to build their own software tools or their own tech stocks, much more so than I've ever seen in my career. Historically, that's been well,

to third parties or consultants to do that. And so with that in mind, we've really revisited how we offer our platform, know, making much more API forward. We offer, you know, at different levels, there's still very intuitive user interface to configure your account, but we offer, you know, even like a low code interface using YAML, which is an industry standard file format that allows people to even more power.

Right? Through text-based configurations, you can implement things like infrastructure as code.

which is another tried and true methodology adopted from the software industry. We also offer a low level GraphQL API, which is completely extensible. Like everything in our platform is available through our API. So customers can configure an interface to their Dura platform however they wish. know, while we do try and provide a lot of out of the box capabilities and integrations with CAD and MES and ERP products, there will always be, as I mentioned earlier, there's always be some new product entry in the market that we're not aware

of or just don't have the resources to build integrations for, great, here's our API, here's our SDK. The larger market now has the appetite and skill to do their own in-house configurations and extensibility through software. And we want to meet that market where it's at and give them the tools that they're asking for. And so those are some of the advances that we've done that we haven't seen in other PLM providers.

Michael Corr

And then on top of that, we have underlying AI capabilities, right? So using AI natural language to do advanced searching within your library, which is historical problem of not being able to find parts and assemblies in your library.

Using AI to analyze your own change orders and all the iterations you're doing to be able to create insights and reports on that. There's a lot of great content when you submit a change order and it's commented on, it's rejected or approved and any kind of downstream effects of that change order. There's lots of great information that you can learn from using AI models to then leverage for reporting capabilities or to do future analysis of subsequent change orders or issues.

And then on top of that, supply chain integration has been a paramount of Dura. We've always been very bullish on pulling in supply chain resources much earlier in the design cycles to remove that legacy separation between the design team and the procurement team.

Often, historically, the design team will design a product, a mechanical or a PCBA, but then the procurement team says, I can't buy this for whatever reason. And so has to go back to the drawing board and you make an iteration of your design just for procurement purposes, not for functional purposes.

But by leveraging advancements in supply chain technology, Nexstar and Octopark being a great example, you've made it so much easier for the design team to access supply chain information, part of their initial iteration cycles. So now they can do functional design requirements on top of procurement requirements in one iteration.

Michael Corr

so that when they release it to their production team, there's a much higher probability of meeting both functional requirements and procurement requirements. And so these are some of the advancements that DURRO has added that we feel really differentiates us from the legacy providers.

Zach Peterson 

So there's a lot there, but I think one way to summarize kind of what you can do with with duro is to maybe describe it like this, right? You could take duro using some standardized schema for your APIs, right? You could plug this into your MRP, let's say, and then you could also have it pull in data from maybe a proprietary system that the company has running on, I don't know, running on their VPN or something like that. You can take that, bring all of that data into duro. Duro can then

output the data to MRP or ERP or whatever the other system is to then execute on that design once it's released for production. And it kind of streamlines that whole data flow from one team into the design team and then out to the manufacturer.

Michael Corr

Yeah, that's a great summary. And to add to that, another way to simplify it is, DURAL really is the sole purpose is to centralize and revision control your bill materials, your BOM. And the one unifying element across all teams, all aspects of a hardware product is they all need access to the bill materials. And whether it's in the design team, procurement team, or manufacturing team, they either create a bill materials from CAD or whatever it may be.

Zach Peterson 

Okay.

Michael Corr

they augment it, adding supply chain information, or they consume it for the manufacturing site. So any tool that needs to access the bill materials can and should interface the Dura platform.

Right, use Dura as that centralized bond management capability. And while we offer again, some features in each of those segments, we don't plan to or never will be able to keep up with all the features and functionality that people will want to provide. And so that's why we have this more of a platform than an application approach, letting people build on top of our system, as long as they're using us to be that central reference for the bill materials.

Zach Peterson

Sure, sure, yeah. So you have the one single source of truth for the bill of materials. It lives on duro. And these other systems can feed into it, which might be a proprietary system, or they access it, whether it's a procurement system, something like this. So one thing you mentioned earlier is the configuration challenges with legacy PLM systems, and that they are notoriously tough to configure.

Michael Corr

Exactly.

Zach Peterson 

And of course this results in 10 different people doing it 20 different ways. they're all wrong, right? So how does Duro simplify that part of it? If you onboard a customer, how does Duro and maybe how do you help them get through that configuration process quickly and accurately?

Michael Corr

Yeah.

Michael Corr

Yeah, so a lot of it's still rooted in that philosophy of keeping it simple, you know, start with the fundamental requirements first and intentionally keep it a little restrictive. So by offering out of the box capabilities, again, we do provide integrations and plugins for the more common products that our customer base interfaces with. Having that very simple and intuitive user interface to be able to then configure.

these integrations, these systems. And then the next layer being the YAML or the API accessibility, and it gives people...

empowers them to do it themselves as they wish, right? Either at the very high level UI, the mid level, the low code YAML, or like the bare bones, like, you know, through the API itself. And so it allows us to meet the customer at their own skill level and their own interest level and always putting the simplicity first really helps make the onboarding process much simpler, much faster, and to be honest, much more enjoyable.

Zach Peterson 

Now you mentioned one thing earlier, which I haven't gone back to yet. but I think you did set a record for recent guests, which is AI was not mentioned until 14 minutes and 55 seconds into the episode. but you did bring up AI and I do, I do want to get into, how, are you using AI? And, and I think another related question is, you know, you brought up the YAML for the configuration, which is text-based. That sounds like something where AI could play a role to help you do the configuration.

Michael Corr

I did.

Michael Corr

Exactly. Yeah, there's levels to that. I think any founder, any product, SaaS product today needs, like it's without question, AI has to be part of the equation, right? If they're not thinking about it one way or another, they're not going to be a successful company.

And there's two sides of it. One, how are you adding AI features for your own customers within your product? But also how are you leveraging AI tools to develop your own products yourself internally for your own process? And so obviously we embrace both sides of it. Certainly on the latter case, that's much simpler. As we all know, there's dozens of AI tools these days to help with creating content for reviewing content.

whether it's marketing content, sales content, or source code, there's been advancements that have been incredibly powerful and capable to help us move much, much faster than we've been able to before, which is also one of the catalysts and enablers for us to do this major refactoring to our platform that I mentioned earlier. Without AI, don't think we'd be able to do it in the pace we were able to. Customer facing, AI, I feel, is...

the perfect, literally perfect fit for PLM. And the reason why is, you PLM, as I mentioned earlier, by definition is the aggregation of multiple data sources. You have electrical, engineering content, mechanical, procurement, manufacturing. And each of these, excuse me, each of these products have their data in their own format, their own vernacular, their own.

even culturals who process that information. And historically, in order to get it into a PLM system, you've had to do some type of integration and transposition of that data to normalize it into your PLM product. So it's consistent, or consistent enough that you can make sense of it. You can process it through machine learning or any advanced algorithms. The unique thing about AI,

Michael Corr

is that AI can handle data in its native habitat and its native format. And so you don't need to do that transposition for it. It can do it for you. So as long as you create that digital thread where your AI models can access each of those bespoke data sets, it can do the analysis and transposition itself for you. So greatly reducing the cost to add data into your platform.

You just have, again, have to have that digital thread that account credibility, to be able to communicate between the two systems. But then once that's established, AI models and tools can access that content and either leave it in its respective repository or transfer it into a central location that's moved either way.

but then it can build value on top of that at a fraction of the cost and a fraction of the time. And that premise is what we really viewed the lens of how do we add AI to our platform. And so that's how we approach all the features that we offer is how can we leverage AI to be able to process and create insights out of customers existing content.

Zach Peterson 

So I think that opens some opportunities for things that are really specific to the hardware space that you wouldn't necessarily see in something like software development, right? With hardware and of course with manufacturing of physical products, we have like DFM, for example, right? AI used for DFM I think is a big opportunity that is grossly under investigated. There are probably some other directions you could go like EMC.

or possibly even some optimization with supply chain. Do you see those as realistic opportunities for AI, whether it's inside of Duro or proprietary system that pulls the data from?

Michael Corr

Ideally.

Michael Corr

I do. you know, referencing some of you said earlier, the hardware industry is plagued with these pockets of tribal knowledge.

And whether it's in the factory, whether it's in design team or wherever, and historically it's been difficult to transfer that tribal knowledge into like a digital means or medium for others to learn from. again, AI is perfect. You could train a model on all these changes or recommendations someone made specifically for DFM, right? You could go through reams of PowerPoint slides where people are marking it up, change this draft angle so we can, know, the tolerances will be better.

or move these parts of the PCBA so that will be better for the reflow. Whatever it is, that information historically has just been captured in people's heads through conversations or just on notes on PowerPoint. And so as long as it's in some text space or some visual medium,

train the AI on it and it can build its own recommendation engine to then feed back into the design cycles. And so DFM is just one great example where you can leverage AI to transfer that tribal knowledge into something that is meaningful, that is actionable, that people can benefit from immediately.

Zach Peterson

So another thing that you mentioned earlier is you're pulling from some of the Altium data using the Nexar API and Octopart. How are you using that data and how does this make Dura a more unique option for hardware engineers compared to some of the legacy systems out

Michael Corr

Yeah. So again, because of my experience as electrical engineer, I immediately saw the value of Octopart and how it can help electrical engineers through PLM.

You know, I myself spent countless, countless hours when I was procuring, you know, parts and building my circuit boards, having, you know, my Excel spreadsheet open on one side of my monitor and my digit key and arrow website on the other side of just browsing for parts, copying, pasting, you know, the specs, the part numbers, the pricing, whatever I could into my bill materials management tool. And I was like, this is a complete waste of my time.

It's inefficient, it's prone to error. And if I give this task to my whole team, they're all gonna do something different, right? Everyone's gonna grab different information from Digi-Key because what's important to them, so it's very subjective. And so again, going back to that uniform package you give to your contract manufacturer, you're gonna get a download of inconsistent information for supply chain, for electrical parts.

And when I discovered Octopart, I'm like, this is brilliant, right? So why don't we allow customers to just put in a manufacturing part number in their PLM and leverage things like Octopart to do all that dirty work for them. And so the value it provided was through Duro, a customer, you we don't help them find the specific part.

per se, but once they've found it, they just put in the manufacturing part number and then we, through Octopart and XR, can get all the published information about it, you know, automatically. So now not only have you removed that time, right, from hours to milliseconds, but you can establish consistency or some standardization so that no matter which user on your team is doing this operation, it's always going be the same data that gets ported into your PLM system. And

Michael Corr

with those link backs to the original source, it's also trivial to do price and lead time checks, right? That also was a very onerous task. You know, I remember in my career where during my design cycles, you know, I'd look on DigiKey, yeah, this part's available, it looks great, I'm gonna pick it, put it in my bill of materials, but...

Normally weeks would go by before I would do my design the board and when I actually went to procure it and at that point the part wasn't available in best case you found a package compatible alternative But there are many cases where I couldn't I had to go back to my circuit board design and change the the layout The footprint layout because it was an incompatible, you footprint and again complete waste of time And so now with tools like octopart with just a button

or some automated reporting technologies, I can find out again in seconds, is this part still available or do I have to make an iteration change to my board, saving a lot of wasted time.

Zach Peterson 

Yeah, you mentioned the, you know, DigiKey on one side of the screen and the XL on the other side of the screen. I can't tell you how much time I've spent in that view on my laptop and wanting to throw my laptop out the window as a result.

Michael Corr

Yeah. Yeah.

Yeah, again, it was not the best use of time. And again, that is exactly what software should be used for, right? For data management.

Zach Peterson 

Absolutely, absolutely. So you've listed a lot of things that Duro can do and that people can do with Duro. And one aspect of procurement is of course getting the components. But I think one thing where, or one area where procurement has, I guess, of struggled is procurement of bare PCBs. Is there the possibility for Duro to be a tool that can help with procurement of bare PCBs?

Michael Corr

Absolutely. That too, we've always been very bullish on the forthcoming evolution of the whole supply chain market. And so I'll give credit where credit's due. mean, it did feel like the electronic parts distributors were.

ahead of the curve and making their catalogs not only very clean and powerful websites, but accessible through APIs. then companies like Octopark made that even easier for developers to access. Catalog parts is pretty trivial to do that, and chemical industry is also starting to do the same.

there was a lag for contract manufacturing or custom manufacturers to do the same, but whether it's mechanical or PCBAs, but we've over the last certainly three plus years seeing more and more suppliers come online and digitize their services through quoting and ordering processes, right? So now there's an

there's dozens of them, both on the mechanical and electrical, you can upload your Gerbers, you can upload a CAD file to these systems. Within seconds, you can get an immediate quote with different options of materials and sizes and lead times.

And then you can place your orders. so Dura has always been at the ready for when that market would be there. And so in our backend, we've made what we call the DBI, the Dura vendor integration engine that allows as these markets or as these providers come online and they have an API, they can truly add their resources to Dura. And so now again, it continues that digital threat. So as a user creates or updates their CAD,

Michael Corr

uploads it into Duro, they can immediately connect it to any of these providers and get custom quotes and even place orders continuing that digital thread.

Zach Peterson 

That makes a lot of sense. Yeah, I see a real simplified workflow where, you you commit it to the PLM and then you just click a button, quote PCB, you get a price, quote parts, you get another price. You've now done what would normally take hours in, like you said, in milliseconds.

Michael Corr

Correct. the other subtle but important layer on top of that too is while many of these custom suppliers have very powerful and capable web products,

there's still an air gap between those products and their PLM, right? There's still an operation where someone has to download the CAD file from their PLM and upload it into these marketplace products. And then vice versa, once they get a quote, they have to copy that quote back into their PLM for other people to access and see it. Again, manual process, that software can do much better. And so by connecting them from Duro to these platforms, you remove that man in the middle,

remove that what I call private conversation. And so now anybody, they don't have to have an account with one of these providers, just the Dura platform has has authorization to connect to it. Anybody in your team can select any CAD file that's in PLM, and then get a quote and pull that information automatically into the platform for everybody to have access to.

Zach Peterson 

Excellent, excellent. So we're getting up here on time, but I do have one more question for you before we wrap up. And there's been so much that you've talked about what Duro can do and what people can do with Duro and what they can build with Duro. But I'm wondering, beyond the things you've talked about so far, what new features do you have planned for Duro or do you kind of see far off in the future for Duro?

Michael Corr

Yeah, so we've always...

Again, we like the underlying theme of Dura is how can we centralize the bill materials? How can we make the creation, editing and consumption of the bill materials as simple and automated as possible. And we've started with the design teams, but we feel that's where the data really starts in this kind of domino ecosystem of data management tools. But as we've evolved and the markets evolved, we've gone to the next segment, which is the supply chain, you know, the tools that we just described.

And ultimately it's a manufacturing, right? So we're seeing more and more demand from our customers. They love how we make the simplicity of creating the bill materials in They now want help from Dura to help manage the manufacturing of their parts. And that in conjunction with whether this is anecdotal or this is a larger actual change, but I'm seeing more more OEM companies bringing their own manufacturing in-house. Certainly in aerospace and certainly

market categories. so with that in mind, I'm seeing more and more interests in OEMs, hardware companies to procure their own manufacturing capabilities.

versus just leaning on contract manufacturers. And so, Dura is just, again, it's once you have control of the bill of materials, it's very easy for us to go horizontally across the whole ecosystem, from the design all the way manufacturing. So the customer has that consistent experience from design all the way to manufacturing.

Zach Peterson 

Absolutely. Yeah, I think that makes a lot of sense and you've mentioned OEMs maybe making their operations more captive. I actually also see that as a trend. So it's good to hear that you guys are going to be there to service that part of the market. Well, Michael, thank you so much for being here today. This has been a huge learning experience for me because PLMs have always been a bit confounding as you have described so eloquently. So again, thank you so much for being here and talking about all this. And I hope everyone will.

Go check out the Dura website. Where can folks go to learn more about Dura and possibly connect with you or even get a demo?

Michael Corr

Yeah, the easiest is to go to our website, getduro.com. From there, there's a handful of videos, product landing pages, customer testimonials, and obviously through their website, you can reach out to us to schedule a demo or connect with me.

Zach Peterson 

Excellent, excellent. Thank you so much. To everyone that's out there listening, we've been talking with Michael Kaur, CEO and founder of Duro. If you are watching on YouTube, make sure to hit the like button, hit the subscribe button. You'll be able to keep up with all of our podcast episodes and tutorials as they come out. And last but not least, don't stop learning, stay on track, and we'll see you next time. Thanks, everybody.

Michael Corr

Thank you, Zach.