What to Expect from a Successful Medical Device Product Development - Webinar Recording

What to Expect from a Successful Medical Device Product Development - Webinar Recording

Show Video

[Laurie Actman] My name is Laurie Actman with PCI. Thanks to everyone for joining us today to welcome   some fantastic speakers about developing medical devices with a really neat company called Triple   Ring Technologies. I'm sure we'll hear more about who they are from our speakers, but they work with   early stage ideas on co-development. But I don't want to misspeak about   how you do work. But I'd actually love to introduce my colleague Pam Beatrice who   directs a lot of our licensing activities in  Penn engineering and some of our other schools   here at Penn to formally introduce you to kick off the program. Welcome Pam. [Pam] Thank you very much Laurie. 

And I want to also extend a very warm welcome to David and to Roger. I had actually   heard the beginning of your talk that you  gave back at UC Davis a few months ago.   And I then immediately suggested to Laurie that she reach out because I thought it was   really interesting and so one of the things  I'm really looking forward to is, this time,   being able to hear your entire presentation.  Because I was not able to do that last time.   So I'm going to give a brief introduction for  both of you and so Dr. David Shack is the  

Vice President of Product Development at Triple Ring Technologies where he focuses on optimizing   the technology translation process from technology development to product development to production.   He has held senior engineering physicians at BD Biosciences and Agilent   Technologies and he has also had significant work leading product teams for startups.   He has a very broad range of experience in multiple analytical areas,   a few of which are atomic force microscopy, x-ray fluorescence, flow cytometry,   algorithm development, software development, fluidics and optical measurement systems.   He received an MS and his PhD in mechanical engineering from Stanford. Dr. Roger Tang currently leads the science systems and engineering teams at Triple Ring Technologies.   He has previously managed the research group and ideation activities at Molecular Devices LLC. 

He has also worked for the startup Signature Bioscience where he developed   some of the first label-free assay technologies based on bio-impedance.   Prior to that he was an assistant adjunct professor in radiology   at UCSF where he focused on cancer imaging. He has a PhD in bioengineering from the joint graduate   group in bioengineering at UC Berkeley and San Francisco and with that I would like to   hand it over to our speakers. Thank you very much. [Roger] Thanks Pamela. Thanks everyone for inviting   us. We're happy to be here and hopefully get a chance to teach you a little bit about or   hopefully get a chance to learn a little bit  about the way we think about product development.   Without further ado, just a bit before we jump into that. A little bit about Triple Ring Technologies.  

As mentioned before, we are a co-development company and we think of it as a partnership with   the folks we work with. I'll just read this here, but it's very, what we do is we   help science driven innovators, entrepreneurs and companies, both small and large, realize their   vision and achieve commercial success by taking all of our talented resources, both people and   capabilities, our unique processes in our venture studio model and our venture studio structure   and what we do is we apply those tools to solving hard problems,   launching breakthrough products and then  ultimately, in some cases, creating new businesses.   We're primarily in the life sciences, medical  device space and these are just some   quick examples of the kind of work that we do. Right here in the middle is   our marijuana breathalyzer. So a THC detection system for the roadside  

detection of marijuana in breath. The system here is a disposable operating room unit   for basically looking at tissue oxygenation and tissue health in real time in the operating room.   Example here on the lower left, this is an x-ray radiotherapy system. We developed x-ray sources   and the system to do that. And numerous other examples. Like I said before, we primarily work,   90 percent of our work, is in the medical device and life sciences spaces and thus we work in   regulated markets. Since day one, our company was founded about 17 years ago. So without further  

ado, let's get into it. I don't know how  familiar you guys are with the sort of the 21 CFR 820 rules  around medical device development, but  it's pretty thin, it fits in a pamphlet like   this that you can put in your pocket and you can read through it and understand what the rules are,   the official rules are, for developing a medical device. It's so terse that the FDA   has come out with design control guidance  for medical device manufacturers that sort of go   into a little bit more detail about what's in here. And from their perspective.   One of the key diagrams in this design guidance is the famous waterfall plot that I show on the right.   Everyone seems to think of the design process as something like this, a linear process where   you define user needs and ultimately at the end have a medical device that meets those user needs.  

