Discover more from From Data to Product
Build vs. Buy: The Question Data Product Managers Must Navigate
“We spent years building this internal metrics system. There just isn’t another system like it, we need the 15 engineers on this to make sure it stays alive and improves.” I heard this in a consulting engagement about 3 years ago. I wonder what those companies are thinking today as data products focused on metrics management hit the market. I bet that conversation sounds something like this:
Leadership: “This system seems to do everything we need it to do, why are we making our own version of it?”
Data & Engineering: “There’s no way that product does the thing we can do internally. It would take forever to buy it and integrate it.”
Leadership: “Do we need this product to do everything? Or is the product made by this vendor good enough for what we have?”
Data & Engineering: “No. We need it do everything. Our users need all the features we have and switching would be disruptive and expensive.”
Leadership: “How do you know?”
I want to focus on this last question - how do you know?
The build vs. buy conversation creates situations in which engineering and data teams attached to their internal products defend the need of the company to manage an internal product and leadership consistently wonders if the external option might be a better idea.
This emotional dance is dangerous and creates a situation in which companies don’t get an answer to Build Vs. Buy. They just get two camps of people dug in on what to do, with little change or improvement over a period of years. If you want to make progress, you will need to answer “How do you know?” here are 5 ideas to prepare yourself to answer that question.
Define your customers. If you read this newsletter often, you’ve seen me say this ad nauseam. The build vs. buy conversation often ends up pitting finance and leadership against engineering and data teams. Surprisingly, the impacted customer is often left out of this conversation. If you want a decision to build or buy a product, you must know who the product is intended to support. Don’t answer this in broad strokes. Be specific. Talk about the personas (e.g. marketing, sales, product) affected but also make it about people who are affected.
Articulate the must haves. Define what the product must do and what it would be nice for the product to do. I’ve seen countless situations in which companies end up focused on esoteric features that only a couple of people use. Entire meetings have gone off the rails because a feature only three people know about goes to the chopping block. It is critical to focus on what, exactly, the product has to do. If you cannot answer this, you cannot answer the question - does the external option do what we need?
Don’t get caught up in the pricing too early. It is extremely common for build vs. buy conversation to go to pricing far too early. My experience is that defaulting to pricing is an easy way out of a more complex conversation. The “cheaper” often usually doesn’t end up being cheaper long term. But I see so many people jump quickly to “how much will this cost us?” If you can, try to guide the conversation away from the giant $$$ in everyone’s mind.
Define the value created. Instead of going immediately to $$$, tie the product features (both internal and external) to value creation in the business. I know it might be frustrating to hear the question “so what does this do for our bottom line?” Try to think about it this way: you don’t need to give dollar figures - you need to explain what value comes from different parts of the product. It is one thing to say “the data scientists would be frustrated if this feature wasn’t there” but another entirely to say “if this feature wasn’t available we couldn’t get real time insight into our multi-million dollar marketing campaigns.”
Be real about costs. There are many costs - not just the sticker price of a product. Integration costs are a black box that scares everyone, including me. Yes, an external product will require integration. Yes, it will likely be hard. Yes, this will probably disrupt existing workflows for a time. No, that isn’t a reason to say no to the Buy option. Rather than shape your cost story to align with your preferred outcome - be real about the cost story. I see many people afraid to show that their preferred option is more expensive. More expensive is okay if it delivers the value necessary for the business.
The Build vs. Buy conversation is extremely challenging to have. It can be emotional, it can be lengthy and it can create strained relationships in a business. As you begin to build your case, as you work on guiding the discussion and as you work toward a decision, remember this: “How do you know?” is the single most important information you can provide. If you can answer it - you’ll change minds. If you can’t - you’ll end up exactly where you started.