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