Now if you look at this, they call this the  waterfall and it looks linear. It looks like   it's a simple process from step one to the end and therefore you have your product. And what   lot of companies do is they sort of think about this in a traditional product development model.   Again, this famous phase gate development process is where you go through a very rigorous process   of making sure you finish what you need to do from a concept perspective, planning perspective   design perspective, ultimately launching a  product for the customer. We often refer this   as a phase gate development process or a design build and then test process. Now in this process   you often hear terms like "fuzzy front end" and when you look at fuzzy front end, there's danger signs   that should go off. At the fuzzy front  end, there's a bunch of unknowns that you hopefully  

will start to resolve as you get into the actual product development and what the mentality   is the difficult technical work that's done during design and test. Now anyone   who's done this for a long time realizes that  there's inevitably a loopback in this process.   There's something that you find out in testing the system that doesn't quite work  right that you have to go back and redesign. What really happens though is that it's  

really much worse. So sometimes things get caught in the launch phase of a project and that loopback   really hurts then. But the one that really,  really hurts of course, is if your customers   find the problems. The customers find the problems - it's a disaster for the product.    So how do we flip this mentality? How do we basically think about product development a way where we can try to avoid this if possible. And what we really want to do and what we try to  

tell folks is you really have to do all the difficult work up front in terms of   analyzing and test before design. And the concept phase is not about, "okay well here's maybe the   product requirements and then let's start designing" but really have an iterative   phase where you think about the concept, you think about what needs to get done, and really   do all the hard work up front. And then therefore, the later stages of the project end up being   a smooth linear flow without any loopbacks. For those folks who

are into lean and agile, there's a sort of a similar terminology here.   Sometimes we call this agile lean. Sometimes we call this knowledge driven. But it really is that   plan-do-check back loop that you see in the lean agile world that you really want to do up front   and get all that difficult work done as early as possible in product development.   Now I can say these things but what really, really makes this stick is if you think of a really good   example and we're going to take one that's not in the medical device space, not in life sciences   space but one that we all may know and this was really credit to Ron Marsiglio who really   told me this example and really illustrated   the mindset about a dozen years ago to me. And it's the story of the Wright brothers. Now as  

all of us know, the Wright brothers conquered manned control heavier than air powered flight   when a lot of people around the world were  working on the same problem and failed.   Now we all know the story. There were two brothers working out of Dayton, Ohio. They were bicycle sales   and repair folks by day, aeronautical engineers by night. I suppose with the high school education  

and they essentially did this part-time over  a four-year period which is amazing. So how did   the two brothers from Ohio succeed when there were others who were more educated and   better funded. Now I'd like to say that they really thought about the process differently, they thought   about doing the difficult work upfront around analyzing tests before actually getting to design.  

So what did they do? So before they designed their first airplane, they don't jump into design. They do   their homework. This is, what do you need me to do? They did a knowledge search. They knew nothing   about aeronautics and so they did their homework. They began with a knowledge search.  

They requested everything that was available about aeronautics from the Smithsonian Institute.    They studied all the lift tables from Otto Lilienthal. They corresponded with all the experts.   They did their homework to really understand what the problem they were trying to solve was, and the interesting thing is, when you look at it, you find those one, two or three really key things   that if I don't solve them, if we don't solve these problems we will not have an airplane. It doesn't   matter. I can jump into the design, but if I never solve the problem of lift, I never understand how   the physics works for lift, but I don't understand what kind of an engine and what the propulsion   needs would be for that, to drive the thrust I  would need for that, I'm not going to be able   to get there. And then ultimately, when the plane gets in the air, if I don't know how to control it,  

there's no point in building an airplane. So they really focused on these three knowledge gaps.   And they closed these knowledge gaps  by performing analysis and doing experiments.   They became scientists. They became engineers. They built their own wind tunnel. They studied hundreds   and hundreds of wing profiles to understand the properties of lift for those wing profiles.   They built miniature models of those things and flew them as kites.   Ultimately man gliders that have the right control surfaces. So they did all that work  

