Build a healthcare-savvy team; build successful healthtech products
Good healthtech products are really hard to build. Every year healthtech attracts great technologists who have had personal experiences with the broken healthcare system. And yet, along with myriad silent disappearances, there are publicly reported flops in healthtech from scrappy start-ups and tech giants alike. What are some of the common pitfalls? And what can your company do to safeguard against them?
Map the players – patients, providers and payors – and understand their motivations
61% of digital health companies that start B2C end up pivoting to B2B and selling to insurance companies, employers, hospitals, or other healthcare providers. Some of this strategy change is natural growth – healthtech companies pilot by selling directly to consumers, and then gain traction and bigger partnerships. But many healthtech companies shift to B2B selling after gaining a hard-earned understanding of the healthcare ecosystem from some time in the field.
We’re all familiar with the patient-provider-payor dance in healthcare. Your company is (likely) trying to improve the health outcomes of the patient, whilst also delighting the provider, who bills your payor. Unlike in many commercial technology businesses, where customer usage and retention tells you a good story about the value of your product, the feedback loop in healthtech is more opaque given this complex tri-partite structure.
One way to minimize the swirl created by this fuzzy feedback is to map your patient, provider and payor stakeholder groups. If you like graphical tools, this might be useful. With each group, identify:
- What success looks like. Simple phrases about each stakeholder, “Make it easy for the provider to pay for our screening test” can turn into company initiatives, which in turn can be used to guide product roadmaps.
- How stakeholder incentives are aligned with this vision of success
- How stakeholder incentives are not aligned
- 3 most-likely failure modes
This exercise (hopefully) doesn’t pivot your direction, but instead helps clarify where you have dark or blind spots. Re-do the stakeholder exercise quarterly or twice a year to ensure alignment between your roadmap and the healthcare ecosystem.
Understand governance, risk management & compliance (or know when to ask for help)
Healthcare is a regulated industry. Depending on your company’s specialization, if you run a lab, you’ll be working with CLIA requirements; if you’re building medical devices, you’ll be working with the FDA, etc. These efforts require specialized dedicated resources. Additionally, almost all healthtech companies will be working with HIPAA protected data. Healthcare data is a hot topic today, including everything from massive data breaches to data-landgrabbing.
Product teams have to account for data compliance in your product strategy, design and implementation cycles. Basics & resources on HIPAA that product teams should know about include:
- Various public cloud solutions now have HIPAA compliant offerings, including Amazon Web Services, TrueVault, Aptible & ClearDATA
- Remember HIPAA is more than technology – the regulations include incident response, risk assessment, operations management, policies & procedures and security & compliance. Training is required for anyone handling Protected Health Information (PHI). Compliance cloud platforms can help you manage this & the associated auditing: Reciprocity Labs, Aptible & ClearDATA
- Your product managers (as well as your engineers) should be familiar with these HIPAA dev resources published by HHS
Establishing and maintaining trust in your healthtech product offering is core to your success. Give your teams the time and resources to manage the regulated aspects of the product in the right way, and save the headlines for your victories, not compliance violations
Pay extra attention to the seams
So you’ve built a beta release. Now for testing! Health problems are deeply human, and therefore the software solution workflow is embedded in a complex, multi-layered context: the real world. This is the zone in which healthtech products most often fail. Successful healthtech products are 1) integrated into the user’s workflow – and sometimes two or more stakeholders are users, and 2) interoperable with existing software or hardware solutions.
- Test early. Get your software into the users hands for feedback as soon as you can. Reid Hoffman famously said “If you’re not embarrassed by your first release, you’ve waited too long to ship.” In healthtech it is important to contextualize these early releases carefully – e.g. make it explicit to friendly users or pseudo-users that this release is for feedback only; ask if you can demo live and shadow them in their workflow to see how they use the product etc.
- When doing customer research and gathering feedback, explicitly ask about the various usage contexts for different users. Pay close attention to what other software or hardware your solution needs to interoperate with to minimize friction. Try to understand what happens if workflow integration and interoperability doesn’t happen – it’ll help you prioritize, and more quickly understand your larger scale usage data later on
- Articulate priorities around integration and interoperability to get a clearly prioritized roadmap, plus decision documentation. A useful tool for this is MSCW prioritization.
Real world usage context is a challenge for any software development effort. It is even more critical in the world of healthcare which includes high stakes decisions, quirky and complex workflows in a time-scarce environment. Elegant integration & interoperability will beat fancy features anytime.
There are lies, damned lies & statistics. Be rigorous.
There are often two types of evidence generated and used by healthtech companies – marketing data and clinical evidence. Marketing data is used to quantitatively describe the benefits of the product. These results must be real and attained through rigorous analysis, however they have not been achieved in a clinical trial setting. Clinical evidence is generated by running an experiment (the gold standard is a randomized controlled trial, but there are various other methods) which is designed to test the protocol’s impact on the intended outcome given a controlled context. Your product teams must understand the differences between these types of information, and communicate results clearly throughout the organization to avoid confusion around data claims.
Most healthtech products that are aspiring to be paid for by insurance companies will likely need to run a clinical evidence effort at some point. Get your team ready for this by familiarizing them with scientific writing. It’ll also keep them current on the medical research in your product area. Some resources:
- Stanford uses this paper to teach to students the basics of academic reading
- How to read a Clinical Trial provides an overview of how to interpret evaluate a clinical trial, and provides context on the statistical rigor involved in generating clinical evidence
- Bradford Hill Criteria provides a great framework for unpacking the logical consistency of a clinical trial
These are good tactics for building a rigorous culture of scientific literacy in your product teams. Deepest expertise in this area, will come from team members with degrees focused in epidemiology, e.g. Masters of Public Health (MPH), or MS in Epidemiology and Clinical Research etc.
We all know healthcare is broken and we believe in the power of healthtech improve our lives. Understanding the complex healthcare ecosystem, accounting for governance requirements, thoughtfully developing for real-life user workflows and establishing a culture of scientific rigor will help you change healthcare for the better, ultimately both faster & stronger.
Elizabeth Brook Garrity
MDisrupt Guest Author
Elizabeth is a product manager with experience developing machine learning software-as-a-service. She developed her healthcare chops as a program manager at at UCSF, and at Dartmouth’s Masters of Public Health program. She started her career as a management consultant, after graduating from Harvard.