The Evolving Healthcare Product Landscape

Lessons from Health Tech's Product Leaders

Hey! I’m Morgan and I’m a Vice President with Bessemer Venture Partners investing in healthcare and life sciences. I’m also in medical school. This newsletter is an evolving collection of what I’m learning as I translate between the worlds of venture capital, technology, and medicine. You can subscribe for free to follow my journey:

I’ve never believed that AI would replace doctors. As I wrote in the Bessemer 10 Laws of Healthcare, “services are the lifeblood of the healthcare industry.” But I’ve always believed that software would play a critical role in scaling clinical expertise non-linearly.

I saw my first electronic health record (EHR) implementation in 2011 as an eager 15-year-old shadowing in the Anesthesia department at INOVA Alexandria. I recall the turmoil: physicians and nurses running around frantically between clunky desktop monitors and reams of paper, lamenting the disruption of Epic and the Meaningful Use requirements that would follow. Was the hospital always this crazy? Why was it so hard to adopt new technology in a field where technological breakthroughs are constantly extending human life?

Fast forward a decade later, $30 billion of government subsidies have created a nearly ubiquitous install base of EHRs, cloud software penetration in healthcare has eclipsed 50% (up from 21% in 2018), and >97% of healthcare workers are using mobile. The sheer surface area available for healthcare technology products has grown exponentially, while brilliant software engineers and product leaders are specializing in the nuances of building for this ancient field. Perhaps most salient for healthcare, next-generation regulations are now incentivizing the next wave of technological adoption.

Welcome to the post-EHR era. Welcome to Healthcare’s “Product Moment.”

In celebration of this unique period of health tech innovation, it was an honor to host a conversation on “The Evolving Healthcare Product Landscape” for the third event of an ongoing (to-be-named) series of conversations among startup CXOs at healthcare and life sciences companies and industry leaders. We were fortunate to gather some of the brightest minds on this topic, notably:

• Ayo Omojola, SVP Product at Carbon Health

• Dhruv Vasishtha, VP Product at firsthand

• Gina Kim, Chief Product Officer at Cohere Health

In this piece, we summarize our conversation and cover a number of Healthcare Product topics, including:

• What is Product in healthcare and how is it different?

• Product for healthcare SaaS vs. tech-enabled services

• How to make buy vs. build decisions in healthcare

• How to make your first Product hire, and what to do if you are the first!

At the very end, Ayo, Dhruv, and Gina share a glimpse into what they hope our industry builds next as part of our very own #RequestForProduct. Happy reading!

What is “Product” accountable for?

Starting with the basics before we dive into the minutiae: what is Product accountable for at health tech companies? In simplest terms, Product is accountable for product-market fit (PMF). The inelastic demand curve for healthcare services juxtaposed with the disconnect between the end user/consumer and the decision-maker/buyer pose unique challenges for PMF, as do the various go-to-market motions (D2C, B2B, B2B2C), end customers (payer, provider, employer, pharma, consumer), business models (insurance, cash pay, SaaS, transaction-based), and outcomes (clinical, financial, member experience ROI - more on that here).

We take a stab at defining PMF in healthcare:

Healthcare PMF: Are customers, end users, and patients achieving the results (clinical, financial, experience, etc.) they intended from the software or service?

Given the complexity of defining PMF in healthcare, what Product teams own (vs. operations, project management, clinical, and other functional areas) often varies based on the aforementioned variables.

Generally speaking, Product teams are focused on a specific mission or problem statement that is associated with key business metrics. The ideal of product vs. the reality of product can be vastly different, and “if you build it they will come” is simply not true in healthcare.

Typically, initiatives that are heavily software-enabled fall under the purview of Product, whereas Operations oversees those that are more services-based (e.g., if you don’t achieve a patient engagement target, Operations will likely be pinged first, then Product). Product might design the intake flow to determine whether a patient is eligible for a diabetes program, but operations (member support, care navigation, etc.) would be responsible for enrolling patients. For SaaS companies, it’s clear that Product would own software and the features compromising it, locking step with engineering on development and implementation/customer success on deployment.

Dhruv’s Framework for Product and Technology Accountabilities

What’s different between Healthcare Product vs. Product in other industries?

Many health tech Product principles can be adapted from best-in-class, generalizable Product philosophies – we list some of our favorites at the end of the article. Here we focus on the unique aspects of Healthcare Product: 

1. Highly Complex Stakeholder Map