and my favorite quote from Wilbur Wright, and i say this all the time,   It's "non-glamorous lab work that's absolutely critical to the success of a project."   They did a lot of things in the lab, on the bench before they even thought about how they would   design their first airplane, and of course,  we all know the success of December 13, 1903.   The Wright Brothers flew but what's amazing is if you look back, the Wright Brothers wrote to   telegram their father a week beforehand and literally said success is assured, keep quiet.   They knew that airplane was going to fly before they flew and why they did all the things that I take as the lessons from the Wright Brothers and every single project that we look at at Triple Ring  and every single project really starts with  these key steps: understanding existing   knowledge, doing your homework. Really dividing the the things you're trying to do in the key logical   subsystems. The wing, the control systems,  the propulsion, what are the key logical things  

that are a part of your complex system and identifying those one, two or three   key knowledge gaps you absolutely have to close in order to be able to even think about putting   together an airplane. And of course, doing  all the homework analysis whether in the lab   or experiments and analysis on the different components to really ferret out   your understanding of that and ultimately then you design and you build your first airplane. So it's   again about doing all that hard work up front. So that when it's time to fly, you will fly.   And with that, I'm going to go switch to Dave who's going to tell a maybe, a more related story,   that's maybe more connected to medical device. So i'll stop sharing. Dave? And I'll let you pick it up.  

[David] All right. So as Roger just kind of walk us through, that great example of the Wright Brothers and   sort of leading to that sort of moment where you know one can declare success assured.   But then what? They hadn't designed an airplane. they had closed their knowledge gaps   and so the the task of actually doing their  product development was still yet to be done.  

And so while the key fundamental technical knowledge gaps had been addressed,   there's still a lot that that needs to happen in order to produce a safe effective manufacturable,   serviceable and on and on and on, all the various requirements that have to come into play   to have a successful product. Not just a clever new technology that's been developed. And so a lot of people sort of look at that and  go, well it's from here on out, it's just   engineering. That's never or or maybe hardly ever the case. There's still a lot of   complexity and a lot of risk that still needs to be managed during product development.

But really what we're talking about here and I'll sort of illustrate a diagram that kind of shows this   in a little bit from now, really changing a mindset from learning to doing.   And it's the mindset that needs to change  as well as how the people engaged in   that activity need to sort of shift their behaviors from one domain to the next.   There's always pressure to get to market fast, although i would contend that predictability is   actually more important than raw speed for most organizations, but I'll sort of leave that hanging   in the air. As an exercise for everyone to think about and decide whether you agree or not.   But I think anybody who's been involved in product development in one way or another knows that   things don't always go the way that you intend at the beginning. There's

technical issues that come up, design flaws  or even worse, requirements errors you   don't end up getting on the right path, to design the right thing, and as Roger pointed out earlier   in the session, finding things late is bad and expensive. Finding things in the   hands of the customers is horrifyingly bad and expensive. Working on technical designs that   cleverly implement something that does something wonderful and new is great   but if it's too expensive or too difficult to  manufacture your success of your product is   negatively impacted. And then just sort of the simple underestimation of   what it takes to actually do a product  development. And as anybody who's   done this before, there's those moments near the end when you are realizing that   you're sort of running out of time and money and still aren't as far along as you had hoped to be   or potentially have claimed to be. So what do you do? Well there's a few options. You can keep doing  

things the way you've already done it. Project's late, clearly it's the project manager's fault.   Let's get someone new in there who really knows what they're doing and that   team just needs to work harder and longer hours and surely that's gonna take care of everything. A lot of times, and I've certainly experienced this myself, in some of the organizations I've   worked in, when projects get into trouble, senior management feels   they need to step in and exert more control and more oversight. And so more   reviews, more gates to push the team through, more scrutiny. You can imagine how well   that typically plays out when you're asking teams to be spending a lot more time talking about   what they're doing, rather than thinking about what they're doing and actually acting on it.  

So what we're suggesting here is actually thinking about things in a different way and   actually going about things in a different way. And Roger mentioned the term, agile and lean,   and those are sort of code words for a mindset and an approach that   really kind of gets around some of these typical problems and really allows you   to know what you need to know when you need to know it in order to be successful throughout   the course of a project execution. And it's really changing the way development teams operate.   It's like we said, it's a different mindset and  and the concept that was introduced at the beginning of the talk about using  knowledge and understanding what you need to know   and what are the gaps in your knowledge and how you go about filling those. Really applies throughout and is critically  important as we'll hopefully illustrate here.   So this talk is not sort of an in-depth survey  of agile methodology or lean methodology,   but they're helpful concepts that underpin what we're doing. And as Roger  

