How to build a multi-sided network
Nov 21, 2016
At Redox, we’re building a multi-sided network of health systems and healthcare technology vendors on a foundation of interoperability and ease of adoption. The value props for each side are simple but powerful: health systems get a single connection to cloud-based applications, eliminating redundant infrastructure costs and reducing the interface management headache, while applications get a single API to connect to that allows them to interoperate with dozens of systems being used at the hospitals and provider groups they sell to.
In this article, I’ll describe the steps we’ve taken to build this network and the major decision points we’ve crossed along the way.
Step 1: Pick a loss leader and start subsidizing
The first step in building a multi-sided network is acknowledging that you can’t start out with the platform in its end state. Specifically, no one wants to join an empty platform, so choosing one side of your network to market to first and subsidizing their interactions is an extremely important first step. A great example of this is how Uber got started: they subsidized drivers to be available even if there were no riders. This maintained their supply until demand caught on.
The idea is that you find a single-sided value proposition for your loss leader that encourages early adoption. This is something from which they’ll receive value, and more importantly, it’s something that will keep them engaged while you build enough momentum to realize your network potential.
At Redox, the application developer community is where we directed our initial focus, and we were able to subsidize their interactions with our platform by providing free developer tools. These tools allow application developers to create a fully-simulated integrated workflow without needing to have a health system implementation on the other side. In doing so, many early-stage companies came to us to help them get past their own chicken-and-egg problem of needing to demonstrate integration before signing with their first health system.
There are a few key factors to consider when choosing which side of your network to subsidize:
Speed of adoption
Keep in mind that this is the infancy stage of your network and you want to progress rapidly in order to get through it as quickly as possible. Meaningful growth is what’s important in this stage, and targeting what can achieve that for you the quickest is what you need to do. For Redox, getting an application vendor to sign up to the platform was as fast as a website conversion or 15 minute phone call, whereas anything involving getting a health system on board required many weeks or months.
Cost of loss
Consider the cost of effectively subsidizing one side of your network vs. the other. Our consideration revolved around the cost of creating developer tools and a “freemium” developer account on the app side vs. trying to create our own app that could get us in the door at health systems. The cost to ramp up the application side of our network was much lower than delivering an all encompassing solution direct to health systems.
Ease of iteration
During this period of your network growth, you’re going to learn a ton about your market and the needs of a certain segment of your customers. It’s exceptionally important to make sure that you can quickly iterate on the components you’re subsidizing. What this meant for Redox is that the lightweight developer tool features in our platform were key. We were able to quickly add requested fields and even publish entire new data models to support use cases desired by users. Choosing the application side of the market allowed us to work with hundreds of groups so that it was clear where we should devote our time versus working with a large enterprise and making changes that may only be relevant for that single (albeit significant) customer.
Step 2: Unleash your loss leader on the other side of your network
Fast forward a bit and hopefully you’ve established a critical mass of engagement and gotten the subsidized side of your network thriving—aka, you’ve begun to receive interest from the other side in your platform. At this point, it’s time to swing your focus to the other side of your network.
After growing our developer network, it was necessary to shift our focus to the health system side and get them equally involved. We accomplished this by providing a Gallery where health system users can discover our application community and find out which they’d be interested in based on the initiatives important to them.
At this stage, you should be closely tracking the economics of your platform to ensure the network scaling effects of a well-built, multi-sided network are taking hold. Your platform should experience both demand-side and supply-side economies of scale as it grows—that’s the whole point!
Demand-side
As membership and utilization of your platform increases, so should the overall value of each participant to the other side. At Redox, this is done by shifting what’s traditionally been a 1-to-1 integration model to one that uses a centralized and reusable infrastructure. Application developers only need to design once to unlock the full network of health systems. Similarly, health systems have reusable infrastructure that allows them to bring in any number of solution vendors. By decoupling the intake effort required from both sides, one side receives immediate marginal value when a new organization joins the other side.
Supply-side
As your platform is used more, the cost of goods and acquisition are reduced. At Redox, we help reduce costs in three main categories:
Financial
Time
Risk
Prior to Redox, integrations were done point-to-point and were often expensive hourly services engagements. These projects, due to their custom nature, were often 3-6 months long, whereas with our platform today, we can connect an application and a health system in under two weeks. This efficiency greatly reduces the cost involved as well.
Most importantly, and perhaps most nuanced, is the cost associated with risk that our platform reduces. Typically, when an application vendor and a health system sign a contract with one another, they’re often acting on faith that their investments will be reflected in the final product. We’ve worked with health systems to completely reimagine the RFP process by leveraging their Redox infrastructure to have solution “bake offs” with real users and workflows prior to making a full purchase decision. This reduces risk on both sides by allowing for more realistic expectations going into the business relationship.
Step 3: Optimize via automation and discovery
The final stage of your platform (and one that you’ll never be “finished” with) is to optimize the discovery and interactions that occur within your platform. You can also think about this as optimizing the Supply and Demand sides that we established in Step 2.
We’re just now entering into this phase at Redox. Our initial efforts have focused on automating our internal processes to facilitate faster onboarding of health systems. We’ve driven our onboarding time from 6 weeks when we initially launched down to around 2 weeks today with our fastest being 9 days.
Our next big push will be automating steps which Redox customer success staff need to manually do today to facilitate connections. One example, allowing health systems and applications to review and approve legal/contractual documentation directly through the platform. By doing so, we’ll drive more direct discovery and purchasing interactions through our platform.
The power of a realized multi-sided network
It took years of thought and effort, but we believe building a multi-sided network of health systems and digital health vendors is the only way to efficiently adopt new healthcare technologies. If all connections are developed point-to-point, information will remain isolated and we’ll never achieve the efficiency of scale that is necessary to lower healthcare costs and accelerate the rate of adoption.
We have taken a strategic approach to building our network and are at a tipping point where enough nodes in the network exist to realize the significant advantages of this approach.