The stakeholder map managed by Healthcare Product leaders parallels the complexity and general dysfunction of the industry. For a single company, stakeholders can include patients, clinicians, researchers, enterprise users, enterprise decision-makers, and caregivers to name a few. Managing stakeholders and identifying effective ways to solve their problems are core responsibilities of Product teams and often require data-driven approaches. Unlike other industries, however, solving problems in healthcare is often muddied by convention and regulation that at times, can obfuscate the story the data tries to tell. Therefore, in addition to managing a highly complex stakeholder map with often competing incentives, Healthcare Product leaders must account for convention and regulation when bringing new products to market. As the old adage goes: “in healthcare, there’s a lot of people who can say no, but often no single person who can say yes.”

2. Bridging Two worlds: Technology and Clinical Medicine

Certainly, other industries have multi-dimensional stakeholder maps, but few face challenges posed by bringing two highly skilled, yet vastly different workforces together: technologists and clinicians. Many healthcare companies employ clinicians not only for care delivery services but also as shepherds and influencers of Product. Given the nascency of product-led growth in healthcare (which I will discuss in an upcoming piece!), the pool of expert technologists skilled in working shoulder-to-shoulder with clinicians is few and far between, and vice versa.

Fortunately, companies skilled in bridging these two unique workforces for the benefit of building good products have developed a few best practices for doing so:

• Integrating sessions on “What is Product?” as part of every employee’s onboarding, with a specific focus on ensuring that clinical team members understand the roles and responsibilities of the Product team (read: it’s not IT)

• Sponsoring courses that provide employee education about healthcare in America (more on this at the end!)

• Requiring Product and Engineering team members to work in clinics for some pre-determined amount of time each year, a practice adopted by small startups but also behemoth companies like Epic. Some healthcare companies have empowered their designers to work from waiting rooms, others have allowed software engineers to “Zoom shadow” telemedicine consults. As with anything patient-facing, it’s always important to get consent before engaging in these practices.

• Hosting cross-functional meetings where clinicians and Product leaders interface regularly.

• Hiring clinician technologists: those who practice medicine and also boast Product and/or Engineering skills - a rare but increasingly critical voice that can translate across the company.

In truth, it’s rare for physicians to occupy spaces where they do not hold the sole authoritative voice. Including your clinical product influencers in sprints and squads while allowing your product and engineering teams to gain real clinical exposure can help both sides build empathy and can reduce any natural hierarchies that may present.

Great Product leaders have a lot in common with great diagnosticians. In the same way that clinicians work through diagnostic frameworks based on presumed underlying pathology before jumping to diagnoses, Product leaders must aggregate data to distill a problem before building a solution.

So, the next time someone tells the Product team they need the full medical record to complete a task, boil it down to the basics. What problem are you trying to solve? You may just need the discharge summary…

3. Organizational structure

Product team organizational structures tend to vary in healthcare, especially for companies that have both clinician and patient interfaces. We’ve seen a number of ways to organize product teams, including:

• Audiences: providers, patients, growth (led by a generalist product manager)

• Services: billing/revenue cycle management, practice management, interoperability (typically requires a product manager with deep domain expertise in the given service)

• Initiatives: new business lines that are full stack (led by a generalist product manager / “founder archetypes”)

Ultimately, the Product team needs to be able to interface with any aspect of the company required to solve customer/user problems, and as a result, there’s no “right way” to organize a Healthcare Product team. The most important aspect of running successful Product teams is to empower your team and org structure to change as the business needs evolve.

What is “Product” for a tech-enabled, patient services company?

Patient services (one example of which is care delivery) is one category within healthcare that has experienced dramatic change over the last five years as telemedicine strives for the ubiquity enjoyed by the EHR and COVID-19-related regulations drive the proliferation of virtual care. So what does Product scope look like for a tech-enabled, patient services business? Do clinical programs count as Product or as part of Clinical Operations? Where does clinical content land? 

Product teams at patient services companies can and should evolve depending on the stage of the business. A pre-launch care delivery company may define Product as the clinical protocols and associated workflows, whereas a post-launch organization might consider the patient-facing onboarding infrastructure and clinician tooling of the product. 

As your definition of Product evolves and hypotheses change, the core problem and KPIs should not. 