mentioned, it's really this iterative loop as embodying an agile   methodologies that allows you to sort of have things  roll forward dynamically without getting yourself too constricted   in a particular design direction. And being  able to make course corrections quickly   by having iterative outputs that can be evaluated and acted upon   quickly. On the lean side, that's less about the learning and more about   how effectively can you be at doing your tasks that just need to be done. And   again it's still managing knowledge and it's still managing the information and data flows that   are important throughout the development process. There's some artifacts, like how do you leverage past work and knowledge and do you have design   standards and roles that you can apply without being overly restricted? Things like check sheets and test driven development, all these other sort of toolbox items that you can apply just to  allow teams to spend less time reinventing   wheels and more time addressing the  key knowledge gaps that have to be done.   So I mentioned this shift in mindset and this isn't new from   what we said before, but just to kind of hopefully make it a little more visually obvious. At the beginning of a project and

going back to the example of the Wright Brothers, when they had the fundamental   technology questions that need to be answered, they had to be in a very learning dominant mode.   What did they not know, what did they need to know? And as time goes by and as you get away   from concept and things start to firm up, obviously you're learning more, so you   need to learn less, but you need to get more things done. And so this notion of a task dominant  mindset and a task dominated approach starts to dominate and you can see that shift over time and there's that success assured point right there in the middle, but still plenty to do as I as suggested earlier on. Okay so to hopefully make this a little more real, we're gonna give a hypothetical story   about a product development project of a medical device and before I get into it I   just want to make sure to give credit to  a colleague of Roger's and I's Aaron Joseph   who who operates as a consultant under Sunstone Pilot was the originator of this particular example and has graciously allowed Roger to continue to use it.   Okay? So just to set the stage, we're  going to we're going to tell a story about a   company that makes and markets infusion pumps and I should say that even though   there's a very specific infusion pump shown in the picture, that's purely coincidental and   not suggestive of anyone associated with this particular company. But they're looking  

to make their next generation product and there's a market desire to make it smaller, lighter,   easier to use, and according to their business analysis, there's a market window   that they need to hit which suggests that they need to have something ready in two years.   And that in order to have something marketed in two years, that really only gives them 16 months of   project time to actually get to the  point of being able to submit to FDA. So before getting this project started,  their advanced research department has come   up with a clever new pump mechanism that will allow them to consume less power,   hasn't been applied in this case before.   Which will again allow them to meet  their market needs of having a smaller, faster,   device, and again, they have a strong need to launch in two years. So we're   going to look at two teams, which represent two different approaches. So Walter's team is,  

Walter's is a very experienced project  lead. He's been down this road many times, knows   what he's doing, knows where all the bodies are buried if you will. He's got all the resources   he needs, both on the technical side and all the other supporting functions, and Walter's going   to follow that traditional waterfall approach that Roger showed you the illustration of earlier on.  

We're also going to look at Grace's team. Grace is also a very experienced project lead, also has a   a well-staffed team of expert people, but she's going to take a different, more knowledge-driven   approach, which we're sort of referring to as our agility approach and this is new for this   particular company. So before we dive in and say exactly how things play out here,   you know as I said earlier, product development is risky. There's lots that can happen   along the way and what do both Walter and Grace need to do   to make sure that the outcomes are what are desired and that they have a successful   product outcome. Lots of risks I need  to go through, all these hopefully these aren't  

sort of shocking or surprising to anybody. But in addition to the technical risk, there's    business related things, legal related things, certainly financial and all of these things need   to be understood and managed. So just one other sort of context setting slide here, not to   dive too deeply into a phase eight  product development process, but just    for those of you who aren't familiar with this, give a brief overview of   the key steps in a traditional phase gate process and of course coming   in with a concept and going through  the initial planning, setting requirements, and   understanding the key risks. And obviously going through cycles of design and development   ultimately deciding that what you have is what you should have, and verifying that's   the case and that all your requirements are met and then ultimately into pre-production   where validation, clinical testing,  human factors, basically assuring yourself   that you actually built the right thing. And of course, all the steps associated with setting   up manufacturing processes and getting those transferred into the factory. So with that as  

