Building vs Buying Data Products: Don't Get Stuck in the Middle

Let’s get this part out of the way - I don’t have the right answer to build vs. buy. For some companies, building will make sense, for others, buying is clearly better. However, for most, the answer lies somewhere in the middle. “It depends” is a deeply frustrating answer, but it is also the truth. The problem is that leaves a company straddling the fence on a decision, without fully committing one way or the other. My focus for today is how to get off the fence, and move toward a decision. I make no claims that there is a “right” decision.

For a whole host of data products - from experimentation platforms, to metrics tools and libraries, to analytics tools and platforms, there is an increasing abundance of options. With an increase in options comes an increased intensity in the build vs. buy discussion, particularly when companies are scrutinizing headcount and spend. I bet you’ve heard some discussions that sound like this:

• “It is pretty risky to have our home grown product, when the person who knows about all of it could leave and we’d been in some trouble.”

• “If we were just starting out it would make sense to go with third party, but we’ve invested a bunch of time and integrated this product into our stack, it would be hard to unwind.”

• “The migration costs to go from our homegrown world to external would be huge, and I’m not certain we’d be able to support it".”

• “We went with this out of the box solution but there’s a bunch of stuff we want to do that we can’t add on without them prioritizing it as a part of their roadmap.”

• “It would be great to have someone else manage this product, but what if they suddenly increase the price, we’re back to where we started.”

As I’ve met with people across the industry, I’ve learned that these discussions are far more similar than they are different. In every situation there is a desire to manage costs, support the company’s competitive edge, and reduce the risk of having specialized knowledge walk out the door and leave the company in a bind.

With the constraints described above, it is not surprising that “decision paralysis” happens frequently. As I met with engineers, data scientists, data product managers and technical leaders, what I found was not a regret about building or buying, but a frustration about not choosing a clear path.

So, what is one to do? Here are a few observations I made about those companies who were able to get off the fence and commit:

• They clearly understood if the data product was part of their competitive advantage. If it was, they usually kept it in house and invested in people to expand its capabilities. If it wasn’t, they eventually moved to a third party solution and focused on identifying the migration costs. In other cases, this exposed that it wasn’t clear what their competitive advantage was!

• They treated the build. vs buy decision like a product “go or no go” choice. It can be really easy to let months or quarters go by without making an active choice as long as there doesn’t appear to be an existential threat. However, putting a hard timeline on a decision and formalizing the choice just as a product team may do with a go/no go decision can be incredibly productive.

• They clearly mapped out the direct costs, the expected growth in those costs and the opportunity costs of one approach over another. One problem that keeps companies on the fence is a lack of rigor around cost. Being very general here often supports decision paralysis. Why? Because its most likely that each option is expensive in the long run. But understanding exactly what those costs are and why they would make sense to pay is most critical.

• They dove deep into the skillset required to build and develop a data product in house. Sometimes the skillset is easy to find but in many cases, it requires a unicorn of sorts. It can be problematic to have the person making the decision (potentially a high level leader) without enough context about how specialized the skillset is.

• They pushed the decision downward rather than upward. They allowed those closest to the problem to make a determination about what the right thing was for the company, rather than pushing it toward a senior leadership decision. That doesn’t mean they made the “right” choice, but they were more likely to not be stuck on the fence.

All of the above is to say that there’s probably not a right vs. wrong answer. It is much more important that a decision is made with complete information with an understanding of the role that data product plays in the company strategy. If you are reading this thinking “I wish we could get off the fence”, just know you are not alone.