Leader Spotlight: Build vs. buy approaches for healthcare tech stacks, with Omar Mousa

Omar Mousa is Vice President of Product at Ventricle Health, a virtual platform focused on cardiac care. He began his career in strategy consulting at IBM before transitioning to a PM role focused on patient experience at Propeller Health. Before his current position at Ventricle Health, Omar worked in various product management roles at Cerebral and headed growth and strategy/operations at Adonis.

In our conversation, Omar talks about deciding whether to build, buy, or take a hybrid approach to creating and scaling health tech solutions. He shares a matrix he uses to evaluate cost and automation opportunities for workflow tasks. Omar also discusses best practices for creating a frictionless telemedicine experience.

A hybrid approach to leveraging solutions

To start, could you provide an overview of Ventricle Health?

Heart failure is a high-spend, high-utilization disease; it’s costly and has a high mortality rate. Ventricle Health is a high-quality, tech-enabled, specialty care service for heart failure. Our goal is to enable better patient behaviors, drive clinical outcomes for patients with heart failure, and reduce the total cost of care. To do this, we partner with payers and at-risk medical groups, and we’re innovating a payment model to drive the outcomes that we desire.

Ventricle Health is a healthcare company dedicated to providing advanced cardiac care through a virtual and home-based model. By leveraging technology and evidence-based protocols, we enhance access to high-quality cardiac care. A key aspect of our approach is utilizing guideline-directed medical therapy (GDMT) to ensure patients receive the correct medications and dosages tailored to their needs.

Additionally, Ventricle Health employs its technology platform to understand patient health and effectively stratify risk, prioritizing care for high-risk patients. This strategy optimizes treatment outcomes, minimizes side effects, and prevents hospitalizations.

In healthtech, some companies build their own solutions, some use existing solutions, and others take a hybrid approach. Which approach do you feel is best?

My recommended formula changes by the stage of the company, but in general, I’d say a hybrid approach is usually best. There are so many challenges you can run into when you buy pre-built solutions. For example, you may be unable to compete with companies that develop their own custom software or intellectual property. If you’re not developing your own IP from core product experiences and, therefore, not winning those categories, you won’t impact clinical, operational, or financial metrics beyond what your purchase product can do.

On the flip side, In a world where you build all your solutions, you are effectively reinventing the wheel early on when your goals should be to go to market, learn, and iterate on your solution. Building customer software to start creates a lot of technical debt upfront because you will not fully understand your users or your business case. You will spend a lot of money and time without the promise of revenue, and you’ll effectively be crushed by the current landscape. Capital is expensive right now — meaning there aren’t enough resources to reinvent everything.

I think the hybrid approach is generally best. Build custom software for things that are core to your business. This will allow you to drive down costs, increase margin, and ensure sustainable unit economics where it makes sense to do so. It’ll help you to achieve clinical outcomes to compete in a saturated market. Then, save on resources by relying on purchasable, pre-built solutions for everything else.

Can you give an example of this hybrid approach in practice?

Take patient scheduling for example. That’s already been solved for. If only one small component of my company’s offering is to schedule patients with providers, I don’t necessarily need to be the best at that. I can buy a scheduling solution and integrate it in a way that makes sense for my platform.

For example, Ventricle Health is in the cardiovascular care space. We may prescribe medication, increase dosages, add more medications over time, and reoptimize the titration mix. We need to be really good at this because it is essential to our heart failure offering. This is why the hybrid approach is always best — you just need to buy software that allows you to even build.

How build vs. buy changes by company stage

You mentioned that your recommendation changes according to the company’s stage. Can you elaborate on that?

In an early-stage company, you’re optimizing on solving for use cases to prove a hypothesis. There is no conviction that you are what you think you are — you still need to go to market and prove that. The best approach here is generally to use existing solutions. You want to be cost-effective and optimize on speed to market. You don’t need to be super scalable, but you need to think about scalability and integration. To some degree, you can be messy because you just want a proof of concept.

For growth stage companies, you’re prioritizing revenue and plan to be a bit more (but not overly) cash efficient. This is where you start to invest in the hybrid approach. You’re still buying things because the pre-built solutions will do the jobs you need, but your focus is on customization for differentiation in the market. Your product needs to stand out and you need to make balanced investments. This leads to some investments into building, some investments into buying, and flexibility with integrations.

Then there are mature companies. This is where you start to move from cash-inefficient to long-term, sustainable unit economics. You’re building mostly custom software at this point, tailoring solutions, and you’re in control of how you’re creating user experiences. You’re thinking about long-term ROI as well as continuous innovation. At this stage, you’re predominantly building custom software. You might even be buying other companies.

The big takeaway here is to invest in what’s core to your model. You should always custom-build in areas that your product needs to be best-in-class.

Say you have an early-stage company that’s starting to move into growth stage and wants to start building custom software for some core functionalities. How should they think about prioritizing that?

Always start with North Star metrics and think about the business objectives. You need to be effectively optimizing for the most important metrics. You’re prioritizing against, “This got me so far into this particular use case. I’ve solved for it, but is it meeting the market need? Does it require additional implementation or a better user experience? Is it hitting the bar that I’ve set?”

If you’re still thinking about moving on to the next use case because your go-to-market solution is incomplete, focus on investing in that. But once you’ve hit all those use cases, you need to start thinking about where performance is most valuable and bring that value to stakeholders.

So, always prioritize with metrics. You shouldn’t be working on anything that doesn’t map up to the North Star metric.

