What do engineers need to understand about manufacturing? How can you apply that knowledge to design controls? On today’s episode, our guest Tom Rish covers the topic of Design Controls. Tom is the Director of Guru Services at Greenlight Guru and a Product Development Engineer in Orthopedics.
Listen as we talk about the differences between user needs and design inputs and the pitfalls companies get into when building design controls. Tom also shares what he thinks people should understand about cross-functionality, why it sometimes makes sense to start from scratch, and using the design control process strategically.
Watch the Video:
Listen now:
Like this episode? Subscribe today on iTunes or Spotify.
Some of the highlights of this episode include:
-
Thinking in terms of manufacturing
-
Things everyone ought to know about working cross-functionally
-
Why starting from scratch may be better
-
Who needs to be looking at design controls and when they should be looking
-
The difference between a design review and a stage review
-
What Tom got to see that helped him understand how things worked
-
What to look for on the manufacturing floor
-
Using the design control process strategically
Links:
Memorable quotes from Tom Rish:
“If you can get a tool in a certain spot you can do it, but if you can’t, you can’t.”
“We like to say at Greenlight Guru: the outputs are the recipe.”
“I think that a lot of times people use design reviews and stage reviews interchangeably.”
“I can’t even put into words how valuable it was to go down to the manufacturing floor as an engineer.”
Transcript:
Etienne Nichols: Hey everyone. Welcome back to the Global Medical Device Podcast.
Today with me is Tom Rish. One you probably heard before. I know he's been on the podcast a few times before I came along. How are you doing, Tom?
Tom Rish: I'm doing well, Etienne. Thank you for inviting me. I'm excited to talk about design controls.
Etienne Nichols: Yeah, I'm excited to talk to you today too, especially when I learned that you're about to be out for several weeks for having a baby. So, several of the gurus have just kind of.
I've kind of lassoed them into doing a podcast with me and everybody's been really great. So really appreciate your willingness to do this.
Tom Rish: Yeah, I've got a list of things that I have to finish and this is up at the top because I already.
I already canceled on you once. So, we're here and we are going to finish it before I'm gone.
Etienne Nichols: Okay. Okay. So excited. So, I guess you already kind of talked about what the topic is going to be. Design controls. What?
Why don't we start with your background in design controls and where you come from?
Tom Rish: So, I started my career in the orthopedic space as a product development engineer. And like every engineer coming out of college, I was super excited to build some new products, design some new products.
And my first job, I got there, I knew ahead of time, but still I was going to be a post market engineer. And I was like, oh, man, I don't want to do that. I want to design new products.
But it was the best thing that had happened to me at that point, which was very early in my career because I learned so much about design.
I learned about, you know, things that could go well, things that maybe don't go as well when you have a product in the field. Because what was happening was I was working with our suppliers and our manufacturing team and not as often, thankfully, sometimes with like the quality team, if there were issues out in the field.
And we would go back, and we would try to update designs and drawings, and we try to figure out, you know, what were people thinking. And there wasn't always the best documentation because they were maybe older products and what not.
So, it really got me thinking about what is a good design, what could be manufactured,
what is safe, what's going to potentially cause problems in the field. So, I did that for a while.
Finally got to move on to new products and then spent, I spent about 8, 9 years total designing orthopedic products before I came to Greenlight. And then I think when I came to Greenlight, that's when the light bulb clicked and I really learned a lot more about design controls, which I'm sure we'll talk about here a little more.
Etienne Nichols: It's too bad that sometimes it takes multiple jobs to recognize the benefit of one aspect of a job. You know, if you're in the moment, maybe you could suck more,
I don't know, learnings out of that situation.
I remember when I was, I was in college, I was doing a part time job as at an engineering firm and they, they put me on an end mill like a Bridgeport 3 axis end mill. And I wound up having a thousand hours on that thing and I was like, this is wasting my life, you know, just running parts through and doing all this stuff.
But later on, it, it, it really makes a difference. And it sounds like that you kind of had a similar experience.
Um, I'm curious if anything really stood out when you, when you went through that post market, that job, when you were learning those things, were there any specific learnings that you applied later on that you might not have had otherwise? Did anything come to mind?
Tom Rish: You know, so I think your story is very relevant because I think as engineers, we, we study in a classroom, in a lab. Right. And at least in my experience I was biomedical, so not much mechanical.
I didn't have a lot of like work with machines and, and tools in the academic setting, so to speak.
Did some things at home and what not but never like in an orthopedic setting. So, because of that, like I just didn't really think about manufacturing when I first thought about design.
I thought about what's, what's going to look cool or what's going to be like, yeah, very ergonomic or lightweight or what's going to be something that you can get into this access point in the joint very easily and you just don't even think about manufacturing.
So, I think I, because I worked so much with suppliers who were typically more manufacturing focused in the manufacturing team, you really started to think, okay, that's why I can't do that. And I was like you, I didn't get to run any machines myself, but I loved going down to the manufacturing floor and just watching because you could see it's really not as hard as you would think.
It's like a lot of common sense. If you can get A tool in a certain spot, you can do it, but if you can't, you can't.
I think I started thinking more about manufacturing and I'm glad that happened early because I know a lot of engineers struggle to think about that till it's too late.
Etienne Nichols: Yeah.
One thing that I never really thought about from the manufacturing side, I guess the different, different roles that I played, the design controls, which is what we're talking about today, those are one of the things that sort of, that I looked at that as upstream and I didn't really think a lot about that. Very often, occasionally when we wanted to change something, we'd go to product and say, hey, can we change this?
And they would pull out all these papers and things and start working on it. And it always took longer than I really felt like it should.
But maybe had I understood that, you know, there's, there's just different aspects, different sides to every, every story.
What, what are some of the things that you think everybody.
I don't know if it's definitions and design controls or just, just things that everybody really ought to know so that you can work a little bit better cross functionally. Any thoughts?
There's.
Tom Rish: Yeah. Well, I, I definitely want to talk about some of the definitions because I see confusion. But on that topic, I think you bring up a really good point.
What I try to tell customers is they always think of manufacturing transfer, design transfer, whatever you want to call it. It's like this huge event that you're working towards, right?
And I try to teach them like, no, it shouldn't be a huge event. It should just be sign off on a bunch of documentation.
You want to make sure that your manufacturing team doesn't come in a week before design transfer and start reviewing to be there on day one. And that. So, I think that cross collaboration, a project plan is something that everyone just is like, I'm going to start a new design project. I got to do a project plan. It's in the regulations.
I'm going to take a template from my last project and just copy paste and change the names and then I'll, then I'll email the manufacturing guy in a couple months. That's the wrong way to do it. And it seems again, very common sense. But I think if you make a very concerted effort to start early with the whole team, let everyone kick it off, maybe even just have a brainstorming session about, here's the design we want to build, let's talk about it.
And you'll get a lot of very good Advice there.
So that's the first thing that cross collaboration that you brought up is very important. I think just understanding the definitions is very important as well. I know when I started, I jumped right into my job, and I had a binder of SOPs like everyone when they start their new manufacturer or medical device job.
And I skimmed through them a little bit pro, probably not as well as I should have, you know, And I never sat down, I never looked at ISO 1345, I never looked at FDA part A20. I never read about user needs or design inputs or outputs. So, you again, just kind of take old examples of design matrices and kind of copy paste pull things.
I think it's better just to start from scratch and to look at the definitions because what I learned later on, you know, user needs, they're pretty general, they're vague, they come from marketing, they come from sales, they can come from engineers. Right. But they should come from the field. User needs are what exactly does the patient, the surgeon, the nurse, whatever clinician it is, what do they need out of this very high level. And then that's where the engineers come in and the design controls really starts.
I'd like to say, I guess is you take those user needs that are generally, and more user focused and then you have to put them into design inputs which are very measurable,
quantifiable, they need to be tested, you need to make acceptance criteria. If you can't have acceptance criteria, it's not design input. Right.
Outputs are where I see a lot of people mess up outputs. Sometimes like the inputs kind of blur into the outputs and vice versa. But outputs really are the final specifications.
The drawings, um, the, the models, the work instructions.
We like to say at Greenlight Guru, the outputs are the recipe.
Um, you should be able to hand the design outputs to somebody and all the associated documentation and they should be able to make that product.
And so, I like to think about it like that, like, could I hand this to somebody that knows nothing about this project, and they could make this and then verification, validation, everyone knows that's testing, I think where people mess up, definitionalize, you verify your inputs, you validate your user needs. So, you don't want to cross those two things. Right. So, verification is more that bench testing, internal testing, material testing, testing per the standards, most standards, I'd say. And then validation is clinical or simulated use or things like that.
Etienne Nichols: Yeah, I know you covered a lot of ground. I'm going to go back to one of the very first things you said and that was you think Sometimes it's better to start from scratch with those design controls.
And I wanted to highlight something about that because, you know, why do we like to copy and paste those, you know, from, from this DHF to that DHF. It's really because we think that one got through.
Right? That one got through.
So, I'm just, this is just a, an exercise I'm going to do to, to, to get this one through. I've already done the design in my mind. I've already done all the hard work, the, the engineering R and D and product development and now I just got to get this paperwork done.
Really. That's, I think that's what a lot of us are thinking, whether we admit it or not. I don't know if that's your thought.
Tom Rish: You got it. I, I can't tell you how many people I've talked to that have said, you know, I don't know if the medical device industry is really right for me because there's too much paperwork.
And I think what you said is exactly why they think, you know, I have to have these matrices,
I have to have certain documentation to submit to the FDA.
What's the easiest, fastest way, least amount of work that I can do that. And it's copy paste.
It's not the right way though. Right. And we have a lot of responsibility as engineers, medical device specifically to do things right and especially the higher risk than our devices are.
And so that's why I like to encourage people to start from a clean slate, I think. Not just because it is the right thing to do, but because you're going to come up with better designs if you think about things a little bit differently.
Differently maybe than others.
And you don't just copy and paste things. So, I think that you know what I found software like Greenlight certainly helps, but even in an Excel based design matrix, if you just do little things from the start, it feels a lot less like paperwork because we all know that we wait till the very end and then we have this huge matrix. We have to build it, we have to rush, and it very much feels like paperwork. So, we always say build as you go.
Start small, work your way. Plus, if you start documenting user needs and inputs early, it's just going to help you with like what tests you should be doing. And those tests are always the long lead items.
So, like get those done early.
So, I went off on a little bit of a tangent there, but I really do like that.
Don't think of this as paperwork, think of this as a true design process. You're an engineer. That's what you went to school for. Let's do it. Right.
Etienne Nichols: Yeah. And that one of the other things that you kind of mentioned without saying it was the tribal knowledge. When we transfer something, just copy and paste, we're really almost solidifying tribal knowledge. So, when I think I'm going to take this, this DHF and some of this stuff, I just assume it's good.
And so, I'm going to move it over here to my project and I'm just going to tweak the things that I want to tweak.
I don't always know why that was the case with those other different aspects. And so, it's really turning that tribal knowledge into rock solid tribal knowledge that no one's ever going to be able to reverse engineer or potentially so.
Tom Rish: Yeah, yeah, I agree. And I think you said something important where you said the hard stuff. Testing, designing, getting a good design. That's going to work. Right. That is the hard stuff. And you're thinking about all this stuff in your head while you're doing that. Right. And so why not write it down when you're thinking it so that you don't forget it, you don't lose that tribal knowledge.
But the paperwork's not the hard part. People think it is, but it's not. The hard part is designing.
And that's why we're all very. That's why, like an engineer, if you made it this far, you're talented, you can do the hard stuff, make the paperwork the easy stuff and do it as you go.
Etienne Nichols: Yeah.
So, another question I might have would be any. What specific challenges have you seen in your career or maybe even recurring challenges that you see customers have to know. You work with a lot of greenlight guru customers as, especially as it pertains to design controls.
What are some of the specific challenges that you see?
Tom Rish: I think the obvious, just from a procedural standpoint, they wait too long.
That's common. We've just, we've touched on that a lot. So, I don't need to harp on that. But starting early is very important.
I would say they don't.
Not reading the definitions is another thing. I, I look at a lot of matrices where those inputs and outputs are mixed up, where they might say something like, they might say like, the handle should be blue in your inputs or something like that. And then in the outputs they say, visual check the handle is blue or something like that. You know, that's not really right. This, the output is maybe the exact type of color that it is the what type of ink or dye or plastic material or whatever that might be, you know, So I see a lot of people just have very vague inputs and outputs, and that causes problems a lot.
And then from a testing perspective, I think that, you know, a lot of times people have in their head what types of tests they want to run ahead of time. They don't let your inputs and your user needs lead you to the right test, right?
So, they have, like, they kind of do their inputs in a silo.
They do their user needs in a silo, and then they're like, well, we got to do all this testing anyway. And then they try to, like, connect the dots between them all.
But really, if you're doing it right, like, as you list out user needs and design inputs, you're basically building a test protocol of what you should be testing. Right.
And so, I like to encourage people to kind of, as you're thinking about user needs and inputs, maybe start writing down lists of tests and start with a blank slate instead of maybe thinking like, oh, here's all the tests we did last time.
Etienne Nichols: I wonder, you know, I just think about the. The challenges that we face with this, especially when we do look at it as just paperwork and save it to the end,
and ways we can make it a little bit more, I don't know, approachable. I don't know what the right word is exactly, but.
Excuse me, but one of the things that I was thinking about is how do you tap into that engineering mindset to where you get those pieces on paper?
I'm just gonna. I'm gonna just kind of use the example that I have in my mind for whatever reason. But when I'm using SolidWorks, for example, if I want to extrude a part, attach another part on, and so forth, and I just keep going and keep going at fillets and so forth.
I don't necessarily go over to the tree and start labeling it like I should every time, but if anyone else ever sees this design, they are going to think, wow, what a sorry engineer.
Tom Rish: If.
Etienne Nichols: If they. I don't even know how to roll up the tree or see anything like that. Understand what I'm talking about?
Tom Rish: Yeah, with.
Etienne Nichols: With that. But it's sort of similar if. If you just.
If you wait to the end and someone is going to be looking at that, that's another thing to be thinking about. And maybe that's another question I might have for you.
How do you.
Who needs to be looking at the design controls and when.
Any thoughts there?
Tom Rish: You know, So I do think this kind of comes back to like waterfall versus more agile methodology. Right. Like the medical device has just traditionally been very waterfall and that's all I've used.
And I'm, I don't know a lot about agile, but I do know with waterfall it worked. So, I don't, I don't want to bash it, but we had very big milestones, maybe 3, 4, 5 throughout a project.
They were those design reviews, they were manufacturing, transfer, things like that. And we did so much busy work that was stressful the week or two leading up to those big milestones. And so, the agile methodology coming to greenlight, learning more about software and software as medical device.
I do think there's real value in splitting things up into smaller chunks and doing them at more frequent intervals, you know, So I think maybe adapt adopting more of an agile methodology and doesn't have to be like full blown, but maybe instead of having four design reviews, have eight, you know, and maybe the first design review, instead of covering both user needs and design inputs, have a user need design review, have a design input design review still pretty waterfall, but splitting it up and making sure everyone's there.
And it should be those manufacturing people like we talked about, the marketing and salespeople, they're so valuable for certain things, especially with user needs. They should be there. Your regulatory team. A lot of times I remember, especially at bigger companies,
you just throw all your DHF stuff over to them at the end and say, hey, submit this. Figure out a way getting them involved early so that they can also build submissions as they go.
It's just splitting things up into shorter chunks and inviting everyone. It seems like it's going to be a lot of work, but I guarantee it saves time. Going to hit your deadlines, save you money in the long run.
Etienne Nichols: And I want to add on to something you're saying because I'm, I just try to put myself in the perspective, okay, so I'm a business owner. Am I going to go for an additional or even double design reviews?
Because I think that's when everybody's away from the computer all in the same room. Is that really value added? And I, I am on your side. I definitely agree, but I, when I kind of put my project manager hat on. For those who don't know, I was a project management, I had the PMP from PMI. So, when I think about that design reviews, what's the difference in a design review and a stage review?
Because we use them interchangeably in the field, so maybe that would be helpful. To make a distinguishing there.
Tom Rish: Yeah, you know, I like where you're headed because I mean, like just change the names of things. Maybe call it a team meeting, you know, because. Right. You have to have one, at least one design review per the regulations. Right.
And I think that a lot of times people use stage reviews and design reviews interchangeably, like your company's.
Mine certainly did.
So, I don't think there's necessarily like a hard and fast differentiation between them, at least in my experience.
And so that's why I do like using different terms for different things. Like maybe your phase one, you have some different stages that are much smaller. You're probably having project team meetings anyway.
Repurpose those and use them more than just sitting there and talking about things like use them as a working session. So, I think that names have certain connotations probably in every industry, but certainly in the medical device industry.
And let's get creative about changing up the name so that people don't get so uptight about it. Right.
Etienne Nichols: Oh man, we better be careful. We just, we're working on changing the entire.
Tom Rish: You just have to have one design review at least so that when the inspector comes in, you can say, oh, here, here's one.
Etienne Nichols: Yeah, kind of where, where I'm head, my, my brain was kind of going down the path of if you have most companies that I've worked with that have a waterfall process, they have that, they call it probably Stage 0 or, or Design Review 0, where you have your planning session and they review all the planning documents.
But then you get into the, the additional design reviews and you even have things like your manufacturing plan, your IQ OQPQ, the, the master validation plan. So, things like that, which aren't necessarily required for a design review.
If you're just going with the FDA requirement for a design review and correct me where I'm wrong, you know, if I slip off the rails here, but if you were to just, just use that design review from the actual definition of a design review, like the, the regulatory requirements, you could have multiple those design reviews where you're just focusing on design controls and then your larger stage review for each stage that you want to. Yeah. Define.
Tom Rish: Yeah, I, I, yeah, you, excellent point. Because what, what's happened is our design control process into like an entire project planning process. Yeah, so I see what you're saying and I, yeah, it's almost like you could have a sub system underneath your project plan that's just design control related and I really, really like that because design controls don't get the attention that they really should. And I think part of it is maybe because their process got hijacked by everything else.
Etienne Nichols: Right, Project managers.
Tom Rish: Yeah.
Etienne Nichols: Okay, sorry. I get excited and I start messing up my equipment.
Tom Rish: Can you hear me? I can still hear you. Yeah.
Etienne Nichols: Oh, man, I can't believe it. Okay. One of the things that I wanted to ask because kind of went off on a tangent there and that's my fault. Project manager coming out.
But did you. What were some of the things that really helped you see how things work? And it did. Like, I don't know if you got to go see surgeries or see any field ops.
Did any of that play into a role in how you approach design controls if you did get to do those things?
Tom Rish: Yeah, it, it definitely did. And I did. And I. That was one of the really cool parts about working in the medical advice industry. Right. You get to see your, your work in action and, and see the impact that it has.
So, I would say a lot of our validation activities were like in cadaver labs or using saw bones or other simulated type device settings. And it was so cool to listen to the, the doctors and associated staff just kind of talk about your device.
They didn't know it was your device. Right. And I've had many situations, like I'm sure many of us where I've been in a cadaver lab and a surgeon says, who designed that? This is. This is like the worst thing in the world. And I will just be like, I don't know who designed that one, actually, I'll have to go back and see.
But they, that though, is a good thing because it really forces you to think and like, yeah, you know what? That wasn't good. I overthought that or I over engineered that.
It seemed cool at the time. But these surgeons, they have a job to do, and they have to be efficient, and it has to work right?
And so, I think just listening to them asking questions, that's one thing we talk to gurus about all the time. It serves you so well in every industry.
Just because you're the engineer that owns that design doesn't mean you have to act like you know it all right? Like, or, or you have to feel like you to have everything under control,
ask a lot of questions. People like to answer questions, and they like to help.
And I think asking the doctor's questions when they were using it, like, do you like that? Do you not like that? Things like that. You want to get that advice.
If you stayed quiet and just kind of crossed your fingers Hoping that it worked. Right.
So, the, the, the validation activities are so very good for getting feedback. The field certainly too like it's, it's fun to watch it in action. You get a, it's a little more pressure setting.
Right. So, you can'. Jump in there as much. But I would say doing those and then, you know, going to visit suppliers and going to, to visit the manufacturing floor just to talk to people was helpful. I know you and I have talked in the past about just building connections with different types of people can serve you very well in your career.
Etienne Nichols: Yeah, absolutely.
You know, I was just thinking when you were talking about the surgeon, maybe not liking your design or, or liking it instead of just twiddling your fingers kind of made me think, kind of what I got out of what you're saying is, you know, we as engineers, we like to look at our product and say our product is good. You know, it's so good, we worked so hard on it. But what we're not really, we're not, we shouldn't be focusing on the product.
We should be focusing on the pain that they're experiencing or the problem they're facing.
And really is, is this thing, did we solve that problem? Really all we're offering is a solution. I, it always funny to me when we, you know, talk about software as a solution. You know, this, do you like our solution?
Which is a strange way to say, but it honestly that's, that's an accurate way to say or it should be.
It's kind of what I'm getting out of what you're saying. We should be offering a solution, not a product.
Tom Rish: Yeah. And that's exactly what, you know, user needs and the design control process, it is trying to help you do. Right. I think one of the questions that I learned when I came to Greenlight, and people have probably seen in our blogs is user needs is did you make the right device for the situation?
Right. And then the inputs are more did you make it right or the right way? You know, so like user needs, if you do them right and they're not a check box activity, you're, you're really trying to identify what's the pain, what's the problem and do we make the right thing for that problem and thinking that way, like I said, I, I really truly believe that all engineers are thinking this already.
But they're not connecting it with design controls. They're kind of that on the side and then design controls is this, it really is not a helpful activity. If you don't tie Those things together.
Etienne Nichols: Yeah.
One thing that popped into my head too, when we were talking about going into the surgery, surgical units or. Or things like that, that's an opportunity to validate little V. I've used this little V. Validate your user needs with those surgeons to make sure that you're actually solving the correct problem. It's not the true big V validation activities, but every time you get to talk to somebody who could potentially be using your product is an opportunity to validate your user needs.
I don't know if you have anything to add there.
Tom Rish: Yeah, I totally agree. The big V is the entire thing. Right.
However, what we said earlier, if you have a list of user needs, you have a protocol essentially, right. Like when you go into that lab with a surgeon or you go to whatever clinical setting, you should say, are all of these things getting checked off?
And in fact, we had a list that our surgeons would check off and sign at the bottom. Right. Like, wow, could you. Could you.
And they were our user needs, or at least they should have been. Sometimes we probably didn't do it as well as we should have, but.
And it would be like, could you open the instrument? Could you clamp on the.
The bone where you needed to? And things like that. And they'd have to say yes or no. So, it's exactly what you said. Those little.
Those user needs, all those little validations build up to the big one.
Etienne Nichols: Yeah.
So, you mentioned going to the manufacturing floor. What were some of the things that you might have asked or looked for in those situations? Anything come to mind?
Tom Rish: You know, I think the first thing really is not even engineering or medical device related, that a trust between the manufacturing team and the engineering team is needed very badly. And, you know, when you start as a new engineer at a company, you often, the manufacturing guys, a lot of them had been around for a while and they were super smart. They knew what they were doing.
They didn't always go to college. So, they were like, I don't want this guy with a college degree coming down here and telling me what to do. And I do not blame them one bit at all, you know.
And so, I think I was nervous, though, because I was like, these guys don't want to listen to me. They know better than me. So, I think the first thing I learned was just talk to them, like, ask them questions about their life, get to know them, ask them how long they've been doing this, what products they've worked on and things like that. And that really helps to build a bond, you know, and then as you do that, people open up more and you know, they, they really.
A lot of my designs were really those guys designs because I would go down there and say, hey, this is what we got to do. I want to make that we can design that we can manufacture this design.
And usually by the end of a couple hours, sitting down there with them, we had to come up with a whole new design that I could take back up and start trying to put into SolidWorks, you know, so it's like I can't even, I can't even put into words how valuable it was to go down to the manufacturing floor as an engineer.
And then also the more tangible effects are like we had better design reviews; we had better manufacturing factoring transfer. Our drawings had less changes to them because we were looking at all this stuff ahead of time.
Etienne Nichols: Yeah. And it's interesting to think about. It's just kind of jogging my memory going back. I remember one guy named Anthony.
Tom Rish: His.
Etienne Nichols: He ran a 7 axis CNC machine, and I didn't even know what the 6th and 7th axis were at first, you know. So, I'd go out there and I talked to him some and I needed something built.
Well, if you'll pardon me, just a story real quick. But so, I went out there, he's like, well, I've got a whiteboard over there and we use. You could put an A priority, B priority or a C priority.
And you know, we kind of work through it in that order. I'm like, okay. So, I went over, I'm like, well, mine's probably a C priority.
So I go out there a few weeks later go out there, I'm like, hey, how. You know, I saw several things go through, but, but my C priority, you know, my, my stuff.
He's like, oh, well, see, a priority means it needs to get done today, it's really important. B prior priority means it's really important it doesn't have to get done today.
And I said, well, when does this, when do you get to the C parties? Like, I've never done a C priority.
They will mess with you all day long.
So, they do.
Tom Rish: And it is fun. And like some of my favorite professional connections are guys that I met on the manufacturing floor. And I've learned so much more than from them that I did in four years getting an engineering degree.
Etienne Nichols: Yeah, absolutely.
Well, any other thoughts that come to mind when you think about design controls and how we can maybe help people through different pitfalls or overcome certain challenges? Any other thoughts come to mind?
Tom Rish: No, I think the biggest takeaway for me on design controls and what we try to tell our clients is use the process strategically.
Like we talked about, don't do this at the very end. Don't do it in a silo. But the design control process, for as annoying as it can be to follow regulations, it's there for a reason. And it's what any good engineer does in any industry.
They might not have to document it as strictly as we do but use that process to your advantage. And that process is get the right people involved early, have productive meetings that cover a short amount of information versus long amount of information,
and work together to build as you go instead of trying to do it all at the end. And those are probably the biggest takeaways. And I think that's one thing.
When I was in the industry, I did not like design control. That felt like paperwork. It was no fun. And now I work with customers, and I don't know that I can say it's fun.
But we enjoy doing design controls together because we start early, we, we document, we do it in greenlight, and it's, it's, it just not feels like paperwork, and it feels like you're moving your company and your product forward.
Etienne Nichols: And I'll just kind of highlight one of the things you said. Every industry has something like this, whether it's in the engineer's head or it's actually on paper. The, the best products have some sort of flow like this so that other people can see it and say, you know, kind of ask questions and make a better product.
Tom Rish: That's, that's, that's what I tell people all the time. Like Apple, you know, and I know they're starting to do some medical device, but before that, you know, when they're building iPhones, they have a process that they follow because they have good design, they're efficient, they get out on time, things like that.
At least they used to. I don't know if they still do.
Etienne Nichols: Yeah. Well, thank you so much. I really appreciate it, Tom. This has been a fun conversation for me. I'll let you get back to the rest of your day. Those you've been listening, you've been listening to the Global Medical Device Podcast, and we'll see you next time.
Tom Rish: Thank you. Have a great day.
Etienne Nichols: Thanks for tuning in to the Global Medical Device Podcast. If you found value in today's conversation, please take a moment to rate, review, and subscribe on your favorite podcast platform. If you've got thoughts or questions, we'd love to hear from you. Email us at podcast@greenlight.guru.
Stay connected for more insights into the future of MedTech innovation. And if you're ready to take your product development to the next level.
Visit us at www.greenlight.guru. until next time, keep innovating and improving the quality of life.
About the Global Medical Device Podcast:
The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.