a backdrop, let's see how this goes here. So we're gonna step through a few key   times in this project and so we're at the beginning and Walter's team,   as they should and as they've done  many times before, has begun setting out   a very detailed project plan. Getting all their product requirements established and elaborated   into system and subsystem requirements and performing their hazard analyses.  

Grace's team is going to take a different approach. They're going to do project planning   but they're not going to get into the weeds of having a several   hundred line gantt chart. They're going  to look at the big moving pieces and how best   to go after those. They're going to be looking at their requirements too but taking more  

of a preliminary approach and seeing  what the key things that are going to guide them   need to be. They're going to do their hazard analysis as they should, but they're also going   to start looking at what their key knowledge gaps are, they've got new pumps, new batteries, and   I didn't mention this before, but there's a desire to have a new simplified UI.  So they're going to really try and  understand what potential issues   are going to arise because of the  introduction of these three new elements.   Except all that's pretty expensive. They're ramping up a team much,  

much larger and much faster than Walter's team is. As they start to look at all these things,   and so right away, there's some cost associated with taking this approach. So let's step forward three months. So we're a quarter into the project. Walter's team has  

got their project plans in place, they've got all their requirements in place,   and they pretty much met all their requirements to go   through their phase gate, their first phase. Grace's team isn't anywhere near that. They've got their high level project and requirements   and they're in hot pursuit of closing all  the knowledge gaps, but they're spending a lot   of time working on that in addition to their sort of analytical and bench work. They're taking trips to hospitals to observe users, the software team has actually   been ramped up and they're making these small, iterative wireframes to   be looking to have things to be able to  show and tell both internal and some of these   external users. So again, from an outside perspective, they're really quite  

behind. And so let's maybe take a step to the side and think about that for   a second. So most organizations, the management of those organizations, are   really used to having checklists of things. You said you're going to do a phase one and how  

long is it taking you to do that phase one? Are you done or you're not done? We know how   these things usually go, so we know how to typically plan for small   amounts of resources at the beginning that kind of ramp up in the later stages. We want   decisions, we want people to hone in on a design and really get moving. So we can    show progress either internally or to  the outside world. So what we're proposing here is   actually running counter to a lot of this. Just to highlight that there's  

headwinds to be able to do this and  how do you get a company to actually support this. So let's jump ahead again with that in  mind. And now we're three quarters gone by.   Walter's team has jumped out of their  phase one gate and and gotten a   lot of traction on their design. They've done all their hardware, they've built a prototype,   the software team has some code that they're integrating with the hardware, they've done their   risk analyses for the design, and they're starting to figure out what kind of   testing and how they're going to do their testing and they're already preparing all the   design artifacts that they need to get through the second gate. Grace's team has finally finished testing the new pumps as well as the   batteries. In doing their testing, they've  actually had some latitude to explore   some alternative designs. The software iterations that they've done have allowed them to  

do some formative human factors tests and gotten a lot of good feedback from the users   that they've contacted and now they finally hit their gate one completion.   So they're a full phase behind Walter's  team. So why are they so far behind?   Well, they found some problems and they've been spending a lot of time working on those problems.   Turns out that there's some reliability issues with the new pump mechanism that were unknown   previously, and that after 3,000 cycles,  they're starting to see some significant failures.  

The batteries were great in the hands of the advanced development team that   came up with them, but turns out when you pack them in a small enclosure, they   start to overheat. And also the user feedback on the user interface actually was not   so good for the first couple of times out and they've been able to react to that and   come up with a third iteration that is starting to gain some traction and some acceptance. So now we're getting into the second half and see how this all plays out. So we're a 

quarter into the second year so getting  toward the home stretch here.   Walter's team, who says "we're coming up on their phase two. They've done that."   They're doing their integration testing and now, just now, they're   starting to see the problems that Grace's team had already encountered   and are looking at alternative designs to correct those.   The software that's coming online, there's still a lot of bugs and   the software team is really needing to get on top of those so that they've got good   working code. And they're really not able to get that software in front of potential   users to be able to do their human factors testing until all of that has been stabilized.  

