The Truth About Medical Device MVPs | Aaron Joseph & Russ Singleton

If you think an MVP in medtech looks like a stripped-down prototype, you’re already behind. Talk to Bill. https://www.linkedin.com/in/founderandcdo/

In their return to LifeSci Continuum, medtech veterans Aaron Joseph and Russ Singleton tackle one of the most misunderstood concepts in medical device development: the MVP (minimum viable product).

From surgical robotics to capital equipment, we discuss why “minimum” doesn’t mean cheap or simple and how smart teams use MVPs to learn faster without compromising safety, trust, or regulatory strategy.
- Aaron Joseph https://www.linkedin.com/in/ajosephprofile/
- Russ Singleton https://www.linkedin.com/in/russellsingleton/

00:00 Why MVP advice from software does not work for medical devices
01:14 What an MVP actually means in regulated medical device development
03:26 Why early customer feedback is essential for medtech startups
06:27 Why medical device MVPs are expensive and often not profitable
10:28 How clinicians reveal unexpected uses for new medical technology
14:25 Convincing early hospitals to use an unfinished medical device
17:23 The “pre-MVP” strategy and first-in-human medical device systems
19:00 Safety, reliability, and regulatory requirements for early devices
21:31 Why regulatory strategy must start early in product development

In Medtech, Your MVP Isn’t Small. It’s Strategic.

Founders love to throw around the term MVP.

Usually wrong.

In software, MVP often gets treated like a stripped-down version you shove into the world fast so you can learn. In medtech, that thinking can get expensive fast. Or worse, it can box you into a regulatory, clinical, or commercial path that makes future growth harder than it needs to be.

That’s exactly why this latest Life Sci Continuum episode matters.

In my conversation with medtech veterans Aaron Joseph and Russ Singleton, we unpack one of the most misunderstood ideas in device development: what a minimum viable product actually means when safety, trust, workflow, reimbursement, adoption, and regulatory strategy are all in the room, glaring at you.

And here’s where Jobs to Be Done becomes incredibly useful.

Too many teams define their MVP by asking:
“What’s the smallest thing we can build?”

That’s the wrong question.

The better question is:
What is the smallest thing we can build that helps us learn whether we can solve the real job better than the current alternative?

That shift matters.

Because the “job” in medtech is rarely just functional. A surgeon is not just trying to complete a procedure. A hospital is not just buying a device. A clinician is not just adopting a tool based on technical performance. They’re hiring a solution to reduce risk, protect outcomes, fit into workflow, preserve reputation, satisfy procurement, support training, and avoid creating chaos.

That means your MVP cannot be defined by product features alone. It has to be defined by what you need to learn about the job, the context around the job, and the barriers that stop adoption.

Sometimes that means your MVP is not minimal in any normal-person sense of the word. Sometimes it is overbuilt, manually supported, operationally painful, and commercially ugly. Good. If it helps you learn the right thing faster, that may be exactly what it should be.

JTBD helps teams avoid a classic medtech screw-up: building an early device around what engineers can make instead of what the market actually needs to hire. It forces sharper questions:

- What progress is the user trying to make?
- What anxieties could stop adoption even if the tech works?
- What workarounds are they firing to make room for this?
- What has to be true

Transcript

0:00

