Member profile: Kyle Woodard, mechanical engineer
Kyle Woodard is a mechanical engineer at informal who specializes in the design and engineering of medical devices. He’s well versed in the FDA approval process and the intricacies that come with it. Kyle is an avid DIYer, having renovated most of his house on his own and having converted a Ford Transit into a campervan with his father-in-law.
Besides ones that you’ve worked on, what’s your favorite product? Why?
My favorite product is probably the beverage can. It’s ubiquitous in our lives and a seemingly simple container, but its production is incredibly complex. There are many operations involved: forming, drawing, coating, etc. In addition, the opening tab is actually two types of levers. It’s a type 2 lever when you’re depressurizing the container (the center of the tab is pulled upward to relieve C02 pressure), and then it becomes a type 1 lever afterward to open the tab.
What do you wish you knew when you started out in your career?
Everything! Especially how much school doesn’t prepare you for the real world of product development. It’s one thing to learn some of the technical information, but it’s another to know how to navigate collaborating with a multidisciplinary team to get a project out the door.
Thankfully, I went to a school that had a co-op program, so by the time I graduated, I had almost two years of experience working with various companies. That really helped make the transition from an academic environment to the real world an easy one.
When working on medical devices, what specifications or nuances do you need to keep in mind in terms of design and engineering?
I think the question answers itself! It’s the specifications you need to keep in mind.
In medical devices and ISO 13485-driven development environments, requirements are key to develop the device and mitigate risk. When starting to develop a medical device, the team doesn’t necessarily have to have all of the requirements laid out. Some things don’t become requirements until early prototype testing reveals some item that was previously unknown. Sometimes, the team knows the device needs to do something (like transmit X lbs of force), but you just don’t know what X is. Sometimes, risk analyses reveal some item that needs to be mitigated, so a requirement is added to address that risk and ensure it’s mitigated successfully.
From my experience, it’s generally a recipe for success to lay out the requirements early, even if there are a number of “TBDs” for that requirement. As a team goes down the development path, those TBDs will get filled in as the team better understands the design and its fit to the use case. In addition, I’ve been on some projects where a multidisciplinary team is taking the time to review and sign off on the requirements. This helps ensure device performance and also helps ensure that different disciplines won’t be stepping on each other’s toes to achieve the spec.
Another big thing is to find out all of the governing standards for the product you’re developing (anything from ASTM, ISO, AAMI, IEC, etc.). A regulatory assessment will help uncover a number of these. But these documents are key to understanding and making sure your device achieves the requirements set out in all of these standards.
What are the biggest issues/insights that you see when clients are going through the FDA approval process?
One of the biggest insights I can provide is to leverage your contacts and reviewers at the FDA to help ensure that your strategy and approach to development and approval is sound. This is especially key on more novel devices being submitted via De Novo or PMA approval pathways. Losing time and money due to a rejection in the approval process can set back projects, so work to ensure that when you submit to the FDA, it’s more of a formality than “hope and pray.”
What challenges do you find when working in hardware?
Never assume anything is a given until it’s tested and proven out. Assumptions can sink development pathways very quickly. I always find myself saying “trust, but verify.” Also, the tiniest thing can cause something to go wrong, and it’ll take days to figure it out, which will throw off timelines. This is especially true in early-phase development.
For example, I had a project where I had a fluid system gaining pressure during the course of a process cycle (it was supposed to stay flat). This started happening after weeks of system testing and right before delivery of the prototype to the client. Turns out I had a vacuum leak in the system due to a small piece of Teflon tape getting lodged in a 3-way valve and the system was slowly sucking air in. It took me two days to find that particulate that measured about 2mm X 2mm.
We’re always looking for engineers, designers, brand strategists, and writers to join our team. If you’ve got a skill that you think we need, send us a message! We’d love to chat. And of course, if you’ve got a hardware product or product idea you want to bring to market, we have just the experts to help!