A matrix for evaluating cost and automation

For companies that are considering investing in pre-built solutions or technologies, what are some criteria to keep in mind when evaluating options?

I like to look at all tech stack decisions as a build versus buy. For the buy decisions, I consider all of the following criteria:

Capabilities and use cases — Does it solve the use case you need? In the scheduling example, does the calendar schedule appointments with patients? Does it allow a patient to reschedule or cancel? What about enabling custom appointment types? Does it enable different personas?
User experience — Does it not only solve your use case but do so in a way that’s better than the competition? Do people enjoy using the solution? An example I like to use is selecting a CRM for patient relationship management. Salesforce is highly customizable and can truly solve anything in healthcare. However, HubSpot has a far superior user experience. If that is something that matters to the user, then HubSpot might be the better choice
Scalability — Is your architecture modular? It should support adding new functionalities and scale components independently. Can it perform at scale? And, most importantly, are you backing yourself into a corner with decisions that will prevent you from making any other decisions or trade-offs in the future?
Flexibility and customization — Can you customize and configure the solution from the product without having to build anything or spend development resources? Does it have APIs to allow for custom development down the road? Does it have a flexible data model?
Security and compliance — Are there robust permissions and access control of data? Is PHI overly permissive? Does it comply with HIPAA and other relevant regulations? Does the company sign BAAs (business associate agreements)?
Cost and ROI — What is the total cost of ownership of this technology? What is the expected return on investment? Does that cost scale over time as user volume goes up or if the use case becomes a little bit more complicated?
Vendor reputation — What do other similar companies have to say about this vendor? Will this vendor survive the long haul? Do they have cash?

For the build decision, it’s actually a lot simpler. Is this use case core to your business and a point of differentiation for you? If so, you should probably build it. Whether or not you can build it better than the existing market solutions out there is also a consideration. Can you drive a metric better than the existing solutions out there? If that metric is a clinical outcome, for example, and that’s the only way you’re going to win in the market, then you have to achieve it at all costs.

Could you talk a bit about your approach to identifying how to reduce the total cost of care in the delivery of the health tech services care model?

With any care model, there are tasks, as well as certain personas executing against the tasks. Tasks require a skill level and a clinical base of knowledge, and I like to create a two-by-two matrix. I map out if the skill is transactional, knowledge-based, or a mix of both. Is it not clinical at all, moderately clinical, or highly clinical?

Creating a frictionless telemedicine experience

In a telemedicine setting, how do you ensure a seamless user experience for both the patients as well as the providers?

I think of this in five buckets:

Interface and design — Is the product intuitive? Did you create a user-friendly and consistent interface that is easy to navigate for both patients and providers?
Seamless integration with the EMR, EHR, or other platforms — You want to ensure that the right data is being surfaced at the exact points of care
High quality — Video and audio have to be good. There should be no latency and downtime will need to be solved for
Technical support — You always have to have good support, whether it’s on the clinical side, how to use devices, or how to use the services. If something’s not working, can the user call someone quickly to get it working?
Regular user feedback and iterative improvements — Are you collecting feedback from users regularly? Are you making continuous improvements on the platform based on their input and the goals of the company? The idea is to marry those together. This is the product team’s job, but the user is at the center of it because they’re ultimately the ones using it

A seamless, frictionless user experience is key for getting users on board. What about also keeping them active in their healthcare plans and making sure they’re engaged?

With any product, onboarding is a huge input into retention because getting users to activation is the “aha” moment. My goal is to get them there. It’s also important to drive this adherence with certain nudges, and with good device performance.

For onboarding, checking, and tracking information, our team makes sure that the package the patient is expecting as part of our services is moving efficiently. When we have a suspicion that the patient has received the package, we call or text them to ensure that it was received. They might get the package and say, “I don’t know what to do with this,” and it ends right there. So, we set up appointments with patients to set up the devices.

We also create triggers and feedback loops for device usage. These devices are sophisticated, so we need to educate our patients on how to use them. And regarding adherence, we want to show them that we care. We let them know that we are continually monitoring the data. We call them if we see anything abnormal or if the device hasn’t registered any new data in a few days.

We also sometimes nudge the user’s caregivers. Social pressures are a great thing. Patients are likely to do things if a caregiver or a provider — or someone of clinical authority — is recommending it. We leverage this when it makes sense, and we incentivize patients with things like coupons, rewards, or gamification.

You talked a lot about the different signals that you’re looking for in terms of the device and usage. What about the voice of the customer — not just for onboarding, but the feedback loops from the customer that help with iteration? How do you collect that from them?

We do this in a couple of ways. One is transactional feedback surveys. We have existing patient populations that we can survey if we have a hypothesis about them and want to get some answers. We also use in-app feedback tooling to identify friction points from our users. External tools are great for this and flag issues as they come up. We also instrument our application so that we can capture user behavior too. I want to see how people are actually behaving in the app, and I’m going to make assumptions based on that data.

Focus groups are another good method. We’ll often create a panel and leverage our champion patients who love the product. They want to help us as best they can, and they’re our trusted people, so we like using them for focus interviews.

Then, we take all of this data and create a voice of the customer dashboard, which we review frequently. Every product manager that I work with constantly evaluates that sort of data. They need to be champions of the customer’s voice. Whether it’s the transactional collected data or user analytics that we capture from tools, our product managers rely on that data to make better-informed product decisions.