Don't wait until you have the fully optimized, manufacturable, serviceable product before you start getting that crucial early customer feedback. Have you ever tried to build an MVP in the medical device space only to realize that what you heard about building an MVP mostly comes from building software and doesn't really apply? Welcome to LifeSci Continuum. Today, I speak with Russ Singleton and Aaron Joseph. We break down exactly what an MVP really means in regulated markets. I know that there's lots of regulatory landmines and once you have established a certain pathway and a certain description and categorization of your product, which is your MVP, you could be making it very difficult to then follow it up with the full commercial product. why early versions are supposed to be somewhat expensive and probably a bit imperfect, and how to use early customer installs and even pre-MVP first-in-human systems to learn faster without blowing yourself up. in my experiences, it's sort of like uncovering things that I didn't even know about and we certainly learned a lot in those situations. Alright, let's go. Alright guys, welcome back to the show. Appreciate having you back on. Hello Bill. Thanks for having us. We're glad to be here. We've been talking a little bit and the subject of developing an MVP in medical device spaces has come up quite a bit so wanted to talk more about that during this episode. I don't know that an exact MVP is clearly defined in the space and it probably means different things to different people. So, you know, why don't we start quickly with just an idea generally of what an MVP would look like. So I could start. This is a case that I mentioned to Aaron a little earlier. It's not exactly medical device in my experience, but it is capital equipment, very complex. I had an experience in a company where we were developing DNA sequencing back in the days when it was first being developed. And we had a capillary electrophoresis, multiple capillary technology that we wanted to get out. And we didn't know if it was going to work in the field. So we ended up deciding to go out fast with a complete system built like a tank and safe and to be able to get the feedback from our early lab customers. And we built seven of them deliberately, not manufacturable, but supportable. had a whole product team to support them and get it out in the fields. And so I would definitely call that an MVP in the sense it was a minimum viable way to get feedback out in the field in a complex. device and it worked really well for us. We got a lot of feedback and was able to take it back and then iterate that back into the product development process. What about that briefly made it an MVP for you? It was a technology that we needed to test chemistry and test the technology for being able to find bases, if you know genetics and how well it worked and how accurate it worked in the field for real customers. um And we were able to get that feedback. So we were testing out the technology concepts in a live environment. So that was why it was important for us to get it out in the field. We couldn't just do that in the lab. We needed to do that in the hands of real lab customers for what we were trying to do. And I was just going to say, I think what's key in what Russ is saying is the customer feedback. So no matter how much testing you do internally, it's even if you bring in sort of representative customers for usability studies or customer evaluation, it's not the same as them having the new product, you know, on their site, especially if it's something, let's say interventional used in an OR. What the MVP strategy is about is getting that crucial feedback from early customers earlier. Don't wait until you have the fully optimized, manufacturable, serviceable product before you start getting that crucial early customer feedback. Now the challenge is that for medical devices being regulated is that it raises the bar to get that product out initially. as... um Russ was saying it has to be safe and reliable. You also will need regulatory approval of it. So you're investing a lot into an MVP that you know will not be profitable. And so that's part of the mix. And I've heard from people in medical device companies that say, we're FDA regulated. So there's no such thing as an MVP, but it's just an MVP modified for a regulated industry. I do have an example of a situation in a medical device. So the story is for a surgical robotics company that I was part of, a startup. And I came in as an outsider into the company. The company had been going on for a few years and they were having trouble getting the product out the door. So I brought a technique into the company. I took over R&D coming into the company as an outsider. And I got the team to focus on just the bare minimum of what they thought they needed to get out to the field. So that's a concept of MVP and paying attention to safety, paying attention that we were going into a regulated environment. We went to Europe at the time. I don't think you can do that quite so much anymore and get it out. And we missed a few things that we knew were part of the product, but we just decided to get the key things out there. and make sure it was safe and get into hands of customers. And we put it in a number of sites in New York and got a ton of feedback as a result of it. And also because we had a camera on board, we were able to make videos of the surgeries that we were doing and use it for the actual FDA submission that we did successfully, actually. So that was a good situation for us, but it wasn't intentional in the sense that it was. you know, was a diversion from the original plan was like in the case of one situation, just what you, and if I'm going to make a choice between the heart and the lungs and, the brain, what am I going to keep in to the product? want to not have in it, you know, so that's really hard choices. So a couple things there I want to bounce back to Aaron for a moment, but Russell will come back to what you just said uh in a second. But Aaron, you had said, OK, you'll know that this product won't be profitable. So you're going to be investing in this and you just you just know it. Talk to me about that, because I think a lot of people will hear that and be like, I can't work on something that isn't going to be profitable. So explain that a little bit more what you meant by that and what it looks like. Yeah, exactly. And, um, the business considerations and business strategy are going to be important. And an MVP strategy is not appropriate for everybody. Um, if you're making, if you're launching version two of a product that's already out there, or it's a well-known type of category of medical device, then an MVP may not really buy you much. Um, but if you're developing a truly innovative device, then What you're doing is, is balancing the, the time and investment to get the MVP out there, get that crucial customer feedback. Um, and then do a fast follow-up with the quote unquote real product, the one that, that you want to manufacture, the one that you want to sell everywhere, the one that's going to disrupt the market. That may not be a positive balance for all products. And, so that's, there's, there's no way to say, Oh, You should always do an MVP, maybe in an unregulated market. That's a very different uh equation, but for medical devices, it's how crucial is that early customer feedback and what is your time span for the product? Now, a lot of medical devices are out on the market for eight, 10, 12 years without any changes. So we're talking, you know, a long product life cycle and long-term strategies. The other thing. to consider is that for a truly innovative device, the company may need to develop a lot of infrastructure around it. And it's not just manufacturing. uh It can be a trained sales force, a customer support uh team, uh field service engineers, all of them, all of that infrastructure needs to be in place for widespread full production uh product. So the MVP can also give space for all that infrastructure to be developed. Because it's very hard to do that rapid. Russell, anything you want to add to that? Yeah, I think that the thinking of the cost structure of an MVP is usually higher than what you want it to be for a final product. Certainly you haven't worked all the problems out for manufacturing if you're to put a number of these things out in the field. I agree with Aaron that you need to have the field support ready for it, even in a limited situation for the sites that you go in. in my experience, it's almost like a site by site thinking process of what support you will have in place. Also, from a sales perspective, it's a selling process of getting those customers lined up to know that they're not going to have the final product. You're going to guarantee them that they will get the upgrades when you have it. So it costs the company money. They're going out knowing they're to put out at least two, maybe more of these units as fast follow-ons to solve the problems for the customers. You have to build that into. If you're a startup, the proposal that you put in front of the VCs or the angel funders or whoever's funding this kind of thing. But the value of it is you get a ton of value from the early feedback and you make discoveries that you didn't even think about in my experience. It's sort of like uncovering things that I didn't even know about what you needed to do in that situation. And we certainly learned a lot in those situations. Right, it gives you a chance to think about and incorporate the things that you didn't think about, you couldn't plan for, some of the unintended consequences of how your device might be used. I'll just interrupt here to say that it's also a matter of like a resonance between an innovative new technology and the clinicians who are going to make use of it. And if it's truly innovative, then they've never used it before. Henry Ford was famous for saying, my customers just asked for a faster horse. They didn't know what a car was. And in many aspects of healthcare, there is a change from a horse drawn cart to an automobile. and it can have huge effects that you won't know until you put that new medical device in the hands of the clinicians. Right. I think before, you know, when we were talking earlier, you had mentioned, I think, the da Vinci product. And did you want to use that kind of to illustrate some of this? Do want to share that? oh absolutely. So there's a famous history of the beginning of uh Intuitive Surgical and da Vinci system. And this is 25 years ago that it was originally intended for cardiac surgery, which is a really tough market. uh You can imagine the risks there are very high. Surgeons are very conservative, a very inventive and resourceful urologist. tried it for prostatectomy, for prostate surgery, and it turned out to be a perfect fit for urology. And that was the beginning of all the growth for the company. If you look at that from an MVP strategy, they would not have known that that surgical system, that robotic system was such a good fit for urology until it was actually tried. Urologists weren't asking for a robot. Fill in some of the gaps for me on the story and how uh kind of the MVP story played out. Did they initially design and build one robot and then maybe source it around to cardiologists and then get a lot of pushback or like how did how did that happen or unfold? I don't know all the details that was long before I joined the company. uh But uh I'm sure you can look up the history. Perhaps it's even on the Intuitive website. the key thing was that the very smart people had designed a really revolutionary new medical device, this surgical robot, and they weren't sure what instruments it needed um or exactly what it needed to do. And if you're just focused on cardiac surgery, as I said, it's very high bar and um it would have been a very difficult place to get started. The urology market turned out to be a perfect fit and it has to do with the geometry of the surgery. But I'll just say for any men out there, my age and older, if you need prostate surgery, you want it done with uh a surgical robotic system. The advantage for the company is that they didn't try to make a zillion robots and place them everywhere. The capital expense is enormous, but also all the infrastructure around it is enormous. And you have to develop special instruments for each medical application. So you want to know, you know, what's a really good fit and focus on that and make it work really well before you spread out to other applications. Coincidentally, this week the uh Medtronic surgical robot, Hugo, was just approved by FDA for the US market for uh urology. So they are, and I'm sure they will rapidly follow up with uh many other applications, uh but they're starting with that base focus, make sure that works well in the US market and then build on it. That's not strictly an MVP strategy, but it uses the same principles. ah You're getting that key customer feedback. You're also building up your infrastructure to support that new product. bouncing back to something that Russell said a few minutes ago. He said you have to be able to communicate to sort of these early users that you're getting feedback from that they just aren't getting the finished final product. How do you think you approach somebody with that? um any strategies or thoughts around going to somebody who's used to finished approved product? So this thing, this approach we actually did put in place at the outset with the company. We decided that for the first two years, we said all customers who get our products will get automatic free upgrades, including full replacement if necessary, which is a very expensive strategy in some cases. um And um you approach the customer and say, there's no risk to you from a financial perspective. And then we will have the support in place for you when you have the robot in place, if you have any situations where you need to do that. And we had the engineering team as well, besides the support team, if something drastic happened in the field, we would fly out. We went to Brussels first in Germany. I mean, we were overseas doing this kind of thing. So it got pretty expensive when we were doing that. I would say that we got some early feedback very quickly, for example, in our vision system, ah that we were seeing things that we didn't expect to see that we could make changes with pretty quickly ah and say, I know what that is. And we made the changes and it was very dramatic for the customers to be able to get that fixed. So they were very happy with the speed of addressing the issues, if you will, ah with the feedback that we had. we discovered several major things that took a little longer to solve, some electrical problems, for example. But because we were in the field, said, gee, we didn't even think about that. That was uh a new type of problem that we had that was very, if we had known about it, we could probably have done it in this. If we had been through placing surgical robots in the field before in another company, which we were one of the early companies. We might have solved it, but going in the field, we were able to get the feedback right away and use that to do a fast follow on to that. Right. Thinking about this whole structure, I mean, we're clearly we've got we've gone through the FDA process at this point with whatever state the products in to get it to that initial MVP. ah But even before that, that's still a heavy lift. And we talked a little bit before uh before the call about a pre MVP MVP. I'll just chime in on that one. So for products that require a clinical study for FDA approval or other regulatory approval, the company has a choice of what the product is that's used in the clinical trial. And when I say a choice, the obvious choice is the final finished product. But as you get into devices that have more software, capital equipment, it becomes more advantageous to have a first in human system and then followed by a commercial system. So that's the, um, what you're referring to as the pre MVP. Um, it is pre market. but it's an important strategy because you're not waiting to start your clinical trial until you have the complete finished polished product. Um, you're also able to work on that full commercial product in parallel with your clinical trial. So from a project management standpoint and sort of resource allocation, it's advantageous. Um, it also means that whatever you learn in the clinical trial gets folded back into your final product. and that can be, um, enhancements to the, the UI. could be something about, as Russ was saying, it could be some additional feature, an automatic report generation that no one ever thought was needed. You know, no one ever thought of, and, um, this first in human system. It then is an early indicator of what customers are going to need. So it gets you sort of the pre-MVP benefits. What do you think are the minimum requirements of that pre MVP first in human? What do you have to nail there or include at that point that just can't wait until that second round? It's safety considerations for sure. You've got to think about hardware, software, whatever it is in the most ridiculous situations that might come up to make sure that you're ensuring it's safe for the patient going in and being able to recover at power going out or whatever the situation may be. And that was a big deal for us because we had to think of things and say, my gosh, I didn't think of that. We had to put that in place. That is absolutely key. The other thing is I think you have to think about the situation for the customer's, particular surgeries that you're going in. So if you're doing an MVP, you're likely or you should have picked out the customers that you're going to do this with. So you know the kinds of things that they're interested in. They may not be in the sweet spot of what you're trying to do for the broad market, but you want to make sure that you're handling their situation and their case. uh and make sure you have those features in place. ah So I would say those two things. And I'll also add that the system is reliable enough that it doesn't interrupt clinical operations. And that sounds obvious, but I have seen cases where companies started a clinical trial with a device that either the software crashed or there were electronic glitches. And you could say it's like, well, it just needs to get through the clinical trial. You're asking a lot of the clinicians and everyone else involved in that clinical trial to put up with that sort of thing. you can do without the bells and whistles. You can do without the manufacturability. I'm sure if there's any manufacturing engineers listening, they're kind of cringing right now. But remember we're trading off the importance of the feedback from the clinical trial and of course the evidence from the clinical trial with completing the perfect commercial launch product. And yes, as Russ said, safety is first and foremost, and, and effectiveness because you're doing a clinical trial, but there's also a certain level of reliability and functionality. So if you have a really awkward UI, it just isn't, it just isn't going to work well. You know, and thinking through some of the implications of this and thinking through my regulatory strategy and where that lives in all of this. And for some people, I'm not thinking about that till months down the road, but I think the two of you are more advocates for thinking about that very, very early on. Well, Russell, Aaron, thank you so much for being on today. Thank you If you made it here, thank you. If you haven't already, like, share, and subscribe to the channel. If you want to learn more about this topic, I expand on it below, as well as in my LinkedIn newsletter. That's all for now. More soon.