As a product management leader, I’m constantly considering priorities, evaluating tradeoffs, and figuring out how best to allocate our resources to build products that help our customers achieve their goals. The buy, build, partner framework has been instrumental in helping me and my teams assess the best path forward when deciding how to acquire (buy or partner) or develop (build) new capabilities that will help us meet our business objectives.
At Moxe, we’re constantly thinking about how we can reduce waste in healthcare. That mentality infiltrates our internal decision-making processes, too, and has shaped our approach to answering the buy, build, or partner question. In our mission-driven culture, the framework isn’t just about our own growth: it’s about how we can be better, faster, and more cost-effective so we can help cut waste in healthcare, not add to it.
At the center of our buy, build, partner framework is a key question: “What are the things we believe we can do better than anyone in the market?” Increasingly, our buy, build, partner framework pushes us to focus on these things, while determining how we can partner with others to achieve our strategic vision and best serve our customers. Using an architectural analogy, we want to focus on building the pillars of data exchange and work with our partners to put buttresses, or supporting structures, in place.
So, what are those things we believe we can do better than anyone in the market, our “pillars”? We believe we connect into the provider ecosystem and acquire data for payment and operations use cases better than anyone in the market. We also package and deliver that data when, where, and how it’s needed, all while fiercely protecting patient privacy and data security. In short: Our pillars are the privacy-centric acquisition and exchange of clinical data.
Using an architectural analogy, we want to focus on building the pillars of data exchange and work with our partners to put buttresses, or supporting structures, in place.
While we choose to allocate our build resources primarily in support of our pillars, we recognize the criticality of the buttresses in making our solutions best-in-class. It’s because we recognize the important role that buttresses play that we have developed processes to 1) decide when we should build, buy, or partner; and 2) select the best partner possible when we’ve decided that’s the best route.
Our goal in answering the buy, build, or partner question is to do so as quickly and thoughtfully as possible. To that end, we use an “AC” matrix, a derivative of the RACI (responsible, accountable, consulted, informed) responsibility assignment matrix to set exploration of potential partnerships in motion. The AC matrix ultimately leads us to a decision point: Do we conduct an experiment with a potential partner?
When the answer to the experiment question is “yes,” we have a robust experimentation process in place to help us determine if a potential partner is a good fit. Our process always includes a problem statement, hypothesis, experiment protocols, and explicit success criteria. Stating clear parameters and success criteria helps our potential partners understand exactly what we’re looking for and can sometimes result in self-disqualification, saving us both valuable time and money.
As we continue to fine tune our buy, build, partner framework, I’m excited to see how we might use it to help solve organizational challenges outside of software development.
One example of how we’re currently using our buy, build, partner framework is in evaluating potential code set mapping/management partners; an important capability to help our customers understand the data we deliver.
We realize that it’s neither in our best interest nor the best interest of our customers to take on code set mapping/management ourselves. Developing this capability would require a lot of upfront investment, experience, and deep expertise around which we would need to build a team. There are vendors out there doing this well. By partnering with them, we can utilize their experience, expertise, and existing investments to bring new capabilities to our customers quickly and at a higher level than we could otherwise. We are currently in the process of exploring a couple of different partnerships to determine best fit.
I was recently chatting with a colleague who asked, “What’s the alternative to the buy, build, partner framework? Doesn’t every company use it? Or, if they’re not using it, shouldn’t they be?”
I think she’s onto something there, and I thought I’d share what I shared with her, in case anyone else is similarly curious.
While most organizations operate with meaningful resource constraints, some do not. A company with resource abundance may choose to ask: Do we build it or not? In short, there are companies that choose to develop everything internally or not develop it at all.
The pros of this approach: By choosing to develop everything internally, a company maintains complete control over its product. They retain complete ownership of the entire solution; they can modify, enhance, or tailor it to their exact specifications; and they can create tighter connections between the various components of their solution, since the entire feature set has been developed by people who are all in the same (metaphorical) building.
On the flipside, I think that failing to evaluate what’s in the market already that may be able to meet customers’ needs better, faster, and/or more cost-effectively, is doing a disservice to those customers. It reminds me of a remark a colleague made once when asked whether we should build a FHIR server to accompany a new FHIR API product we were developing. They said, “‘I don’t think they give out medals for having the 8th best FHIR server in-market.” In asking the buy, build, or partner question, we’re trying to stay true to our mission of eliminating waste in healthcare, while ensuring there aren’t inefficiencies in our own solutions.
As the industry slowly, but surely, continues to make its way down the path of interoperability, I’d like to see more healthcare tech companies adopt the buy, build, partner framework. I believe wider adoption of this framework in the industry would allow stronger interoperability solutions to emerge faster and more cost effectively.
I like to think that even if Moxe had no resource constraints, we’d still use the buy, build, partner framework to make decisions that mutually benefit us, our customers, and the greater healthcare ecosystem.
Ready for more on Moxe?
Learn more about Moxe's modern approach to Release of Information. There is a better way.