But they are making progress and they are getting their VMV protocols written and   starting to get moving on their manufacturing process development. But of course, these are the   problems that are here and they're not going away and Walter's team as you can see   is only discovering these things very late in the process. Grace's team is also, because they had a jump on understanding where the problems were and were   able to correct those in a timely fashion, they're now pulled even with Walter's team and  have done their phase gate completion for the second, for the development phase. They've   gotten all their design verification  completed, including their certification testing,   and in fact, they've even been able to go ahead and get their   third gate completed and they're now  preparing for the validation testing in phase four. So maybe to look at this from a   different angle and looking at   a map of the number of design issues over time, you can see Grace's team, they all   ultimately encountered the same problems, but Grace's team found those problems a lot earlier   and before too much was set in stone or that too much time had been invested in sort   of pursuing designs and evolving design to a higher level of completion.  

And we're able to correct those a lot faster. Or you can see Walter's team didn't find   those errors until much later than Grace's team, and in fact, because it's late, it's more expensive   both in time and effort to be able to correct those because there has been a lot more invested   in where they've gotten to. And so what we're contending here is   that this different mindset and the application of agile - lean methods really are there to encourage the early  identification of issues, and equally   importantly, the early rectification of those issues. In the traditional approach,   most of the problem solving activity happens near the end, and I know we've said this multiple times,   but that's absolutely the worst time  for this sort of thing to be happening.  

And as you can see in this example, Grace's team comes in on time. Walter's team is 40%   over time. So the moral of the story, is you might guess here, is that there's always risks and there's always issues that come up, but really being able to focus   the early efforts on identifying those risks, uncovering problems and then correcting those   is really a much better way of ultimately producing the successful outcome   in a plan and predictable way and generally speaking on time.

All right, so I'm gonna take a quick  shift here just to talk a little bit about   transfer to manufacturing, because I think one of the things that gets overlooked when   talking about product development in general is the importance of transfer to manufacturing and   not just the act of doing it, but how  much upfront effort and how much collaboration   is required. So I'm just gonna spend a couple of minutes talking about some ideas here.   So many of you probably heard about concurrent engineering which is essentially, the   act of having manufacturing people working side by side with development people and    the contention here is that's really  important and that having people side by   side who understand manufacturing who are thinking ahead to manufacturing concerns and issues   and being able to feedback into the development cycle in addition to having   the time that they need to do what they need to do is really important to a successful outcome.   We always want to strive for design  for manufacturability and I'll say   they're the traditional DFM, but there's  also DFx, representing all sorts of   things that we want to achieve designed for reliability, serviceability. As I've noted here  

and on the ideas here really hold true for all of   those aspects, but I'm gonna for this moment just focus on manufacturability.   So the first idea is just that design for  manufacturability really needs to be baked in   from the beginning. It's not something that gets bolted on at the end and   you can imagine going back to the example that we just sort of walked through. If you    have gone through this extensive and  time-consuming and effort-consuming    work to come up with a product design, and then all of a sudden, someone's saying no, you   need to change this and that at the very last minute, it is never a good thing.  

A lot of design for manufacturability is represented as checklists. You use these fasteners,   follow these rules, do this or that and that's good and that's important.   But it's more than that, product manufacturing of real things   that are physical manifestations of a design,   there's variability in parts. There's variability in processes   and what design for manufacturability really needs to encompass is the ability for a given   design to be robust to that variability.  So that you're assured to have   a working high performing product come off of, every single one comes off of, the line   doing what it needs to do and not relying on quality control and   testing the quality in at the end. And that really comes back to a design issue.  

Really more than anything, I mentioned  that you want to have manufacturing   folks side by side with development folks. It's my experience, people who are in manufacturing   think about the world differently than people who are in development. There's a few rare   cases where people equally cross those lines but   by and large, I think the priorities and  and the approaches of the two different   groups of people are different and highly complementary. And manufacturing people are really  

spending a lot of their time thinking about how do I make this? How do I make this robust? How   do I assure that I'm always having high  quality? And not that engineers who are design   engineers don't care think about that, but they have other things that they're focusing on.   So really being able to leverage that expertise in a complementary way is really important.   Cost and other DFX items really need to be considered all the way through. Oftentimes,   designs are very focused on, does it do what it needs to do, and the argument being, well if it   doesn't do what it needs to do, you don't have a product. Well it's equally true to say,   if it's too expensive to make or to meet the market need, you don't have a product   either. So none of these things should be taking a back seat to other design considerations.   Testing's really important. How are you  going to test something and how you design to  

