📍 Have you ever had an idea for a physical product that you just knew had the potential to change the world? Maybe it was something you dreamt up in your garage or a solution to a problem you encountered in your daily life. Whatever it was, you knew it was a winner. If only you can turn that idea into something... You are not 📍 alone!
Countless entrepreneurs and innovators have stood exactly where you stand filled with passion and drive, but unsure of where to begin, and that's where "The Builder Circle" comes in.
My name is Sera Evcimen and I'm a mechanical engineer, hardware enthusiast, and hardware mentor. I've had the privilege of working with numerous hardware companies that are passionate about solving some of the biggest challenges in the world. And I will be your host as we explore the exciting and complex world of physical product development.
All right. Welcome to the Builder Circle.
Today I have Matt Lipsitz with me and we're going to be talking about quality. And that's a really broad term that I just threw out there, but we're going to get into the details and how it could be applied in the startup world.
But before we start I just want to say thank you so much for being on the show. And I'd love for you to give a little bit of background to our listeners so that they know who they're listening to.
Sure. I am a mechanical engineer by training. I finished school and wanted to combine my love of theater with engineering and I went to work for a company that built scenery for shows and Broadway and automated that. And I left that industry to go back to school for manufacturing, engineering and business and then worked for a company that did automation machinery for manufacturing low speed, but high precision and eventually moved to Keurig Dr.
Pepper, where I spent 9 years doing everything from machine design to developing the recyclable pickup pod, So to test engineering for Keurig appliances. And I left that around the start of the pandemic to go work for really another appliance company, Formlabs, making 3D printers. And I'm now responsible for quality and sustaining engineering.
Form labs, printers, our hardware.
That's excellent. That's such a swath of very different industries and it seems like also just experience and very different parts of the product life cycle from I know the quality can encompass testing quite a bit, especially when you go into kind of the verification validation loops but that's super cool.
And it's really awesome to have people that have this kind of swath of experience to talk through different types of products because not sometimes even though general practices can be applicable to many, there's still some specifications that come with the different products. So thinking in that way is really, , valuable and I'm so excited for you to be on this episode to, talk about all of that and specifically in the quality realm because that's what you live and breathe right now at Formlabs from what I understand.
Okay the, I guess the biggest question that we start off with is what does the word quality mean for a hardware company? And at a high level, what does it take to realize it?
Yeah. When I think about quality, I really want to start with what does the customer expect out of the product that the company is trying to make and meeting customer expectations is really the baseline of defining quality and a company that's delivering a quality product. Maybe meeting expectations in the areas where the product features that they're trying to deliver.
So that could be things like building a reliable product, building a product that is easy to use may hit a certain cost target. And then from there, building on that, delivering it consistently to every customer. And a lot of what I work on right now is thinking about. Reliability in both operational execution and manufacturing and also in field performance.
And does the product last as long as expected? And does it perform adequately through that length of time? So that's. My starting point definition of quality
yeah. So there are there are a variety of ways to approach quality, but it really comes back to mitigating risk. And when I think about risk, there are a few different sort of phases of the product life cycle where a company can impact. The quality and impact the risk of not delivering to customer expectations.
It really starts with the design and conceptual phase. And thinking through I've got this design. How could it go wrong? How could it fail? The tool that's most often used there is failure modes and effects analysis, which is really a way to quantify the risk in terms of the severity of the risk, the likelihood of it occurring and the ability to detect it in some process.
And risk management is really what quality is all about. Either managing the risk that the product doesn't meet customer expectations or managing risk of cost and schedule and product performance through a, an MPI cycle. And then as a, as you get into manufacturing the products. In my experience, quality is about preventing failures from getting to the field and doing everything you can to catch those issues that detection part of the FMI.
A to catch things before they get to a customer. But of course. You can never catch everything, and there's always a certain reactive part and part of what I've been part of as a quality leader at Formlabs is going from the reactive space where we're doing everything reactively as customers see issues in the field to a more preventative and proactive space where we're trying to minimize the impact.
Of issues and or minimize the existence of those issues, the probability that they occur through manufacturing controls or design controls. And that transformation, I think, is 1 that many startup companies go through as they go from just trying to get a product to market to getting a product to be built consistently with high quality and at volume.
That I really appreciated how you weaved the perspective of quality into multiple stages of the product lifecycle really from, all the way from the conception of it. To testing to launch and to scale. And I think it's really important because oftentimes Quality assurance or control feels like something that companies can think about after product launch or after, we've gotten through this hurdle of developing our technology and we feel better about it.
Or, oh, that's like in the sustainment era, like we'll deploy those later. And I guess I would love to get your. Thoughts on that because I feel like it isn't top of mind immediately. I, people know they have to do it because there's like even unit economics that sometimes depend on it because especially you were talking about kind of the difference between Quality and the design phase and quality in the manufacturing phase, which we'll talk about the difference later.
But when it comes to manufacturing, if you don't have a great yield, then your unit economics start really working against you. And it really starts to from a startup perspective, get in the way of this kind of product market fit hypothesis that you're trying to prove and potentially even the the survivability of your product in the field.
I guess all of that to say is, what are your thoughts on when and how to apply the right level of rigor when it comes to different stages of a company maturity and a product maturity?
Yeah, I want to speak a little bit to the challenge that you mentioned a moment ago before I fully answer that question because. In my head, the thing that drives quality first and foremost is knowing what you want in terms of what you want out of the product. And if you're a design engineer, often that comes back to drawings and specifications and really defining product performance.
Test engineering, you're measuring that product performance and validating it. And so to deliver quality first, you need to know what is quality, what is, what makes this product high quality or adequate quality. And so I think that's a big challenge for folks who are really starting early in their technology development and don't necessarily know what good is yet.
And there's a lot of work that needs to go into defining what is the product that you're making, what are the features to develop, what are the attributes that you want to deliver to the customer and the value that you want to deliver to that customer. And that's an evolution. It's, you never really know out of the gate and the projects that you really do know that out of the gate are pretty low risk projects.
In my experience. When I've been able to write a specification on day 1 and know exactly what I want out the other end, there's pretty little risk and it's not hard to get a good quality product out. But when you're building the train as you're building the tracks and it's rolling down.
The railroad at the same time, it's a lot harder to define that that definition of quality, but that's really important. And as a company begins to build a 1st generation product. And define what they want, it really comes back to being diligent about that definition. And it could be in it could be in written specifications, it could be in drawings, it could be in building prototypes. Yeah, so applying the right rigor early in the life cycle is about defining. What you want in specifications and then finding ways to document what you want and transfer it to whomever is going to build it. So early we talk about product life cycle management or documentation control where you're.
Revision controlling design documentation, and that makes it easier to transfer that knowledge to whomever is going to make it, whether that's a outsourced manufacturing partner or it's internal. And so that is 1 way to communicate. What you want as a design engineer or as a company and ensure quality.
And then the next piece is how do you measure that? You got what you want because that's. Critical to knowing that what comes out the end of the manufacturing line or what the customer receives is going to be good. And there are a few different ways to do that. In my experience, I've worked on test engineering.
So thinking through. Again, how can the product fail? What can go wrong? And then what are the different ways it can fail and testing across those different regimes? So it might be different environmental conditions or different types of let's say electrical power voltages or low voltage different different frequencies.
And that's going to be very much dependent on the application. Thinking of the end user the customer, right? Where are they going to use it? How are they going to use it? What could they do wrong?
Yeah, totally. And more often than not, it's the ways the customer misuses the product that are the surprises and that are hard to anticipate. And, I remember hearing a story about someone putting all different types of alcohol in Keurig brewers. It's not meant for alcohol, but that's an example of.
A time of a misuse that really wasn't anticipated and could be problematic for the performance of the product. And so sometimes those surprises are funny and fun, and sometimes they're frustrating. Working on 3D printers, it's a pretty complicated product. So we find user education is really important to using it right and getting the best performance out of the printer or out of the whole workflow.
We make multiple products, including materials and post processing equipment. So to get a good quality print, you really need to understand that workflow and process, and you need to understand, the best conditions to operate the system. So things like temperature and humidity become really important.
The age of the resin may be important or the incoming electrical power quality to make sure the printer isn't varying its power and maybe dying in the middle of a print. Typical types of problems
I'm so the I guess what I'm trying to get out with the question is when people are working in startups, either as a mechanical engineer or a technical lead, or an electrical engineer, they're looking at. The beginning of the life cycle and they're in the technology development phase and going from that technology development phase, you're talking about what we touched on this, like proactive versus reactive quality I guess action.
And I feel like there's really good bits and pieces that people can do actively now when they are in the design phase, which you alluded to of just having really good requirements, going back to them, making sure that they have validity with the end user and the customer. And then also, once you design it to test it so that you are getting close to those requirements, or at least knowing how close you're getting.
In my mind, that's how I think of proactive, but were you thinking of something along those lines of just like that is the proactive piece of the puzzle and then reactive is what actually happens in the field?
Yeah, you're right. The most impactful proactive work happens in the design phase and the design validation phase before that product gets to a customer. And it's also the least expensive place to impact quality. The earlier you can. make a difference, the better. In theory, everything, every product can be designed right the first time, and there are never quality issues.
But that's never really true. The second sort of phase is in the new product introduction cycle, ramping up manufacturing, and then once into mass production. Trying to find those control points in the manufacturing process where you can catch issues. And again, I'll come back to that risk assessment tool where you're thinking through, how do I detect that an issue is happening?
And ideally, it's not detected at the customer. It's detected long before the product gets to the customer. Because once again, the earlier you can detect a product failure, the earlier you can Mitigate it and the less costly it is in the end. And so some of quality is about quality control and thinking through in a manufacturing space.
Where can we catch issues? So maybe supplier 1 is making a part. It gets assembled at supplier two into a subassembly, and then it maybe it even goes into supplier three to be put into a finished good packaged and shipped to a warehouse. Each of those steps is an opportunity to catch quality issues along the way.
And ideally, if the individual part has an issue, you catch it at that first supplier before it gets to tier two and and tier one. At this at the finished good manufacturer. So a lot of quality controls about thinking about what is really important to me because you can't measure everything.
And then where can I catch that really important thing as early in the process as possible? So we. May implement things like outgoing quality control inspections. Some percentage of outgoing parts is inspected for critical to quality dimensions or features. And then the supplier issues a report to say, this batch of product is good and it goes to the next step and do a similar type of thing.
And then secondarily, there's often outgoing quality control inspections. So that could be testing. It could be some sort of. Measurement or just a visual inspection to make sure cosmetics are good, or that could be even a functional test to operate the system. And these are all really control points that manage the risk of a quality escape before it gets to a customer.
Then on the most downstream side, there's the reactive quality space. And that's, of course, very costly. And oftentimes you're reactive because a customer has called your customer service team and said, I have a problem and I don't think the machine's supposed to work this way. Help me fix it. And by that point, you've got a brand integrity risk because now the brand is threatened by this customer who's unhappy.
The customer can't do what they want to with the product. It's not working as intended and you have to react to it. And often that takes time to troubleshoot and figure out where the issue came from and then to go and fix it. So for example right now, if I want to make a change to a hardware product.
It may take a couple months for that change to cut into manufacturing because we need to go through some amount of in work in process inventory before we can cut in a new part that gets assembled onto the product, it gets packed and shipped. It could take 3 months to ship by sea over across the world, to the U.
S. and then eventually get to a customer. So it could be 3 to 6 months. Until a customer sees that change. So sometimes reactive quality needs to be faster and we need to deploy things like customer replaceable parts or field service technicians or a software update that'll patch fix the problem.
So fortunately, there are a lot of levers to pull that can solve these things. But I think in the the reactive space, they're very costly and they cause, engineers, you got to pull engineers from their day jobs, designing the next product to go fix the issue the issue from the product that's already in the field.
Definitely. And I do have to make a I guess a shout out to you for like truly not only talking the talk, but walking the walk with this one because I was at a previous company and I actually, we had some small issues with our Formlabs printers and I had met Matt beforehand and I just.
LinkedIn messaged him saying that we were having a problem and they directly swung into action and helped us and fix the issue almost within a few days. And it was excellent. Although we try to avoid the reactive quality it's really nice to see companies when they actually do follow through with fixing the issue.
So I'll give a little bit of a, Formlabs for that one.
Thank you. It's, that is definitely part of our product. We've chosen to make customer service a priority, and we want customers to have a good experience and make sure the product is working reliably for them.
Absolutely. So you mentioned so many valuable things throughout throughout the entire tasks that take to get a product out and successfully implemented with customers and continued on with brand integrity.
One of the things that you mentioned was quality control and obviously quality control has many. different ways of doing it. And you gave some really good examples of that. One of the things that I guess I would be curious to know your take on is oftentimes. So there's two scenarios that startups could potentially face when it comes to building their product.
They could be internally manufacturing it or they could be outsourcing it. As you said, they could be going through this kind of supply chain or supplier chain more so where a different subcomponents or subsystems get assembled somewhere else and then the entire system integration happens somewhere, which is I think one of the most complicated or it just happens at a contract manufacturer or it happens in house.
So my question is. When it comes to quality control, how do you approach it when it's internal versus external? And I guess what are the differences and how can you communicate that effectively?
Yeah, I think what you're describing really comes down to one of the hardest things to do in product development, which is transfer a product from the people who have designed it, who are the creators and ideated the product to the people who manufacture it. And even if it's in house.
It's hard because knowledge transfer is hard, and we keep so much in our heads, it's hard to externalize that knowledge and write it all down so that somebody else can digest it. And there are certainly tools we use for that. I've talked about drawings and models and other things. Fortunately, when it's in house.
It's a little easier because theoretically everybody's working for the same company. There's hopefully a common culture. It's easier to go to the site where the product is manufactured because you don't need to jump through quite as many hoops. But when it's outsourced, the importance of externalizing that knowledge is so much greater.
And quite often you're dealing with cultural differences. So much is manufactured in Southeast Asia, but designed in the United States, or the company is based in the United States. That's a huge cultural time zone and just a day to day behavioral difference in, in Needing knowledge transfer that those are hurdles that just get much greater than transferring knowledge within a single within a company.
In those cases, I think, come back to defining what you want really specifically and then there's a 2nd layer. Where you really need to work closely with the supplier sometimes be on site with them to help realize what you want, because there's so many times when just a phone call or an email doesn't exchange the information quite enough, and there are nuances to the manufacturing process or the limitations of that supplier capability that you just don't get when you're virtual or far away.
And so that's where either having people on site who can be a company's agent to help transfer that knowledge or going personally and traveling to the location where it's being made makes all the difference. And, that applies even in a vertically integrated company where you're making it yourself.
I saw that. At carry Dr pepper in a few different ways, there was vertical integration for some of the consumables and the pods and going to the manufacturing site helped me understand the limitations of that manufacturing. And then the appliances remain in Southeast Asia with the contract manufacturer again, going there made all the difference to transferring knowledge and transferring activities.
We spent a lot of time moving testing from the U. S. to Asia, and we had to be there, be on site, and have additional people from our company on site to help train the technicians on how to test and how to assemble the product.
Gotcha. And do you feel like, and I, it's okay if you haven't really had the experience of this, but oftentimes what happens with a lot of startups is that they end up working with suppliers that care as much about their business because it's a drop in the bucket for them because startups start with very low quantities.
Do you feel like That is, that could still be possible that just like site visits and keeping a close pulse on the quality. Is that something do you feel like suppliers would be open to?
Yeah, absolutely. I think that any supplier relationship is a partnership, and it's a partnership that both parties need to invest in. So a supplier needs to be invested in making the product and making it well, but you can't always expect them to know what good is unless you teach. And then there's a certain amount of verification needed.
And quite often being that face to face person on site shows an investment in the partnership and an investment in understanding the challenges that supplier is facing so that you can work through them together. And I think that's really the key to successful quality. Is being a sort of imagine arms locked and charging down the aisle together to go build something.
That's how it needs to be. Is that meet in the middle of a partnership of part supplier bring certain expertise for how they know how to do things and customer brings expertise on what they want and how to make the thing or what they want out the other end of the line. And together they go and build it.
And then make sure it's good. And I think even with early startups, that sense of partnership and finding the right partner is so key. Because otherwise I don't think you really can deliver quality. You can't always expect that the supplier knows what you want or can deliver it. If they don't have experience with it.
That makes sense. And I guess I, I want to also ask your opinion on dealing with a potentially sticky situation where your supplier or your integrator or your contract manufacturer, somewhere outsourced is not really performing well, where the, maybe the quality is okay, but the yield is very low, or the the yield is, in their mind, great, but it's because their understanding of quality is off.
What steps do you go through to either mend the situation, or like, how do you let go? When do you know to let go of a supplier and potentially go somewhere else?
There are certain sort of typical tools for telling a supplier that something's wrong. You can use tools like corrective and preventive action documents that sort of say, Hey, there was a problem in the field. Please go fix it. Here's where the problem was. We want you to go troubleshoot, but that turns into something very transactional and it assumes the supplier can go fix that problem.
Now, if it's something that a manufacturing partner should be able to do, manage inventory or clear a line after a production lot, so that you don't get mixed and matched parts that kind of thing usually can be transactional, but if it's something a little more nuanced, maybe it's the proper adjustment and dialing in the mechanism of a 3D printer and using certain, tools to calibrate.
That requires a little more handholding and partnership and being, often being physically there and present. And at a certain point, you make that investment for a period of time, and if the partner still can't get there, Then you have to decide can they ever get there. And are they, do they have the skills, the talent, the people who can understand what we want as a customer.
And then can they deliver what we want, even if it takes a significant investment from from the client. And if not, then it's time to walk away and find somebody else who can do it. Sometimes the other reasons for walking away are cost. The cost is too high, and it's time to go find someone who can do it for less.
The risk there is often lower cost means less attention to quality and fewer people paying attention to process controls. And so that's a balance too, and often requires a little more oversight, but it can deliver dividends on the cost side.
. If, like, when you get into that point where you are deciding whether or not you're going to continue with a supplier or spin up a new one I would assume that there's a lot of trade offs of doing that because you already have invested in a lot of knowledge transfer with this partner you probably have this crazy demand that you're trying to hit, which is a lot of A very common problem that hardware startups have actually is not the market side, which is a lot of software companies have that issue with hardware.
It's like you have so much demand, but you don't have the ability to scale quickly. So it's like when these types of problems happen, quality is usually the first one to get the get the boot off the boat because they're like, Oh at least we can get something out. And I personally disagree with this because I think your point about, the product and brand reputation is really important and really critical specifically in the early stages. But anyway, all of that to say how do you evaluate those trade offs and have you ever had to make a decision like that? Is there any you don't have to give a specific example or you can give like a made up example of like how a person can how a hardware team could evaluate something like that and actually come up with a decision to?
Either continue with the same supplier and try to get them to to get to the right quality metrics or say, you know what? Nope. We're going to spin up someone else.
Yeah, I have been in that place and I've also been in the place where I've carried multiple suppliers forward in order to try to tease out a winner, so to speak, or one who can realize the right quality or the right features of a product. And sometimes that's the right solution is you need to carry multiple multiple paths, but it can be very costly from a time and a resource standpoint.
So I think it's, I always want to put in a decent investment in trying to build up a supplier and teach them what it takes if I have the know how to teach them what it takes to make this product and give them at least a few tries. But quite often. You get down the road and by the time you realize that they can't do it, you're stuck.
So there are some trade offs there. It really depends on the situation. Sometimes the situation is such that they can make a couple of good parts, but the yield is pretty low. So maybe that's enough to you can invest some dollars in low yield while building up a new supplier and a second source.
But again, that's a time penalty and a dollar penalty. And sometimes it's necessary to pivot much more quickly, which again, often costs time. And coming back to an earlier point, trying to think through these risks, thinking about where am I single sourced? What is really critical to quality and Focusing attention engineering effort and early risk mitigation on making sure those key things are going to hit the mark at least adequately might not have to be 99.
9 percent yield. But, if you can get an adequate dollar investment for a good quality parts coming out then, you've done a pretty good job managing that risk. And I think one of the biggest strategies there is to try to carry a few solutions at the same time and not put all your eggs in one basket.
But you're right that early stage startups often only have a couple of choices, and that's limited. But, thinking creatively about what those options are, maybe building the part in house or the sub assembly in house is an okay interim solution until you can stand up a supplier and transfer it there. It really varies. It depends on the product and complexity. And
with you a specific I mean it really depends obviously on the product because if it's a very complex industrial machine that might not be feasible, or it's better to do it that way again it's super product dependent and I completely agree with that. But I also. Agree with the point that even as a early stage startup, when to be able to do that knowledge transfer successfully, I think you have to be able to build it in house at least once, even if it's an industrial equipment, even if it's maybe it's a, if it's an industrial equipment, you simplify the problem and you build a subsystem in house and you build a subscale prototype where it's not the big thing but a small thing.
That does something similar that you can extrapolate the data and say, okay, the big thing might work. But I really, I personally, specifically in startup world, having the core competency around your product and being your product's main, I guess owner and knowledge keeper is really important because you stress this throughout the entire like questions that we've been answering is that the most important and the hardest thing is to be able to communicate that knowledge, whether it is insourced or outsourced or whatever.
And if you don't know that knowledge, like the back of your hand, you're not going to be able to communicate it effectively, which then downstream will result in low quality. Products. So that makes a ton of sense.
That's not to say that you can't outsource, there may be people with subject matter expertise in certain areas, but you do need to make sure you know what you want out the other end and you can measure that thing.
And if you don't know, I also like making lists of the unknowns. Obviously the unknown unknowns will come out in tests. Like you can't write those down. Hence the unknown. But. Even if you have unknowns that's a really good thing to be able to communicate to an outsource partner because they might be able to tell you what those unknowns should be.
And then that's why I think it's so important to get to a prototype and testing quickly is because that's when you really uncover the ones that the unknowns that you don't know and go from there. It is critical. And. So we're still in the, topic of quality assurance and quality control and all of these things.
I, I'd love to get your perspective on common pitfalls that you've seen in this, in the world of quality specifically when it comes to products and systems.
Yeah. I think a common pitfall I've seen is building some prototypes in an early stage and then making an assumption that those prototypes represent the real world. And the truth is their models, they are good enough to test and prove some concepts and prove out the theory of operation, but it's rare that they represent the full breadth of variation that comes out when you get a product to the field and customers may misuse it, or it experiences different environmental conditions or use cases.
And thinking through, okay, I've got this kind of nominal case, this prototype that is working okay, how do I stress test it and push it to the extreme to understand if it works in these other regimes? And I think that's one of the hardest things to do, and to think through, how can I break it, really?
And what does it take to break this thing? But that's where you get the most learning. I've said it before in in talking about testing, that you don't really learn anything from a test that passes. You learn from tests that fail. And when you're doing validation engineering, particularly design verification it's really all about finding that point of failure where you understand the risk you're taking on or the risk of the product performing or not performing.
And that doesn't mean that failure has to be or always is in a place you don't want it. Sometimes there's plenty of margin for performance but knowing where that margin is and how much you have is really key.
Yes, I would agree when I think about some of the products that I've worked in, that's definitely been the case. I think one of the common pitfalls, and we've nailed this multiple times throughout the conversation is really not thinking about where to implement quality control.
I've I've seen a lot of entrepreneurs Just assume that the because it just because outsourced supplier is the subject matter expert in something. It doesn't mean that the quality metric that they're going to produce something is going to match what you need and what your system needs. And there's sometimes just this inherent assumption that it will.
And I think The biggest thread that I'm picking up from our conversation is that it's so important to understand your quality success criteria and not assume that people will hit it.
Yeah, you're totally right. And also, not assume that your supplier understands what really is important, because as I said, you can't measure everything. So you need to focus on the things that are truly critical. Hopefully is just a handful of things and then make sure that's what the supplier is spending their energy doing is looking at those things and understands how to control them and how they can go wrong.
And just assuming the a that the supplier understands your product or be that they know how to do QC is certainly a pitfall. And so trying to be. Maybe not overly prescriptive, but help that supplier understand what's really important and then partner or collaborate on how to realize it.
That's a really important thing for getting the thing out that you want to get out.
And honestly, this is just a note on this once you have a little bit more thought put into and this is to support entrepreneurs to implement quality earlier on is once you have that kind of sense of quality control, you start to like enforces better Practices in your product development.
And so you have better documentation. You have a better understanding of success criteria. You potentially have a really humbling experience of how much you are not aware of, which is always a good thing. And then what that causes you is to prepare better for supplier engagements. Because I do see a lot of companies also just tumble into these supplier conversations because and get Multiple quotes, or re communicate multiple times, and all of these things, and if you can bring that quality mentality earlier on, it'll keep your team nice and buttoned up a little bit more, and then once you approach suppliers with better quality better communication around requirements, better communication around specifications, what they, the expectation is.
You'll be treated differently too, because there's this common thread that startups get treated poorly by suppliers, which for some suppliers, this is true. They want millions of dollars, you're giving them thousands. But It's also the case that you usually the headache is because startups could be unprepared going into the conversation.
So I really appreciate the kind of message of if you bring quality, the mentality of quality early, it not only potentially will not potentially, it will definitely influence your product to have higher quality, but it will also enforce better systems, engineering practices, better mechanical design practices, better manufacturing practices.
And. In turn, have you better prepared for supplier conversations? Do you feel like that's a good kind of summary?
I think you're spot on, and I think you could extend that concept to I'm going to come back to the concept of Customer. The definition of a customer could be the end user, but really every phase in the new product development process has a customer. So the design engineers customer may be the manufacturing engineering team or the supplier.
The suppliers customer is both the the folks who are ordering it, the company that's building the product, And the customer and user and probably also the logistics company and the warehouse company. So there are all these different sort of customer supplier relationships in that cycle.
And so the more you, wherever you sit in that life cycle or in that workflow, think of your downstream partner as a customer and delivering customer, delivering value to that downstream customer, anticipating their needs and meeting them the better and the more streamlined, the more effective, the faster the process will go and the less rework and confusion.
So I think that's Kind of what you were just describing.
Absolutely. I love that. I really do appreciate the fact that the customer isn't just the end customer. You have many interim customers up until it gets to that point. I really like that perspective. So we just talked about how everything can be just like rainbows and butterflies of quality and everyone designs the best product, has the best requirements.
You validate the requirements you've got at a hundred percent 📍 if only.
This episode and podcasts are brought to you by my consulting company, Pratik Development
where every startup receives a tailored approach in transitioning their ideas. Or research and to innovative hardware products. I'm dedicated to helping with strategic execution and product development, scaling manufacturing, and optimizing supply chains to bring your vision to life. I believe that hardware should be accessible and successful.
And that's the whole reason that this podcast exists. So if you value the podcast and you'd like the episodes and you appreciate the insights, please support us by sharing rating and leaving a review on your favorite podcast platform. Your engagement is crucial in helping us reach more visionaries like yourself. Thank you so much for listening and being a part of the community.
So I, I feel like this is a perfect transition to switch on to the absolute polar opposite of what we were talking about and talk about hardware horror stories.
Hardware Horror Stories Segment
This is one of my favorite segments that I like to do with all of my guests.
And I'm, and I feel like in quality specifically, you can get some really funny stuff not to put you on the spot maybe not funny, but interesting. So I'd love to hear if you've ever had hardware horror stories related to QA, QC, some. Quality stuff just going absolutely horribly.
Now the pressure's on for something funny.
I had something prepared. I'll talk about what what came to mind. In several of my experiences, I've run into an issue where something was measured in more than one place. And anytime you measure something in different places you have room for disagreement, and likely the measurements are going to disagree, and that
say place, sorry, just to clarify, when you say place, is it like different suppliers or a different spot on like the mechanical piece?
Yeah, let me clarify you're measuring the same thing in two different physical physical suppliers or physical laboratories, let's say. And that might mean you're measuring with different instruments. It might mean you're measuring with different measurement processes. So you think about a coordinate measurement machine needs a special program.
Those two programs across different locations might be different. And the programmer might have come at the geometric dimensioning and tolerancing differently and interpreted it differently. And anytime you have redundancy in measuring the same thing, whether it's the same feature or the same performance metric on a product, there's room for variation and likely room for disagreement between the values the output of those measurements. And I've seen this multiple times where a contract manufacturer in Asia measures something according to the SOP. They did it right. Their tools seem to be calibrated, but the measurement was different from what we got in the United States at the laboratory at our headquarters and why?
And this causes lots of engineering angst and lots of discussion and concern. Why was it different? Which one do we trust? And so the best practice that I recommend is to have. a single source of truth for measurements, and to qualify those measurement systems to make sure you do trust them.
And if you absolutely have to measure in more than one place, then it's critical to have the same tool and the same process in both of those places. And that's going to avoid so much waste and confusion and that question of which do I trust? Which one is right? Is the, is it out of spec by X or Y?
And when you say just to turn it into, like a practical step that someone could take, say it's a measurement of a, actually like a width of something are you saying you put whatever measurement tool you're using say a micrometer is a terrible probably a measurement tool for mass production.
But anyway, let's say micrometer. When you say like you qualify that Measurement tool. Are you saying you get something that has a known known with and then you use both of those to measure that? And if it's giving the right result, it's calibrated. It's good. Is that what you're talking about when you say qualify?
That
different steps to qualification. This is a good clarification. First, I always want to know, is the tool we're using calibrated? Do we believe it to be accurate, no matter who is using it? Some tools, let's say a caliper or a micrometer, can go to a calibration lab and be calibrated so they have a sticker on them that says, this tool is accurate.
The second step is it measuring repeatably and reproducibly, meaning you measure the same part more than once and it comes out approximately the same. You measure multiple parts across different operators and they come out approximately the same. And so that sort of takes into account the different sources of variation.
And in qualifying a measurement system, you want to make sure that it will measure accurately, repeatably and reproducibly across the full range of expected measurement. Let's say you're measuring something that could be anywhere from 10 millimeters to 12 millimeters wide. The accuracy, repeatability, reproducibility needs to be, good within that full range.
sense. Okay. Yeah. Looking at both the accuracy and the precision continued precision, that makes. That is super important. Did you have any other stories or was that it? That's okay if it is.
Now I'm trying to think. I'm sure I do. Yes. Okay. Some things that come to mind are oftentimes when putting something together and using automated equipment Maintenance of that equipment comes into play. And there have been examples of nuts and bolts inside sealed packaged products that have come back.
And again, I talked about a brand integrity threat. That is definitely a brand integrity threat when you've got a sealed package that is supposed to work. Only have the product intended in it. And it actually has parts of the machine that made it that, that were sealed into the package.
So that's not a good quality escape. You definitely want to avoid those. And that's why a lot of companies put in automated inspection tools to try to catch those things before they leave the factory.
That's awesome. Honestly. I would really love to see that failure mode in action. Just to experience that. It's, for the consumer, you get more for what you pay for, you get some additional nuts and bolts to take home.
Little extra weight in the package.
That's awesome.
I think the question that would be the most valuable to close off the, this wonderful conversation would be to talk about design.
Best practices that startups can deploy when building out their quality assurance and control plans and I'll specify the part I think because we talked about requirements and I could talk about requirements all day all night. But I think. On the potentially a little bit over on the manufacturing side of things not only in supplier land but also in process development and manufacturing process development, because I do work with a decent amount of entrepreneurs that are buying equipment and just from the beginning of how do we make this?
What is the process to make this? What equipment to buy? Do we make this? What are some? best practices for those types of startups to deploy when they're creating their process maps and going on with more complex manufacturing,
So if I understand the question a startup is trying to figure out how to make their thing, their widget, and they need to figure out what are the steps to getting there. And then they need to figure out how to make sure those steps are working right. Yeah with a hardware product, I think often it's fairly straightforward to break down the product into its subcomponent parts. And when thinking through how to put something together or make that product. It really comes down to how those parts get built up one at a time, and some of that becomes clear because you have to put the switch in before you put the cover on before you screw it down.
And those kind of things are clear process steps and other things are harder We need to put this plastic sheet on top of a part and then somehow stick them together. We could stick them together with fasteners. We could stick them together with maybe a heat seal or some sort of seal.
We could use adhesive. So there are a handful of different process steps there. And there are a few factors that might go into choosing that. It may be harder to do a heat seal if the materials are dissimilar. So you're trying to attach a piece of aluminum to a piece of plastic. That's not going to stick with a heat seal, so maybe you need some sort of adhesive.
But you might be able to do a heat seal if you had A plastic layer on that aluminum. And if that allows you to make the process more streamlined and more repeatable using an existing manufacturing process or manufacturing equipment that your supplier happens to have or has knowledge of how to use, then it might make sense to adjust the design to accommodate that.
Manufacturing process. So there's this balance between design for function or sort of the initial pass at the design and the assumptions the designer made about how it's going to be manufactured. And then this overlay of design for manufacturability where the supplier brings some knowledge of what they know how to do or what is the best practice for how to put two things together and achieve the desired outcome.
And. Need for some iteration and refinement there and I think that's where suppliers deliver a ton of value is coming in with their expertise on how to put something together and how tweaking the design a little bit could make it easier, faster, cheaper to assemble.
Are there any so that's a good point. I'm trying to think of quality. As you say that, are there any obvious things that you can when you're making these decisions either regarding the assembly or the design that you can say. That feature, or this process will likely have the hardest quality control, or it will be the hardest to get good quality out of.
You know what I mean? I feel like that's not something, that's not a perspective I think of often but I feel like it would be very valuable to know.
Yeah, that's definitely something I've run into where you're trying to maybe shoehorn a certain process into a supplier who isn't used to doing it that way. So maybe they're a CNC machine shop and you're asking them to do a thermoform type of assembly or manufacturing process. They're not used to thermoforming.
They can probably learn, but it's not really their bread and butter. And so trying to align the design of the product. With what the supplier can do or align the supplier to the design requirements is really important to getting quality out and you're not going to necessarily it's unlikely that you will get good quality.
If you're trying to force a certain manufacturing process on a supplier with no experience and no capabilities in that space. And so I have definitely run into issues where that. that there is a mismatch between supplier capabilities. And there's this hope, I think they can get there. Maybe if we work a little harder or teach them something, they can get there.
But this is a good example of where it might not work out. And either the design needs to change to match what the supplier can do, or the supplier needs to change to be able to achieve that design.
I think that's super valuable. And I think that is because oftentimes there's this notion of people assume tangential knowledge of just Oh, it's close enough. They should know. But oftentimes when people are highly specialized, that's really not the case. And some knowledge is just not transferable.
So I think that's a really good call out and. To be really mindful when approaching people and really understanding their core competencies so that they can help you in the correct part of your value chain and if they can't, just evaluate to change or switch whichever is, easiest at that point and I feel like with that, I'll just leave it to you to give some last piece of advice for people working in the hardware space or trying to build a venture.
Yeah, I think my parting thoughts are I don't think you need to have someone whose title or job is quality to get a quality product. I think quality is as much a culture and a way of thinking about things and managing risk as it is. People thinking the word quality thinking I need to deliver reliability or I need to design a product that hits customer expectations and really thinking about the customer is very much a cultural thing.
And if you can build that thought process into. The talent who's designing and deploying your product, then I think you're well on your way to building a quality product. And the other pieces become sort of tactical technical skills of understanding variation, understanding how to manage it and monitor it and test and measure.
And there are lots of different skills and people out there who are capable of doing that, who don't have the title of quality engineer or quality person.
Yeah, there might come a time further along when you need people to really specifically be thinking about that and have a team like you do right now. But I do appreciate that the way that you put it is that quality is a part of culture and it's a mindset and once applied correctly, it will just result in better quality product, but also a less headachy hardware development process.
Yeah, definitely.
Awesome. Thank you so much for being on the show. This was super valuable. I know a lot of hardware companies are going to get a lot of benefit from it.
Thanks so much for having me. It was a pleasure.
Hello, and welcome to the Too Long, Didn't Listen section of this episode. So this episode really just dove right into quality and quality control management and Matt did such a good job. So I'm going to leave you with the TLDL key takeaways of this entire conversation.
Okay, let's get started. So first and foremost, quality is all about the customer or the end use. So understanding what, where your product is going to end up is really important. And to understand and meet. Your customers or end uses expectations will define the true quality of your product.
It's not just about functionality, but also about the reliability and user experience your product delivers. Integrating quality from the get go is really important, although it seems daunting and it feels like a big company thing. It's really important to not wait until the last minute to think about quality because embedding quality assurance and control processes early in your product development will just steer clear of potential pitfalls down the road.
Just to add my comment here is that this doesn't have to be a lot of documentation or processes or bureaucracies that you need to create. Those are never a good idea, especially early. early stage in an early stage startup. But what you can do is just have acceptance criteria around what you're building.
That usually is, gives you a reason to talk about what the expectation is. And then it's just like a very tangible. point in time of like, when you do a test or when you do a prototype, just get together and say, does this fit our acceptance criteria? And the meta step to that is what is our acceptance criteria?
So I highly recommend that utilizing tools like failure modes and effects analysis helps you identify what could go wrong and prioritize issues based on the impact. So it's a proactive approach to managing risk and safeguarding your product's integrity. This is just good advice in general.
Testing is really important. You really don't want things to end up in your customer's hands or the end use before you have a chance to find them and fix them. So making sure that you have a relatively robust testing plan that is birthed out of your FMEA or risk register. is incredibly important in the life cycle of your product.
Effective communication with suppliers is also something that we talked about a lot in this episode because it's always that knowledge. Transfer is always a really difficult part. So when outsourcing, ensure your quality standards are well understood and agreed upon internally and externally.
And then have regular visits and engagement. So that you can help maintain these standards throughout the manufacturing process. Implementing quality control at every manufacturing stage is really important so that you can have early detection of issues. And it can, you can also decouple them if you do it at the end of every single cycle.
Documentation is very important.
I think here the balance is very critical, and this is a personal opinion is that meticulous documentation is obviously really important, but also too much documentation kills its fundamental purpose, which is to be able to communicate knowledge and make pockets of knowledge easily acceptable.
If you have too much documentation, you can't find the information you need. So keeping documentation very focused, light touch, but existent for everything you do, I think is the way to go. Also have a one thing that Matt mentioned is having a plan for post launch quality issues. Quality is really important to try to catch proactively, but also having a plan for reactive quality issues is really important.
I actually had a personal experience with Formlabs that I mentioned in the episode. You should go check it out. They had a great reactive quality support that I personally experienced. And then last but not least, cultivate a quality culture with your team. Quality isn't just a department.
It's a mindset. Encourage your team to prioritize quality in everything they do, fostering a culture of continuous improvement. There you have it. Golden rules to engrave your hardware development journey. Remember quality is not an end point, but it's a continuous journey towards excellence.
I hope these key takeaways are helpful and
and provide insight towards you delivering hardware products that stand out for their quality and reliability. Thank you so much for tuning in and I hope that you enjoyed the episode.
The opinions and information shared on this podcast are for informational purposes only. We always recommend that you seek professional advice before taking any action related to your business or personal ventures.
Countless entrepreneurs and innovators have stood exactly where you stand filled with passion and drive, but unsure of where to begin, and that's where "The Builder Circle" comes in.
My name is Sera Evcimen and I'm a mechanical engineer, hardware enthusiast, and hardware mentor. I've had the privilege of working with numerous hardware companies that are passionate about solving some of the biggest challenges in the world. And I will be your host as we explore the exciting and complex world of physical product development.
All right. Welcome to the Builder Circle.
Today I have Matt Lipsitz with me and we're going to be talking about quality. And that's a really broad term that I just threw out there, but we're going to get into the details and how it could be applied in the startup world.
But before we start I just want to say thank you so much for being on the show. And I'd love for you to give a little bit of background to our listeners so that they know who they're listening to.
Sure. I am a mechanical engineer by training. I finished school and wanted to combine my love of theater with engineering and I went to work for a company that built scenery for shows and Broadway and automated that. And I left that industry to go back to school for manufacturing, engineering and business and then worked for a company that did automation machinery for manufacturing low speed, but high precision and eventually moved to Keurig Dr.
Pepper, where I spent 9 years doing everything from machine design to developing the recyclable pickup pod, So to test engineering for Keurig appliances. And I left that around the start of the pandemic to go work for really another appliance company, Formlabs, making 3D printers. And I'm now responsible for quality and sustaining engineering.
Form labs, printers, our hardware.
That's excellent. That's such a swath of very different industries and it seems like also just experience and very different parts of the product life cycle from I know the quality can encompass testing quite a bit, especially when you go into kind of the verification validation loops but that's super cool.
And it's really awesome to have people that have this kind of swath of experience to talk through different types of products because not sometimes even though general practices can be applicable to many, there's still some specifications that come with the different products. So thinking in that way is really, , valuable and I'm so excited for you to be on this episode to, talk about all of that and specifically in the quality realm because that's what you live and breathe right now at Formlabs from what I understand.
Okay the, I guess the biggest question that we start off with is what does the word quality mean for a hardware company? And at a high level, what does it take to realize it?
Yeah. When I think about quality, I really want to start with what does the customer expect out of the product that the company is trying to make and meeting customer expectations is really the baseline of defining quality and a company that's delivering a quality product. Maybe meeting expectations in the areas where the product features that they're trying to deliver.
So that could be things like building a reliable product, building a product that is easy to use may hit a certain cost target. And then from there, building on that, delivering it consistently to every customer. And a lot of what I work on right now is thinking about. Reliability in both operational execution and manufacturing and also in field performance.
And does the product last as long as expected? And does it perform adequately through that length of time? So that's. My starting point definition of quality
yeah. So there are there are a variety of ways to approach quality, but it really comes back to mitigating risk. And when I think about risk, there are a few different sort of phases of the product life cycle where a company can impact. The quality and impact the risk of not delivering to customer expectations.
It really starts with the design and conceptual phase. And thinking through I've got this design. How could it go wrong? How could it fail? The tool that's most often used there is failure modes and effects analysis, which is really a way to quantify the risk in terms of the severity of the risk, the likelihood of it occurring and the ability to detect it in some process.
And risk management is really what quality is all about. Either managing the risk that the product doesn't meet customer expectations or managing risk of cost and schedule and product performance through a, an MPI cycle. And then as a, as you get into manufacturing the products. In my experience, quality is about preventing failures from getting to the field and doing everything you can to catch those issues that detection part of the FMI.
A to catch things before they get to a customer. But of course. You can never catch everything, and there's always a certain reactive part and part of what I've been part of as a quality leader at Formlabs is going from the reactive space where we're doing everything reactively as customers see issues in the field to a more preventative and proactive space where we're trying to minimize the impact.
Of issues and or minimize the existence of those issues, the probability that they occur through manufacturing controls or design controls. And that transformation, I think, is 1 that many startup companies go through as they go from just trying to get a product to market to getting a product to be built consistently with high quality and at volume.
That I really appreciated how you weaved the perspective of quality into multiple stages of the product lifecycle really from, all the way from the conception of it. To testing to launch and to scale. And I think it's really important because oftentimes Quality assurance or control feels like something that companies can think about after product launch or after, we've gotten through this hurdle of developing our technology and we feel better about it.
Or, oh, that's like in the sustainment era, like we'll deploy those later. And I guess I would love to get your. Thoughts on that because I feel like it isn't top of mind immediately. I, people know they have to do it because there's like even unit economics that sometimes depend on it because especially you were talking about kind of the difference between Quality and the design phase and quality in the manufacturing phase, which we'll talk about the difference later.
But when it comes to manufacturing, if you don't have a great yield, then your unit economics start really working against you. And it really starts to from a startup perspective, get in the way of this kind of product market fit hypothesis that you're trying to prove and potentially even the the survivability of your product in the field.
I guess all of that to say is, what are your thoughts on when and how to apply the right level of rigor when it comes to different stages of a company maturity and a product maturity?
Yeah, I want to speak a little bit to the challenge that you mentioned a moment ago before I fully answer that question because. In my head, the thing that drives quality first and foremost is knowing what you want in terms of what you want out of the product. And if you're a design engineer, often that comes back to drawings and specifications and really defining product performance.
Test engineering, you're measuring that product performance and validating it. And so to deliver quality first, you need to know what is quality, what is, what makes this product high quality or adequate quality. And so I think that's a big challenge for folks who are really starting early in their technology development and don't necessarily know what good is yet.
And there's a lot of work that needs to go into defining what is the product that you're making, what are the features to develop, what are the attributes that you want to deliver to the customer and the value that you want to deliver to that customer. And that's an evolution. It's, you never really know out of the gate and the projects that you really do know that out of the gate are pretty low risk projects.
In my experience. When I've been able to write a specification on day 1 and know exactly what I want out the other end, there's pretty little risk and it's not hard to get a good quality product out. But when you're building the train as you're building the tracks and it's rolling down.
The railroad at the same time, it's a lot harder to define that that definition of quality, but that's really important. And as a company begins to build a 1st generation product. And define what they want, it really comes back to being diligent about that definition. And it could be in it could be in written specifications, it could be in drawings, it could be in building prototypes. Yeah, so applying the right rigor early in the life cycle is about defining. What you want in specifications and then finding ways to document what you want and transfer it to whomever is going to build it. So early we talk about product life cycle management or documentation control where you're.
Revision controlling design documentation, and that makes it easier to transfer that knowledge to whomever is going to make it, whether that's a outsourced manufacturing partner or it's internal. And so that is 1 way to communicate. What you want as a design engineer or as a company and ensure quality.
And then the next piece is how do you measure that? You got what you want because that's. Critical to knowing that what comes out the end of the manufacturing line or what the customer receives is going to be good. And there are a few different ways to do that. In my experience, I've worked on test engineering.
So thinking through. Again, how can the product fail? What can go wrong? And then what are the different ways it can fail and testing across those different regimes? So it might be different environmental conditions or different types of let's say electrical power voltages or low voltage different different frequencies.
And that's going to be very much dependent on the application. Thinking of the end user the customer, right? Where are they going to use it? How are they going to use it? What could they do wrong?
Yeah, totally. And more often than not, it's the ways the customer misuses the product that are the surprises and that are hard to anticipate. And, I remember hearing a story about someone putting all different types of alcohol in Keurig brewers. It's not meant for alcohol, but that's an example of.
A time of a misuse that really wasn't anticipated and could be problematic for the performance of the product. And so sometimes those surprises are funny and fun, and sometimes they're frustrating. Working on 3D printers, it's a pretty complicated product. So we find user education is really important to using it right and getting the best performance out of the printer or out of the whole workflow.
We make multiple products, including materials and post processing equipment. So to get a good quality print, you really need to understand that workflow and process, and you need to understand, the best conditions to operate the system. So things like temperature and humidity become really important.
The age of the resin may be important or the incoming electrical power quality to make sure the printer isn't varying its power and maybe dying in the middle of a print. Typical types of problems
I'm so the I guess what I'm trying to get out with the question is when people are working in startups, either as a mechanical engineer or a technical lead, or an electrical engineer, they're looking at. The beginning of the life cycle and they're in the technology development phase and going from that technology development phase, you're talking about what we touched on this, like proactive versus reactive quality I guess action.
And I feel like there's really good bits and pieces that people can do actively now when they are in the design phase, which you alluded to of just having really good requirements, going back to them, making sure that they have validity with the end user and the customer. And then also, once you design it to test it so that you are getting close to those requirements, or at least knowing how close you're getting.
In my mind, that's how I think of proactive, but were you thinking of something along those lines of just like that is the proactive piece of the puzzle and then reactive is what actually happens in the field?
Yeah, you're right. The most impactful proactive work happens in the design phase and the design validation phase before that product gets to a customer. And it's also the least expensive place to impact quality. The earlier you can. make a difference, the better. In theory, everything, every product can be designed right the first time, and there are never quality issues.
But that's never really true. The second sort of phase is in the new product introduction cycle, ramping up manufacturing, and then once into mass production. Trying to find those control points in the manufacturing process where you can catch issues. And again, I'll come back to that risk assessment tool where you're thinking through, how do I detect that an issue is happening?
And ideally, it's not detected at the customer. It's detected long before the product gets to the customer. Because once again, the earlier you can detect a product failure, the earlier you can Mitigate it and the less costly it is in the end. And so some of quality is about quality control and thinking through in a manufacturing space.
Where can we catch issues? So maybe supplier 1 is making a part. It gets assembled at supplier two into a subassembly, and then it maybe it even goes into supplier three to be put into a finished good packaged and shipped to a warehouse. Each of those steps is an opportunity to catch quality issues along the way.
And ideally, if the individual part has an issue, you catch it at that first supplier before it gets to tier two and and tier one. At this at the finished good manufacturer. So a lot of quality controls about thinking about what is really important to me because you can't measure everything.
And then where can I catch that really important thing as early in the process as possible? So we. May implement things like outgoing quality control inspections. Some percentage of outgoing parts is inspected for critical to quality dimensions or features. And then the supplier issues a report to say, this batch of product is good and it goes to the next step and do a similar type of thing.
And then secondarily, there's often outgoing quality control inspections. So that could be testing. It could be some sort of. Measurement or just a visual inspection to make sure cosmetics are good, or that could be even a functional test to operate the system. And these are all really control points that manage the risk of a quality escape before it gets to a customer.
Then on the most downstream side, there's the reactive quality space. And that's, of course, very costly. And oftentimes you're reactive because a customer has called your customer service team and said, I have a problem and I don't think the machine's supposed to work this way. Help me fix it. And by that point, you've got a brand integrity risk because now the brand is threatened by this customer who's unhappy.
The customer can't do what they want to with the product. It's not working as intended and you have to react to it. And often that takes time to troubleshoot and figure out where the issue came from and then to go and fix it. So for example right now, if I want to make a change to a hardware product.
It may take a couple months for that change to cut into manufacturing because we need to go through some amount of in work in process inventory before we can cut in a new part that gets assembled onto the product, it gets packed and shipped. It could take 3 months to ship by sea over across the world, to the U.
S. and then eventually get to a customer. So it could be 3 to 6 months. Until a customer sees that change. So sometimes reactive quality needs to be faster and we need to deploy things like customer replaceable parts or field service technicians or a software update that'll patch fix the problem.
So fortunately, there are a lot of levers to pull that can solve these things. But I think in the the reactive space, they're very costly and they cause, engineers, you got to pull engineers from their day jobs, designing the next product to go fix the issue the issue from the product that's already in the field.
Definitely. And I do have to make a I guess a shout out to you for like truly not only talking the talk, but walking the walk with this one because I was at a previous company and I actually, we had some small issues with our Formlabs printers and I had met Matt beforehand and I just.
LinkedIn messaged him saying that we were having a problem and they directly swung into action and helped us and fix the issue almost within a few days. And it was excellent. Although we try to avoid the reactive quality it's really nice to see companies when they actually do follow through with fixing the issue.
So I'll give a little bit of a, Formlabs for that one.
Thank you. It's, that is definitely part of our product. We've chosen to make customer service a priority, and we want customers to have a good experience and make sure the product is working reliably for them.
Absolutely. So you mentioned so many valuable things throughout throughout the entire tasks that take to get a product out and successfully implemented with customers and continued on with brand integrity.
One of the things that you mentioned was quality control and obviously quality control has many. different ways of doing it. And you gave some really good examples of that. One of the things that I guess I would be curious to know your take on is oftentimes. So there's two scenarios that startups could potentially face when it comes to building their product.
They could be internally manufacturing it or they could be outsourcing it. As you said, they could be going through this kind of supply chain or supplier chain more so where a different subcomponents or subsystems get assembled somewhere else and then the entire system integration happens somewhere, which is I think one of the most complicated or it just happens at a contract manufacturer or it happens in house.
So my question is. When it comes to quality control, how do you approach it when it's internal versus external? And I guess what are the differences and how can you communicate that effectively?
Yeah, I think what you're describing really comes down to one of the hardest things to do in product development, which is transfer a product from the people who have designed it, who are the creators and ideated the product to the people who manufacture it. And even if it's in house.
It's hard because knowledge transfer is hard, and we keep so much in our heads, it's hard to externalize that knowledge and write it all down so that somebody else can digest it. And there are certainly tools we use for that. I've talked about drawings and models and other things. Fortunately, when it's in house.
It's a little easier because theoretically everybody's working for the same company. There's hopefully a common culture. It's easier to go to the site where the product is manufactured because you don't need to jump through quite as many hoops. But when it's outsourced, the importance of externalizing that knowledge is so much greater.
And quite often you're dealing with cultural differences. So much is manufactured in Southeast Asia, but designed in the United States, or the company is based in the United States. That's a huge cultural time zone and just a day to day behavioral difference in, in Needing knowledge transfer that those are hurdles that just get much greater than transferring knowledge within a single within a company.
In those cases, I think, come back to defining what you want really specifically and then there's a 2nd layer. Where you really need to work closely with the supplier sometimes be on site with them to help realize what you want, because there's so many times when just a phone call or an email doesn't exchange the information quite enough, and there are nuances to the manufacturing process or the limitations of that supplier capability that you just don't get when you're virtual or far away.
And so that's where either having people on site who can be a company's agent to help transfer that knowledge or going personally and traveling to the location where it's being made makes all the difference. And, that applies even in a vertically integrated company where you're making it yourself.
I saw that. At carry Dr pepper in a few different ways, there was vertical integration for some of the consumables and the pods and going to the manufacturing site helped me understand the limitations of that manufacturing. And then the appliances remain in Southeast Asia with the contract manufacturer again, going there made all the difference to transferring knowledge and transferring activities.
We spent a lot of time moving testing from the U. S. to Asia, and we had to be there, be on site, and have additional people from our company on site to help train the technicians on how to test and how to assemble the product.
Gotcha. And do you feel like, and I, it's okay if you haven't really had the experience of this, but oftentimes what happens with a lot of startups is that they end up working with suppliers that care as much about their business because it's a drop in the bucket for them because startups start with very low quantities.
Do you feel like That is, that could still be possible that just like site visits and keeping a close pulse on the quality. Is that something do you feel like suppliers would be open to?
Yeah, absolutely. I think that any supplier relationship is a partnership, and it's a partnership that both parties need to invest in. So a supplier needs to be invested in making the product and making it well, but you can't always expect them to know what good is unless you teach. And then there's a certain amount of verification needed.
And quite often being that face to face person on site shows an investment in the partnership and an investment in understanding the challenges that supplier is facing so that you can work through them together. And I think that's really the key to successful quality. Is being a sort of imagine arms locked and charging down the aisle together to go build something.
That's how it needs to be. Is that meet in the middle of a partnership of part supplier bring certain expertise for how they know how to do things and customer brings expertise on what they want and how to make the thing or what they want out the other end of the line. And together they go and build it.
And then make sure it's good. And I think even with early startups, that sense of partnership and finding the right partner is so key. Because otherwise I don't think you really can deliver quality. You can't always expect that the supplier knows what you want or can deliver it. If they don't have experience with it.
That makes sense. And I guess I, I want to also ask your opinion on dealing with a potentially sticky situation where your supplier or your integrator or your contract manufacturer, somewhere outsourced is not really performing well, where the, maybe the quality is okay, but the yield is very low, or the the yield is, in their mind, great, but it's because their understanding of quality is off.
What steps do you go through to either mend the situation, or like, how do you let go? When do you know to let go of a supplier and potentially go somewhere else?
There are certain sort of typical tools for telling a supplier that something's wrong. You can use tools like corrective and preventive action documents that sort of say, Hey, there was a problem in the field. Please go fix it. Here's where the problem was. We want you to go troubleshoot, but that turns into something very transactional and it assumes the supplier can go fix that problem.
Now, if it's something that a manufacturing partner should be able to do, manage inventory or clear a line after a production lot, so that you don't get mixed and matched parts that kind of thing usually can be transactional, but if it's something a little more nuanced, maybe it's the proper adjustment and dialing in the mechanism of a 3D printer and using certain, tools to calibrate.
That requires a little more handholding and partnership and being, often being physically there and present. And at a certain point, you make that investment for a period of time, and if the partner still can't get there, Then you have to decide can they ever get there. And are they, do they have the skills, the talent, the people who can understand what we want as a customer.
And then can they deliver what we want, even if it takes a significant investment from from the client. And if not, then it's time to walk away and find somebody else who can do it. Sometimes the other reasons for walking away are cost. The cost is too high, and it's time to go find someone who can do it for less.
The risk there is often lower cost means less attention to quality and fewer people paying attention to process controls. And so that's a balance too, and often requires a little more oversight, but it can deliver dividends on the cost side.
. If, like, when you get into that point where you are deciding whether or not you're going to continue with a supplier or spin up a new one I would assume that there's a lot of trade offs of doing that because you already have invested in a lot of knowledge transfer with this partner you probably have this crazy demand that you're trying to hit, which is a lot of A very common problem that hardware startups have actually is not the market side, which is a lot of software companies have that issue with hardware.
It's like you have so much demand, but you don't have the ability to scale quickly. So it's like when these types of problems happen, quality is usually the first one to get the get the boot off the boat because they're like, Oh at least we can get something out. And I personally disagree with this because I think your point about, the product and brand reputation is really important and really critical specifically in the early stages. But anyway, all of that to say how do you evaluate those trade offs and have you ever had to make a decision like that? Is there any you don't have to give a specific example or you can give like a made up example of like how a person can how a hardware team could evaluate something like that and actually come up with a decision to?
Either continue with the same supplier and try to get them to to get to the right quality metrics or say, you know what? Nope. We're going to spin up someone else.
Yeah, I have been in that place and I've also been in the place where I've carried multiple suppliers forward in order to try to tease out a winner, so to speak, or one who can realize the right quality or the right features of a product. And sometimes that's the right solution is you need to carry multiple multiple paths, but it can be very costly from a time and a resource standpoint.
So I think it's, I always want to put in a decent investment in trying to build up a supplier and teach them what it takes if I have the know how to teach them what it takes to make this product and give them at least a few tries. But quite often. You get down the road and by the time you realize that they can't do it, you're stuck.
So there are some trade offs there. It really depends on the situation. Sometimes the situation is such that they can make a couple of good parts, but the yield is pretty low. So maybe that's enough to you can invest some dollars in low yield while building up a new supplier and a second source.
But again, that's a time penalty and a dollar penalty. And sometimes it's necessary to pivot much more quickly, which again, often costs time. And coming back to an earlier point, trying to think through these risks, thinking about where am I single sourced? What is really critical to quality and Focusing attention engineering effort and early risk mitigation on making sure those key things are going to hit the mark at least adequately might not have to be 99.
9 percent yield. But, if you can get an adequate dollar investment for a good quality parts coming out then, you've done a pretty good job managing that risk. And I think one of the biggest strategies there is to try to carry a few solutions at the same time and not put all your eggs in one basket.
But you're right that early stage startups often only have a couple of choices, and that's limited. But, thinking creatively about what those options are, maybe building the part in house or the sub assembly in house is an okay interim solution until you can stand up a supplier and transfer it there. It really varies. It depends on the product and complexity. And
with you a specific I mean it really depends obviously on the product because if it's a very complex industrial machine that might not be feasible, or it's better to do it that way again it's super product dependent and I completely agree with that. But I also. Agree with the point that even as a early stage startup, when to be able to do that knowledge transfer successfully, I think you have to be able to build it in house at least once, even if it's an industrial equipment, even if it's maybe it's a, if it's an industrial equipment, you simplify the problem and you build a subsystem in house and you build a subscale prototype where it's not the big thing but a small thing.
That does something similar that you can extrapolate the data and say, okay, the big thing might work. But I really, I personally, specifically in startup world, having the core competency around your product and being your product's main, I guess owner and knowledge keeper is really important because you stress this throughout the entire like questions that we've been answering is that the most important and the hardest thing is to be able to communicate that knowledge, whether it is insourced or outsourced or whatever.
And if you don't know that knowledge, like the back of your hand, you're not going to be able to communicate it effectively, which then downstream will result in low quality. Products. So that makes a ton of sense.
That's not to say that you can't outsource, there may be people with subject matter expertise in certain areas, but you do need to make sure you know what you want out the other end and you can measure that thing.
And if you don't know, I also like making lists of the unknowns. Obviously the unknown unknowns will come out in tests. Like you can't write those down. Hence the unknown. But. Even if you have unknowns that's a really good thing to be able to communicate to an outsource partner because they might be able to tell you what those unknowns should be.
And then that's why I think it's so important to get to a prototype and testing quickly is because that's when you really uncover the ones that the unknowns that you don't know and go from there. It is critical. And. So we're still in the, topic of quality assurance and quality control and all of these things.
I, I'd love to get your perspective on common pitfalls that you've seen in this, in the world of quality specifically when it comes to products and systems.
Yeah. I think a common pitfall I've seen is building some prototypes in an early stage and then making an assumption that those prototypes represent the real world. And the truth is their models, they are good enough to test and prove some concepts and prove out the theory of operation, but it's rare that they represent the full breadth of variation that comes out when you get a product to the field and customers may misuse it, or it experiences different environmental conditions or use cases.
And thinking through, okay, I've got this kind of nominal case, this prototype that is working okay, how do I stress test it and push it to the extreme to understand if it works in these other regimes? And I think that's one of the hardest things to do, and to think through, how can I break it, really?
And what does it take to break this thing? But that's where you get the most learning. I've said it before in in talking about testing, that you don't really learn anything from a test that passes. You learn from tests that fail. And when you're doing validation engineering, particularly design verification it's really all about finding that point of failure where you understand the risk you're taking on or the risk of the product performing or not performing.
And that doesn't mean that failure has to be or always is in a place you don't want it. Sometimes there's plenty of margin for performance but knowing where that margin is and how much you have is really key.
Yes, I would agree when I think about some of the products that I've worked in, that's definitely been the case. I think one of the common pitfalls, and we've nailed this multiple times throughout the conversation is really not thinking about where to implement quality control.
I've I've seen a lot of entrepreneurs Just assume that the because it just because outsourced supplier is the subject matter expert in something. It doesn't mean that the quality metric that they're going to produce something is going to match what you need and what your system needs. And there's sometimes just this inherent assumption that it will.
And I think The biggest thread that I'm picking up from our conversation is that it's so important to understand your quality success criteria and not assume that people will hit it.
Yeah, you're totally right. And also, not assume that your supplier understands what really is important, because as I said, you can't measure everything. So you need to focus on the things that are truly critical. Hopefully is just a handful of things and then make sure that's what the supplier is spending their energy doing is looking at those things and understands how to control them and how they can go wrong.
And just assuming the a that the supplier understands your product or be that they know how to do QC is certainly a pitfall. And so trying to be. Maybe not overly prescriptive, but help that supplier understand what's really important and then partner or collaborate on how to realize it.
That's a really important thing for getting the thing out that you want to get out.
And honestly, this is just a note on this once you have a little bit more thought put into and this is to support entrepreneurs to implement quality earlier on is once you have that kind of sense of quality control, you start to like enforces better Practices in your product development.
And so you have better documentation. You have a better understanding of success criteria. You potentially have a really humbling experience of how much you are not aware of, which is always a good thing. And then what that causes you is to prepare better for supplier engagements. Because I do see a lot of companies also just tumble into these supplier conversations because and get Multiple quotes, or re communicate multiple times, and all of these things, and if you can bring that quality mentality earlier on, it'll keep your team nice and buttoned up a little bit more, and then once you approach suppliers with better quality better communication around requirements, better communication around specifications, what they, the expectation is.
You'll be treated differently too, because there's this common thread that startups get treated poorly by suppliers, which for some suppliers, this is true. They want millions of dollars, you're giving them thousands. But It's also the case that you usually the headache is because startups could be unprepared going into the conversation.
So I really appreciate the kind of message of if you bring quality, the mentality of quality early, it not only potentially will not potentially, it will definitely influence your product to have higher quality, but it will also enforce better systems, engineering practices, better mechanical design practices, better manufacturing practices.
And. In turn, have you better prepared for supplier conversations? Do you feel like that's a good kind of summary?
I think you're spot on, and I think you could extend that concept to I'm going to come back to the concept of Customer. The definition of a customer could be the end user, but really every phase in the new product development process has a customer. So the design engineers customer may be the manufacturing engineering team or the supplier.
The suppliers customer is both the the folks who are ordering it, the company that's building the product, And the customer and user and probably also the logistics company and the warehouse company. So there are all these different sort of customer supplier relationships in that cycle.
And so the more you, wherever you sit in that life cycle or in that workflow, think of your downstream partner as a customer and delivering customer, delivering value to that downstream customer, anticipating their needs and meeting them the better and the more streamlined, the more effective, the faster the process will go and the less rework and confusion.
So I think that's Kind of what you were just describing.
Absolutely. I love that. I really do appreciate the fact that the customer isn't just the end customer. You have many interim customers up until it gets to that point. I really like that perspective. So we just talked about how everything can be just like rainbows and butterflies of quality and everyone designs the best product, has the best requirements.
You validate the requirements you've got at a hundred percent 📍 if only.
This episode and podcasts are brought to you by my consulting company, Pratik Development
where every startup receives a tailored approach in transitioning their ideas. Or research and to innovative hardware products. I'm dedicated to helping with strategic execution and product development, scaling manufacturing, and optimizing supply chains to bring your vision to life. I believe that hardware should be accessible and successful.
And that's the whole reason that this podcast exists. So if you value the podcast and you'd like the episodes and you appreciate the insights, please support us by sharing rating and leaving a review on your favorite podcast platform. Your engagement is crucial in helping us reach more visionaries like yourself. Thank you so much for listening and being a part of the community.
So I, I feel like this is a perfect transition to switch on to the absolute polar opposite of what we were talking about and talk about hardware horror stories.
Hardware Horror Stories Segment
This is one of my favorite segments that I like to do with all of my guests.
And I'm, and I feel like in quality specifically, you can get some really funny stuff not to put you on the spot maybe not funny, but interesting. So I'd love to hear if you've ever had hardware horror stories related to QA, QC, some. Quality stuff just going absolutely horribly.
Now the pressure's on for something funny.
I had something prepared. I'll talk about what what came to mind. In several of my experiences, I've run into an issue where something was measured in more than one place. And anytime you measure something in different places you have room for disagreement, and likely the measurements are going to disagree, and that
say place, sorry, just to clarify, when you say place, is it like different suppliers or a different spot on like the mechanical piece?
Yeah, let me clarify you're measuring the same thing in two different physical physical suppliers or physical laboratories, let's say. And that might mean you're measuring with different instruments. It might mean you're measuring with different measurement processes. So you think about a coordinate measurement machine needs a special program.
Those two programs across different locations might be different. And the programmer might have come at the geometric dimensioning and tolerancing differently and interpreted it differently. And anytime you have redundancy in measuring the same thing, whether it's the same feature or the same performance metric on a product, there's room for variation and likely room for disagreement between the values the output of those measurements. And I've seen this multiple times where a contract manufacturer in Asia measures something according to the SOP. They did it right. Their tools seem to be calibrated, but the measurement was different from what we got in the United States at the laboratory at our headquarters and why?
And this causes lots of engineering angst and lots of discussion and concern. Why was it different? Which one do we trust? And so the best practice that I recommend is to have. a single source of truth for measurements, and to qualify those measurement systems to make sure you do trust them.
And if you absolutely have to measure in more than one place, then it's critical to have the same tool and the same process in both of those places. And that's going to avoid so much waste and confusion and that question of which do I trust? Which one is right? Is the, is it out of spec by X or Y?
And when you say just to turn it into, like a practical step that someone could take, say it's a measurement of a, actually like a width of something are you saying you put whatever measurement tool you're using say a micrometer is a terrible probably a measurement tool for mass production.
But anyway, let's say micrometer. When you say like you qualify that Measurement tool. Are you saying you get something that has a known known with and then you use both of those to measure that? And if it's giving the right result, it's calibrated. It's good. Is that what you're talking about when you say qualify?
That
different steps to qualification. This is a good clarification. First, I always want to know, is the tool we're using calibrated? Do we believe it to be accurate, no matter who is using it? Some tools, let's say a caliper or a micrometer, can go to a calibration lab and be calibrated so they have a sticker on them that says, this tool is accurate.
The second step is it measuring repeatably and reproducibly, meaning you measure the same part more than once and it comes out approximately the same. You measure multiple parts across different operators and they come out approximately the same. And so that sort of takes into account the different sources of variation.
And in qualifying a measurement system, you want to make sure that it will measure accurately, repeatably and reproducibly across the full range of expected measurement. Let's say you're measuring something that could be anywhere from 10 millimeters to 12 millimeters wide. The accuracy, repeatability, reproducibility needs to be, good within that full range.
sense. Okay. Yeah. Looking at both the accuracy and the precision continued precision, that makes. That is super important. Did you have any other stories or was that it? That's okay if it is.
Now I'm trying to think. I'm sure I do. Yes. Okay. Some things that come to mind are oftentimes when putting something together and using automated equipment Maintenance of that equipment comes into play. And there have been examples of nuts and bolts inside sealed packaged products that have come back.
And again, I talked about a brand integrity threat. That is definitely a brand integrity threat when you've got a sealed package that is supposed to work. Only have the product intended in it. And it actually has parts of the machine that made it that, that were sealed into the package.
So that's not a good quality escape. You definitely want to avoid those. And that's why a lot of companies put in automated inspection tools to try to catch those things before they leave the factory.
That's awesome. Honestly. I would really love to see that failure mode in action. Just to experience that. It's, for the consumer, you get more for what you pay for, you get some additional nuts and bolts to take home.
Little extra weight in the package.
That's awesome.
I think the question that would be the most valuable to close off the, this wonderful conversation would be to talk about design.
Best practices that startups can deploy when building out their quality assurance and control plans and I'll specify the part I think because we talked about requirements and I could talk about requirements all day all night. But I think. On the potentially a little bit over on the manufacturing side of things not only in supplier land but also in process development and manufacturing process development, because I do work with a decent amount of entrepreneurs that are buying equipment and just from the beginning of how do we make this?
What is the process to make this? What equipment to buy? Do we make this? What are some? best practices for those types of startups to deploy when they're creating their process maps and going on with more complex manufacturing,
So if I understand the question a startup is trying to figure out how to make their thing, their widget, and they need to figure out what are the steps to getting there. And then they need to figure out how to make sure those steps are working right. Yeah with a hardware product, I think often it's fairly straightforward to break down the product into its subcomponent parts. And when thinking through how to put something together or make that product. It really comes down to how those parts get built up one at a time, and some of that becomes clear because you have to put the switch in before you put the cover on before you screw it down.
And those kind of things are clear process steps and other things are harder We need to put this plastic sheet on top of a part and then somehow stick them together. We could stick them together with fasteners. We could stick them together with maybe a heat seal or some sort of seal.
We could use adhesive. So there are a handful of different process steps there. And there are a few factors that might go into choosing that. It may be harder to do a heat seal if the materials are dissimilar. So you're trying to attach a piece of aluminum to a piece of plastic. That's not going to stick with a heat seal, so maybe you need some sort of adhesive.
But you might be able to do a heat seal if you had A plastic layer on that aluminum. And if that allows you to make the process more streamlined and more repeatable using an existing manufacturing process or manufacturing equipment that your supplier happens to have or has knowledge of how to use, then it might make sense to adjust the design to accommodate that.
Manufacturing process. So there's this balance between design for function or sort of the initial pass at the design and the assumptions the designer made about how it's going to be manufactured. And then this overlay of design for manufacturability where the supplier brings some knowledge of what they know how to do or what is the best practice for how to put two things together and achieve the desired outcome.
And. Need for some iteration and refinement there and I think that's where suppliers deliver a ton of value is coming in with their expertise on how to put something together and how tweaking the design a little bit could make it easier, faster, cheaper to assemble.
Are there any so that's a good point. I'm trying to think of quality. As you say that, are there any obvious things that you can when you're making these decisions either regarding the assembly or the design that you can say. That feature, or this process will likely have the hardest quality control, or it will be the hardest to get good quality out of.
You know what I mean? I feel like that's not something, that's not a perspective I think of often but I feel like it would be very valuable to know.
Yeah, that's definitely something I've run into where you're trying to maybe shoehorn a certain process into a supplier who isn't used to doing it that way. So maybe they're a CNC machine shop and you're asking them to do a thermoform type of assembly or manufacturing process. They're not used to thermoforming.
They can probably learn, but it's not really their bread and butter. And so trying to align the design of the product. With what the supplier can do or align the supplier to the design requirements is really important to getting quality out and you're not going to necessarily it's unlikely that you will get good quality.
If you're trying to force a certain manufacturing process on a supplier with no experience and no capabilities in that space. And so I have definitely run into issues where that. that there is a mismatch between supplier capabilities. And there's this hope, I think they can get there. Maybe if we work a little harder or teach them something, they can get there.
But this is a good example of where it might not work out. And either the design needs to change to match what the supplier can do, or the supplier needs to change to be able to achieve that design.
I think that's super valuable. And I think that is because oftentimes there's this notion of people assume tangential knowledge of just Oh, it's close enough. They should know. But oftentimes when people are highly specialized, that's really not the case. And some knowledge is just not transferable.
So I think that's a really good call out and. To be really mindful when approaching people and really understanding their core competencies so that they can help you in the correct part of your value chain and if they can't, just evaluate to change or switch whichever is, easiest at that point and I feel like with that, I'll just leave it to you to give some last piece of advice for people working in the hardware space or trying to build a venture.
Yeah, I think my parting thoughts are I don't think you need to have someone whose title or job is quality to get a quality product. I think quality is as much a culture and a way of thinking about things and managing risk as it is. People thinking the word quality thinking I need to deliver reliability or I need to design a product that hits customer expectations and really thinking about the customer is very much a cultural thing.
And if you can build that thought process into. The talent who's designing and deploying your product, then I think you're well on your way to building a quality product. And the other pieces become sort of tactical technical skills of understanding variation, understanding how to manage it and monitor it and test and measure.
And there are lots of different skills and people out there who are capable of doing that, who don't have the title of quality engineer or quality person.
Yeah, there might come a time further along when you need people to really specifically be thinking about that and have a team like you do right now. But I do appreciate that the way that you put it is that quality is a part of culture and it's a mindset and once applied correctly, it will just result in better quality product, but also a less headachy hardware development process.
Yeah, definitely.
Awesome. Thank you so much for being on the show. This was super valuable. I know a lot of hardware companies are going to get a lot of benefit from it.
Thanks so much for having me. It was a pleasure.
Hello, and welcome to the Too Long, Didn't Listen section of this episode. So this episode really just dove right into quality and quality control management and Matt did such a good job. So I'm going to leave you with the TLDL key takeaways of this entire conversation.
Okay, let's get started. So first and foremost, quality is all about the customer or the end use. So understanding what, where your product is going to end up is really important. And to understand and meet. Your customers or end uses expectations will define the true quality of your product.
It's not just about functionality, but also about the reliability and user experience your product delivers. Integrating quality from the get go is really important, although it seems daunting and it feels like a big company thing. It's really important to not wait until the last minute to think about quality because embedding quality assurance and control processes early in your product development will just steer clear of potential pitfalls down the road.
Just to add my comment here is that this doesn't have to be a lot of documentation or processes or bureaucracies that you need to create. Those are never a good idea, especially early. early stage in an early stage startup. But what you can do is just have acceptance criteria around what you're building.
That usually is, gives you a reason to talk about what the expectation is. And then it's just like a very tangible. point in time of like, when you do a test or when you do a prototype, just get together and say, does this fit our acceptance criteria? And the meta step to that is what is our acceptance criteria?
So I highly recommend that utilizing tools like failure modes and effects analysis helps you identify what could go wrong and prioritize issues based on the impact. So it's a proactive approach to managing risk and safeguarding your product's integrity. This is just good advice in general.
Testing is really important. You really don't want things to end up in your customer's hands or the end use before you have a chance to find them and fix them. So making sure that you have a relatively robust testing plan that is birthed out of your FMEA or risk register. is incredibly important in the life cycle of your product.
Effective communication with suppliers is also something that we talked about a lot in this episode because it's always that knowledge. Transfer is always a really difficult part. So when outsourcing, ensure your quality standards are well understood and agreed upon internally and externally.
And then have regular visits and engagement. So that you can help maintain these standards throughout the manufacturing process. Implementing quality control at every manufacturing stage is really important so that you can have early detection of issues. And it can, you can also decouple them if you do it at the end of every single cycle.
Documentation is very important.
I think here the balance is very critical, and this is a personal opinion is that meticulous documentation is obviously really important, but also too much documentation kills its fundamental purpose, which is to be able to communicate knowledge and make pockets of knowledge easily acceptable.
If you have too much documentation, you can't find the information you need. So keeping documentation very focused, light touch, but existent for everything you do, I think is the way to go. Also have a one thing that Matt mentioned is having a plan for post launch quality issues. Quality is really important to try to catch proactively, but also having a plan for reactive quality issues is really important.
I actually had a personal experience with Formlabs that I mentioned in the episode. You should go check it out. They had a great reactive quality support that I personally experienced. And then last but not least, cultivate a quality culture with your team. Quality isn't just a department.
It's a mindset. Encourage your team to prioritize quality in everything they do, fostering a culture of continuous improvement. There you have it. Golden rules to engrave your hardware development journey. Remember quality is not an end point, but it's a continuous journey towards excellence.
I hope these key takeaways are helpful and
and provide insight towards you delivering hardware products that stand out for their quality and reliability. Thank you so much for tuning in and I hope that you enjoyed the episode.
The opinions and information shared on this podcast are for informational purposes only. We always recommend that you seek professional advice before taking any action related to your business or personal ventures.
