The Minimum Clinically Viable Product: Enabling rapid innovation without sacrificing clinical rigor
Omada Health thinks deeply about how to integrate physician and clinical expertise into our product development process. Our clinical and product leadership work closely together to ensure both teams are ready collaborators. The goal is always to develop a product that is safe to use, effective in driving outcomes, and delivers a compelling, engaging user experience.
We utilize agile software development - the practice of shipping new features to our user community in order to test an idea with measurable impact. A core part of this type of development is the minimum viable product, or MVP. The MVP allows rapid iteration to maximize learning through iteration. But the concept of doing the “minimum” for a patient is antithetical to how clinicians are trained, and how we operate. At best, the idea of a MVP in digitally-based healthcare breeds skepticism with the clinical team; at worst, it’s an absolute non-starter.
Whereas the failure of a new MVP feature on a hotel reservation or transportation app might cause your company to lose a few subscribers, a faulty feature in a digital care program can have much more dire consequences. So, in order for our clinical and product teams to collaborate effectively, we needed a new vocabulary. The dichotomy ultimately led us to a new term - The Minimum Clinically Viable Product, or MCVP.
The MCVP is defined as both the minimum needed to test a hypothesis with our users, and the minimum we need to impact clinical outcomes while ensuring user safety. To know whether a new feature or product meets the MCVP bar, we consult the scientific evidence and clinical best practice. If it’s a behavior change concept, we look for published research demonstrating that a technique or process changes health behavior. If it’s remote monitoring, we determine which device is the most accurate and has the best evidence of directly impacting outcomes.
The idea of an MCVP is to give clinicians a strong voice in a process normally led by product experts. When it comes to digital health, the clinician must have the space to tell the product team when a new feature or program falls below the threshold for clinical effectiveness, or when it gets anywhere near endangering user safety. It’s on these two issues where the MCVP is fundamentally different from a normal MVP process. The Product Manager still is the ultimate decision maker, but won’t ship features that don’t meet the threshold. Our clinicians must also embrace collaboration and humility, acknowledging that our best path toward innovation is to test something small and iterate.
Subject matter experts have always been an established input into the MVP method, lending their technical expertise to inform the outcome or development. Like developing an MVP, developing an MCVP is a team process that includes insight from researchers, designers, a lead product manager, and SMEs -- in this case, me and our clinical staff. But to better orient the process toward a clinically viable product, we had to reframe the conversation to honor both the product development process and the clinician voice.
Doctors are used to being the principal decision makers on teams, taking intaking information and making the final call. But in a product development team, clinicians are one input into the process. Outside of safety concerns, the Product Manager ultimately decides what is built and makes it into the patient’s hands. This can be hard for clinicians who are both risk averse and used to being in charge.
Recently, we added a Type 2 Diabetes health history form to serve our expanded product. Our clinical team submitted an initial draft that was based on clinical best practice -- meaning it was very comprehensive. And clinical instincts were correct! Having that information is crucial for comprehensive diabetes care. But a comprehensive intake form is useless if a patient doesn’t fill it out. Our users engage differently with history forms in our program than they would in a physician’s waiting room - and our product teams know it. We couldn’t put a form in front of our users that was likely to lead to disengagement. And when a user may just be “checking out” Omada, they may prefer to provide only a fraction of that information until we succeed in building trust.
A debate ensued between our product and clinical teams. Applying the MCVP concept, we focused on the critical questions that would allow us to provide safe, effective care to patients for the first few weeks. We went through every question on the comprehensive form and asked ourselves, “do I really need this information to provide education within the first week, or could it wait until later” The product team worked to add branching, graphics, engaging response icons and other tricks to make the history form more user friendly. The ultimate product was a shorter, better user experience that did not sacrifice patient care or safety, and was designed to keep patients engaged. We knew that we could always come back to our users to collect more information -- as long as we kept them engaged and proved our value in the first phase of care.
Some might say that the MCVP is just common sense. Product teams always gather inputs from stakeholders and pick the elements that will allow quick testing to achieve an outcome. But digital health is different. The players are different and the stakes are higher. The MCVP is as much a statement of intention as it is a process. It allows the clinical SME to feel empowered as a key partner in the decision-making, and at the same time respects the overall product development process.
Clinicians come to Omada to imagine a world in which we can deliver care in a new way and impact health at scale. And product managers, designers, and engineers work in digital health because they want work that is mission-driven. Blending cultures is not easy, but what emerges is a unique and impactful program that has the potential to impact millions.
