Moneyball: How can smaller Health IT companies hit a homerun (or at least get on base)

In 2002, the Oakland A’s season became one of the most successful seasons in the team’s history. The team's general manager, Billy Beane, successfully pivoted the strategy of one of the lowest budgeted franchises into a tremendous winning streak that would change baseball forever. Many of you are likely familiar with the book Moneyball by Michael Lewis or the subsequently produced film starring Brad Pitt. But the lessons learned here apply to more than just baseball.  

So how can a small Health IT company compete with industry titans despite differences in capital, resources, and scale? By not trying to be like them.

Billy Beane used, sabermetrics, an empirical analysis framework developed by Bill James, to focus on what was important, getting on base. This meant he would not be enamored with how players were valued or viewed by the industry, but looked at what statistical attributes contributed to a team achieving more runs per game.

Now if we look at Health IT market, there are many areas in which companies and venture capitalists assess ‘value.’ Many times, this value is assessed loosely on the need of a use case across different organizations, but not specific to any particular user group, the bigger the market, the higher the value. Just look at the recent losses in public insurtech companies following billion dollar valuations. Many Health IT companies focus on a broad use case—such as care coordination—and attempt to build a general solution, complemented with a suite of features that may or may not be value added. This results in a scalable product, but is it value added to the user? If we reflect on the 2002 strategy of the Oakland A’s, the focus was about runs per game, or more specifically, it was about getting on base. What if we considered high user engagement, "getting on base?”

How might a company implement this strategy?

One of the more controversial things Billy Beane did was restructure the team—trading ostensibly ‘great’ players for others not considered as such. But this was necessary, he was trying to realign the team by taking the subjectivity out of what the management and scouts valued as good attributes for a player and team.

Companies should consistently reevaluate their product features based on what their users actually utilize. The difference between a winning feature and a losing feature is subtle, and it comes with an intimate understanding of your user base.

Things that probably aren’t winning concepts:

• A ‘dashboard’ for everyone, which really means for no one.

• Not having a member on staff with previous experience such as physician, social worker, or medical biller that aligns with your target user base.
• Clinical information displays for an organization that doesn’t use clinical data.
• An analytics platform with less functionality than excel, or worse yet, limited or no access to the data you generated in the system.
• No ability to integrate with other systems (The concept of this system is the only one you will ever need).
• Making the product incompatible with itself (Two instances of the product in the same community that cannot be merged or communicate with each other).

• Inflexible group permission structures, forcing organizations to fit their staffing hierarchy into the constraints of the product.
• A scheduling feature that is restricted to the system with no connectivity to external calendars for notifications or edits.
• Lots of ‘canned’ reports that almost never align to the needs of users.
• Several backend partnerships to route claims to payors resulting in fragmented revenue cycle management.
• Little to no customer support along with no awareness to the policies and reimbursement methods for a program/organization.

Now, some of you may say, these seem like obvious things a product team would consider, but I have noticed that many of these issues tend to surface frequently post implementation or in year one of product go-live.

But beyond product features, the hyper-specialization of the core product should be more valued. It is not enough to provide a general care coordination or referral tool. A product that meets some needs but not all needs of a user will inevitably lead to vendor churn for the organization, or worse, an organization having multiple systems for a single use case. For many healthcare and social service providers in California, this is the current state, multiple systems that meet some needs, but not all needs.

But doesn't focusing on more specialized use cases reduce the potential market and create more system variability?

Perhaps. But some of the best Health IT companies I have seen, ones that have a loyal user base of clinicians, case managers, or speech pathologists, are hyper-focused on the users they support. These vendors are aware of the policies governing their user's program, they have dedicated customer support teams, they are extremely flexible to getting data to/from other systems, and may even manage reporting for them.

Furthermore, it is unlikely that any organization will just need one or two comprehensive systems, this should not be the goal, but more so to ensure that fewer users need multiple systems for their primary role. It is a night and day difference to hear an organization discuss Health IT vendor challenges and others talk about how they cannot operate without them.

So, maybe trade a broader market of indifferent users for a more specialized market of devoted users?

Specialized examples I have seen:

• Behavioral Health billing solution for elementary education.
• Case management for transitional aged youth (TAY) with asthma.
• Medically tailored meal ordering system between a health plan and food pantries.
• Telehealth care navigators for neurodivergent people.

• Asynchronous video application for tuberculosis direct observational therapy (DOT).

Each one of these use cases comes with unique features and policies that a general Health IT solution will not comprehensively address. Consequently, these types of companies likely have less need for a large marketing budget since they know their market and benefit from high referral rates.

However, community organizations remain mired in several overpriced “solutions" that still do not accomplish their goal of providing efficiency to the user and their patients. After all, that is what technology is supposed to do, improve upon a process, not obfuscate it. I can only hope that by drawing attention to the inadequacies within some of these broader health and social care solutions, we will start to see quality vendors emerging.

Lastly, for those opposing the strategic shift from broader to specialized use cases as not a feasible return on investment (ROI) strategy; I would encourage you to look at how Zoom defeated Cisco WebEx, how Slack is preferred to MS Teams, and how focusing on stamp, coin, and other collectibles led to eBay. These use cases were saturated in the periphery of bigger companies and considered small and unworthy of pursuit. However, as we know now, specialization in these use cases disrupted the industry, much like Billy Beane did in baseball. Building immense value for a small group of users will inevitably lead to better stability for the company and better outcomes for providers and their communities.