make that testing easier rather than more difficult. It is important. And of course, supply   chain and this is true now more than  it has ever been. You can't build it if   you can't get the parts and thinking about what's going to be available and and avoiding single source suppliers  and things like that, are all sort of   important product development considerations. And finally, just a couple of other thoughts   on transfer to manufacturing. There's an old saying, what do engineers produce? And the right and true answer is paper. Meaning  

all those beautiful prototypes and bench top experiments and everything are great but   it's really the documentation of a design that gets handed over into a manufacturing organization   to be able to actually procure the parts, assemble the systems or devices,   and then test them are what really matter. And everything else is sort of in service to that.   You can see here, some of the details behind that. In order to be able to    get parts and make them, there's all  kinds of design outputs that need to be   produced, and of course, in terms of  building and testing, it's really important   for the developers to have a very big hand in understanding how things are made and developing process instructions and assembly drawings and the like.   So that pretty much concludes my thoughts on transfer to manufacturing. So I'm going to   hand it back to Roger to sort of recap where we ended up. [Roger] Yeah, so going back to the slide that   we started with, we talked about the fact that a lot of people think about product development   as a linear process or a waterfall process. Where you start with needs and there's a  

clear path to the end. But I think clearly  with complex product development there's always   going to be this give and take, this understanding, this learning and loopbacks, especially early on,   And early on with the place to have them, it just has to be a clear recognition of that. And   actually, if you read the design guidance, even the FDA agrees with that. And I think people miss this   phrase, literally in the good design guidance is this phrase, that says, "in practice feedback   paths would be required between each phase of the process and previous spaces representing the   iterative nature of product development" as we've talked about. These details have been emitted from   the figure to make the influence design controls important, so it's a design control framework   not a product development framework. So that's the right way to think about it. So we'll end with   that and we'll be happy to take questions from the audience at this point. Thanks for your time.

[Laurie] Thank you so much. That was a really   compelling and interesting presentation and gave I think us all a lot to think about.   I wonder if you want to recap. Or kind  of, based on your experience, what are the, what are common pitfalls versus common success factors   as maybe based on your experience? [Roger] I'll start. I think, for some of this early phase  

product development, early phase research and development, one of the common pratfalls is   not really being clear on what you really want to do. I think it's amazing how people can   mark pretty far along without taking a  step back and really trying to understand   the highest level requirement for what  they're trying to accomplish with the product   that they're developing. And I think that's, it's amazing. We run into it all the time where   people are pretty far along and you take a step back and you ask, so what does this have to do?  So one of the key knowledge gaps might really be understanding truly what the user needs are.  

I mean we're talking technical knowledge gaps in both of our examples, but that's also   a key knowledge gap, that other  folks and other tech have talked about.   So I think that it's pretty well known  that's something you have to do,   but we still run into it. I don't know? Dave, if you have some other key nuggets? That's a big one. [David] No, that's really important. I mean, just to sort of follow up in that. There's   a lot of well-known literature from the software world on the   cost of requirements errors and how learning that you didn't do the right thing   late is astronomically more expensive  than learning that you're not doing the right   thing early. And it just kind of goes to the general theme that   we've been trying to get across here, is in an iterative and dynamic way,   like really questioning what you don't know, what you need to know, I think it's king.  

[Laurie] Okay, thank you. We have a question in the chat or a few questions. Let's see.   How does Triple Ring partner with  universities? Share cost, your risk, share revenue? [Roger] Oh it's an interesting question. We definitely have a number of models where we work with   universities. We ourselves are in SBIRs, we write them, we take we participate in them with  

various grant mechanisms with universities. So something that we do quite often and continue   to do in the future, but otherwise it's on a per case basis. Let's look at the project,   let's look at what we're trying to achieve, and is there some kind of an economic puzzle   to solve that we can solve and then there's a technology question that we would solve and   we we work in many ways with universities. But primarily through the SBIR as well as   subcontracting as a partner. [Laurie] Okay, that's great to know. I'm going to move on to the next question.  

