What to Expect from a Successful Medical Device Product Development - Webinar Recording
[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
