How to Start with an MVP to Build a Best-in-Class Software-Driven Medical Device
Developing a new medical device is an enormous undertaking — one that requires a major investment of time and resources. From documenting your users’ needs to proving your device’s safety and efficacy, there’s nothing “quick and dirty” about taking a medical device to market.
Contrast that with software product development, and a whole different picture emerges. Using agile development principles, software developers iterate rapidly as they build out a product. Oftentimes, their goal is to arrive at a minimum viable product (MVP), or the leanest possible version of a product that is still meaty enough to inspire user adoption. In doing so, software developers save both time and money — and reduce risk, too.
On the face of it, MVPs may seem difficult to square with the medical device development process. But the truth is that you can (and probably should) consider adopting an MVP model for software-driven medical devices. Here’s what you need to know.
What is a Minimum Viable Product (MVP)?
The concept of a minimum viable product was first defined twenty years ago by Frank Robinson.
A minimum viable product is the most elemental version of a product that still offers enough real value to consumers to gain traction in the market. To be clear, producing an MVP isn’t about slap-dashing a product together as quickly as possible and fixing it after it goes to market. It’s about reducing complexity, not lowering your standards.
This means that in order to bring a successful MVP to market, you need to do your homework. You must develop a fully fleshed-out concept for a product that offers a meaningful solution to your users’ needs. But you shouldn’t move too far beyond your core concept. That’s because the whole idea of an MVP encourages restraint. It shouldn’t include any unnecessary bells and whistles that could lead to feature bloat (and wasted resources).
Finally, an MVP should be seen as a jumping-off point. It’s not a mandate to produce an ultra-lean product that remains ultra lean. Over time, you can (and should) build your product out with additional features and functionalities. However, rather than trying to anticipate the features your users will want, you can add them in direct response to their feedback.
The Benefits of Going to Market with an MVP
It’s natural for product developers to want to wait until their product is fully completed — and chock full of exciting features — before going to market. But the reality is that there are many benefits to going to market with an MVP. By starting with an MVP, you can:
-
Save money. An MVP can help you significantly reduce the amount of money you spend before launching your product. This initial savings can be especially helpful for startups.
-
Go to market faster. Time to market is a critical factor in staying ahead of the competition. By spending less time building out bells and whistles, you can take an MVP to market much faster than a “finished” product.
-
Reduce risk. Anytime you set out to develop a new digital product, you run the risk of investing too heavily before knowing for sure how the market will respond. By going to market with a lean MVP, you can significantly reduce that risk.
-
Prove out your concept with real users. An MVP allows you to test out a new concept with real users. The benefit? You can identify what is and isn’t working and, assuming your product resonates with users, invest in adding only those features your users have expressly requested.
-
Secure additional funding for full product development. If your firm is working with limited funding, you can also use MVPs as a way to show investors that your product has real value to users. This can, in turn, be the key to securing additional funding for full product development. You can even use the concept of an MVP internally, to show investors your product’s potential and get more funding before going to market.
-
Inject greater flexibility in the product development process. If your organization sets out to develop a product with an overly rigid vision, that vision can unintentionally obscure the best solutions. By working toward an MVP, you embrace a more organic approach — one that allows users to show you how to craft the best software product to meet their needs.
FDA Regulations for Medical Devices: Is an MVP a Viable Option?
If you have any experience in the medical device industry, you already know that the FDA plays a critical role in your ability to bring a new device to market. So how do the FDA’s approval requirements mesh with the concept of an MVP? At first glance, it doesn’t seem like a very good fit. Where MVP development is quick and nimble, the FDA’s Design Controls are long and methodical.
The FDA’s traditional approval pathways were built in tandem with traditional product development — that is, hardware engineering. The process of developing a hardware device tends to follow the waterfall model. Within this model, product teams follow a set sequence of steps to slowly narrow down on a finished product. Because the cost of making changes to a physical device goes up as the product’s fidelity increases, the MVP model might not be as effective for hardware devices.
Software development, on the other hand, is much more iterative and agile than hardware engineering. In recognition of the fact that so many of today’s medical devices are software-driven, the FDA is finally modernizing its approval pathways. Beginning in 2019, the FDA launched a new Digital Health Software Precertification (Pre-Cert) Program. The Pre-Cert program allows companies with “a robust culture of quality and organizational excellence” to apply for company-wide pre-certification. Pre-certified companies are free to innovate more rapidly — without applying for 510K clearance with every new product release.
This is great news when it comes to your firm’s ability to produce a minimum viable product for your software-driven medical device. You can do this one of two ways. The first is to create an MVP for internal use as a way to prove out a concept and get the funding necessary to take it to market. The second is to go to market with a lean version of your core functionality in place and see how the market responds.
By creating a minimum viable product, you stand to reduce your risk, save time and money — and produce a product that is tailor-made to meet your users’ unique needs.