Regardless of stage, there’s often a (healthy) tension at care delivery companies between Product and Patient Services Operations. Ultimately, we defined Product as All the Things: the clinical protocols, clinician and patient-facing technology enablement, and impact analytics (including pre/post studies). Through it all, Product is the experience czar that must figure out how each piece of this highly complex but orchestrated system works together to solve a business problem.

Here are three frameworks we like for organizing Product organizations at care delivery companies:

1. User-Centered

Organize teams based on “the user” (e.g., patient, clinician, employer benefits leader, etc.). This is a great framework for pre-launch companies. Once you launch your MVP and it’s stable, you can split the team into squads that are less user-focused on more problem-oriented. Focusing Product resources on specific users ensures you don’t underinvest in the experience of certain users (e.g., providers). Additionally, context switching across multiple user needs can be expensive for an early-stage Prodcut team. For any initiatives that span multiple users, consider creating squads around them. As the organization grows, a Product Strategy team can build bridges across squads to ensure a consistent Product ethos.

2. Commandos, Infantry, Police

This framework is great for mid-stage companies that are scaling an existing product with PMF while also launching new ones.

Commandos: These are your front-line, bleeding edge Product minds that are working on the rawest stuff. The archetype for this role is someone with founder energy - highly autonomous, quick learner/iterator, and data-driven. This is the team best known for pulling off a miracle, after which, they need to be working on the next one.

Infantry: Once the commandos scope a Product opportunity and make strong progress towards PMF, the Infantry team moves in behind to take over. This team will continue to advance the feature set while integrating customer feedback.

Police: This is the team that keeps established products in a steady-state by maintaining stability and continuing to improve the already mature product. See more on this philosophy here.

3. Values-Aligned

A risk-based, tech-enabled services business has a few core value levers that can lead to population and client impact. In these cases, some Product and Engineering teams are staffed against these value levers and scope work based on initiatives they believe will impact leading KPIs or lagging OKR metrics for payer contract success. 

An organization defined by such values might create Product pods based on:

• Member Selection - Of our attributed lives, which can we impact via outreach and enrollment every month (defined by each of our MSAs) given that our patient-facing teams have variable capacity and differing tenure and maturity?

• Engagement - Are we enrolling individuals into our programming and continuously engaging them such that we have built a trusted relationship?

• Total Cost of Care - Are our clinical interventions leading to higher patient quality and outcomes?

As you can see, each of these Product pods would require cross-functional collaboration to move the value lever described. Draw those dotted lines!

How is Healthcare Product talent evolving? 

The DNA of a Healthcare Product person is changing rapidly as the functional area matures. Historically many “healthcare-native” product managers came from other functions approximate to product, such as Project Management and Operations. Exit opportunities were narrower, but companies like Flatiron Health, Oscar, and ZocDoc were able to recruit some of the best Product talent in the early days of “digital health” (has it rebranded to “health tech” officially?).

Increasingly, however, there is a growing cohort of health tech native Product talent spinning out of the latest and greatest healthcare and life sciences tech mafias, which has coincided with increasing subspecialization within the industry.

In addition to Dhruv, Ayo, and Gina, check out the incredible work of Brendan Keeler, Claire Vo, Rebecca Mitchell, Rohan D’Souza, Scott Voight, JenJen Chen, and Shohini Gupta, to name a few!

How to hire the first Product person

Product hiring mistakes are expensive – there are a handful of decisions made each year by Product leaders that are “make or break” for any company. As the pipeline for amazing health tech native product talent grows, we offer some guidance on how to make the best first Product hire. Before even hiring this person, it’s important to have clear answers to the following questions:

• What can you delegate to this person at this point in time?

• What do you still want to decide and own?

Oftentimes, there is a lot of wasted energy expended by the first Product person because the answers to these questions were unclear. For founders, it’s helpful to determine whether you are Sales-led or Product-led as a leader. Though no one exists squarely in one camp or the other, think about it from the context of where your Zone of Genius lies. If you are Sales-led, you may decide to make your first Product hire sooner. If you are Product-led, you may need to interrogate how and when you decide to entrust Product with another team member.

Ultimately, as a founder, if you disagree with a decision your Product leader is making and steer the ship in a different direction, you need to be accountable for the outcome.

What to do if you find yourself as the first product manager at a healthcare company?

Congrats! You were recently hired as the first Product Manager at a healthcare company. You’ve now got a stakeholder map as complex as the human body and a backlog longer than the complete list of ICD-10 codes because your CEO tried to lead Product for a little too long… Here is a step-by-step guide on how to build a product organization from the ground up as the first hire:

1. Create a value statement. This is a 3-6 page document that covers:

   1. Market context and business opportunity

   2. Defined problem

   3. Specific customer, user, and distribution segment you are solving for

   4. Leading and lagging KPIs that you would measure which would indicate the problem is being solved

   5. Back-of-the-napkin revenue opportunity analysis coupled with the level of effort (aiming for orders of magnitude)

2. Align with your CTO or a lead development partner on the division of roles between Product and Engineering, and ultimately, who makes decisions across various functions. Our best advice here is to create a list of all the “jobs to be done” and divide ownership based on unique qualifications to complete said jobs. This is easier said than done.

3. Build your team. How can you get your product managers to see one, do one, teach one? 🙂

So what’s in our Healthcare Product stack?

No two Product team stacks are the same, and like much of tech, Product teams cobble together a ton of different tools to manage the stakeholders, drive forward processes, maintain accountability, and prioritize the roadmap.

Some of our favorite tools:

• Slack: team communications, including clinical teams

• Airtable / Miro / Notion: roadmapping

• Google Drive (excel, slides, etc.): documentation, roadmapping, prioritization

• Productboard: product feature prioritization and roadmapping

• Notion: documentation

• Jira: issue and project tracking

• Loom: async team education, communication, and investor demos.

  • For example, front-line direct care workers can record video journals summarizing their experiences with patients each week to share with the non-clinical teams and strengthen company-wide understanding of the frontline worker experience and patient population.

  • During fundraising, it’s helpful to share a pre-recorded Loom demo as part of the data room so that the Product team doesn’t have to do a live demo for every investor semi-interested in the company.

• Canvas, Elation, Athena EHR: next-generation EHR

• Snowflake / Jupyter Notebook: data analysis

How to make Buy vs. Build decisions?

Is it strategic and does it create enterprise value for your business? Build it.

Is the answer to the above no, and does a good enough one exist? Buy it.

We can’t answer this question for you directly as Build vs. Buy decisions are highly nuanced and need to be placed in context, but the Value-Complexity Matrix above offers some insight into how to think through these choices in a structured way. You may not need to build your own EHR to achieve key objectives, but you may need to build patient- or clinician-facing interfaces on top of an existing EHR to differentiate your business. You may not need to build your own FHIR API, but you may need to invest in novel data storage and query methodologies that keep your application nimble.

Think about what is actually establishing enterprise value for your company and build those things. Partner or buy for the rest.

For many healthcare services businesses, operational excellence is a key differentiator and moat. In these cases, it makes sense to invest in Product that drives operational prowess.

Note: Not everyone will always agree with your buy vs. build decisions. Trust your process and remember that other functional areas have different incentive structures. The beauty of these decisions is you’ll find out if you made the right one in due time, and though it may be expensive to fix, can course correct based on new data.

#RequestforProduct

To conclude the session, we asked our Product leaders a simple question: what do you hope gets built over the next few years in health tech? Here are their responses:

• True EHR interoperability

• Automated eligibility benefit checks

• Developer friendly messaging platforms for patients, caregivers, and providers (“Twilio for Healthcare”)

Working on one of the above? Let us know! We’d love to chat with you.

If you got this far, thanks for reading. Stay tuned for information on the next event in October where I’ll be covering “Building Brand and Community in Healthcare” with some of our industry’s most illustrious storytellers.

Supplemental Reading List:

• “A comprehensive survey of Product Management” by Lenny Rachitsky

• Christensen’s “Jobs to be done” framework applied to PM by Zbignev Gecis

• The only thing that matters by Marc Andreessen

• What distinguishes the Top 1% of product managers from the Top 10%? (Quora)

• Behind Every Great Product by Marty Cagan

• Product vs. Feature Teams by Marty Cagan

• Brendan Keeler’s Newsletter, Health API Guy

• Popular product threads from Shreyas Doshi

• General business memos (not all product-specific) from Sriram Krishnan

Have more to add to this list? Drop me a DM @morgancheatham!

---

To continue supporting the Healthcare Product ecosystem, Dhruv Vasishtha and Out-Of-Pocket are gearing up to create a short bootcamp on Healthcare Product Management and Engineering collaboration. If you’re a (current or aspiring) Healthcare Product Manager, or someone who works closely with Healthcare Product folks, please consider filling out this survey to provide input on the course design!