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.
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.
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.
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 eventually build.
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.
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.
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:
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.
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?
Once I create this matrix, I can see the collection of tasks that require my care model to be executed against. Then, I can look at the people who are doing each one. A heart failure patient has a team of professionals — a cardiologist, registered nurse, social worker, and medical assistant. All these people have costs associated with them, and their skill sets are best used on specific things. If I build the matrix and say, “This task is highly transactional and not clinical at all,” then I can make the recommendation to automate it.
If a task is transactional but highly clinical, then I need to partially automate it and ensure that the clinical portion of that skill is still performed by a human. I want to ask the clinician for the right thing at the right time, while also not bogging them down with the transactional nature of the task.
This matrix is great to help understand the total cost of delivery, cost of revenue, or cost of service to take care of patients. It gives insights into what costs the most so you can potentially build solutions for that. I’ve found this framework to be really helpful across multiple industries.
I think of this in five buckets:
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.
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.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
Learn more →