How would you approach a medical device design that is aimed for small markets or   underserved populations with affordability and cost being an important factor? That's a   great question and I feel like we see a  fair number of those ideas here at Penn. [David] Sure, I think the fundamental rules of   technology and product development  apply in terms of how the kinds of things you need to think about. But I think that in looking at   maybe low-cost solutions to  particular technical problems   or lower resource funding, to be able to execute, I think there's some specific   things that are probably worth talking about. And taking the first one first.   It really sort of making this comment in   my section on transfer to manufacturing, it's really putting cost   of the solution as a high priority  requirement. And so, even from the very beginnings   of investigating what potential concepts and solutions   might be available, is holding that front and center. And given enough   time and money, you can solve any problem right? But if you're highly constrained on money   either from a cost or a development point of view, making that sort of a  hyper focus of the technical investigation is critical and   sometimes you may conclude that there isn't a good solution yet.  

Technologies need to evolve or sometimes you really apply sort of   additional creative thinking and additional knowledge gap closure to your   first 16 ideas are fantastic technically but don't meet the cost objectives.   So it's that 17th one that really brings to bear a good answer. Roger?   [Roger] I think that's absolutely  true. I think the point is, you can probably solve   any problem given enough time and money and one of the challenges of the low-cost requirement   is to even be more creative, right? So we can build a James Webb telescope but if someone   put a different price cost target to that then you start looking at the user. Do you  

really need this? Does it really need to  perform this way? And oftentimes we don't go back   to the end user and really test out, does it really have to do this? Could it really do that?   And suddenly there's potential solutions and I think there's an interaction with   the requirements with the user and the use cases to really truly find that right middle ground. So I think that's important, yeah. [Laurie] Great, thank you. Another question. What is a good practical approach   to convince R&D teams that are hyper focused on one aspect to be more divergent in their thinking? [David] So my reaction to that is that's a management problem.   And I guess what I mean by that is, I'm only sort of half facetious.   R&D teams need to operate in the context of an organization that is   supporting them and outside of the people on the team, I made some sort of   slightly veiled disparaging remarks about management earlier in the talk, but   really there is a role for management as you know. Hopefully people who've been down the road before and understand the big picture   whereas admittedly sometimes a design engineer or scientist is hyper focused on    the problem right in front of their  face and it really just needs a   bit of external coaching and guidance either for individuals or for teams to make   sure that they understand their objectives and understand the basic   marching orders of where they're heading. And if they're spiraling in on something, too  

focused for the needs of what is going on, there just needs to be some guidance. [Roger] Yeah, I   think to echo what Dave said, it is a management and oversight and project leadership   challenge, right? And we all know this, we've all worked with engineers and scientists that    "that has to be the solution." They really hone in on that and they're adamant that that's the   solution. I think you got to have a culture and a management framework that allows people to   say, "yeah, I get it but I want you to come up with four more and I want you to work with this   person to do that." And so you've got to be able to break the common, and it's common. I mean   engineers often get very, very hyper focused on that they think their solution is the best and that's   not always the case. And the management has to step in and force them just to really look outside. [Laurie] That's a a very fair answer. So our next question. Again, what are some of the  

take home messages from Grace's team for academic researchers interested in translation? It seems   like her team's approach is similar to academics' translational research. What are your thoughts? [Roger] Yeah, I mean it's I think hopefully, everyone does it that way.   Really to really focus on reducing  risk as your number one goal and closing   key knowledge gaps is the way to. I always, when I talk to someone, they're like "well   yeah, yeah, yeah but we still have to develop a product." Like, well look, you're not going to   develop a product. Nothing's going to happen if you don't close those knowledge gaps. It doesn't matter   one iota what you do. If you don't solve  the problem of how to get off the ground, if you don't  

solve that problem, it doesn't matter what you design if you don't solve the problem of this   fundamental technical nugget or user unknown need, there is no product. So why wait? Why waste   your time on the things that don't matter? And so I think from an academic translational   perspective, it's a perfect match. I think everyone should be doing it that way.   I don't know what else to say. That's  the way we like to do things, I guess.

[Laurie] Okay, thank you. That  was another great question.   So I think at this point, we're going to wrap up. But I wanted to thank you all for joining us.

2022-02-08 16:17

Show Video

Other news