A helpful analogy for knowing when to build or buy…
In the past starting a brewery in Europe was a from scratch proposition. You had to do all the activities you’d expect like sourcing ingredients and hiring help. But you also had to do everything else, up to and including generating your own power. Due to the bespoke nature of the work and location choice, prospective brewers would often have to become power plant operators. Generating power would often take more time and resources than the actual brewing. But if you wanted to strike out on your own, you didn’t have much of a choice.
Eventually brewers realized that running a power plant was not the best use of their time. In fact anything that wasn’t making the beer taste better was not something to which they should be giving focus and time. If it didn’t make their product better than they needed to find someone else to do it for them. Luckily for them there were energy entrepreneurs who had a similar realization about the brewers situation. They were more than happy to take over the power plants and let the brewers buy energy from them. This created a symbiotic build-buy relationship. Energy men could create energy and let brewers buy it. And in return brewers could make better beer that the energy men could buy after a long day.
In our product and company building we should be asking ourselves a question similar to the one the brewers asked. “Does it make the beer taste better?” Or in other words is this a core competency for us and the product? If not, we shouldn’t be building it, we should be buying it from someone for whom it is a core competency.
Build vs. Buy is often a controversial and complicated topic, but using the brewers mindset it doesn't have to be. It becomes much more black and white.
A relevant example from tech to illustrate. If we are a marketing and engagement company, we should spend our time, energy, and money building unique customer segmentation tools. But we should not spend any time building an email delivery service. There are countless companies for whom this is already a core competency. If we went down the path of building our own service, we’d be dumping resources into a problem that has already been solved. So instead of building this capability, we buy it. And buy it almost assuredly at a cheaper price, in a faster timeframe, and at a higher quality. In this way, we ensure we strengthen and expand what makes us unique, while also ensuring our messages reach their intended targets.
Two other helpful frameworks for making the build vs buy decision:
Eric Weber of the From Data to Product newsletter had a great article on build vs. buy. He framed the decision around considering what touches your customer. From that article:
“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.”
Thinking back to our examples from earlier, customers don’t care how you kept the lights on at the brewery just that the beer tastes good. And they don’t care whether you used MailGun or SendGrid, but they do care that the content in the email was engaging and relevant to them.
The other framework comes from an engineer I worked with at a previous company. He commented to me that engineers are great at making the build vs buy decision. They make it each day, often without realizing it. He explained that when starting a new project, he could build his own package for handling complex computations or he could just use NumPy. If he needed to host something online he could build his own service or he could use WordPress like everyone else. Engineers are great at using packages and open source projects to buy (often without spending money or at low cost) all the parts of their project that aren’t core competencies. This leaves them free to spend their time building the things that are unique and not easily sourced elsewhere.
A few different approaches for build vs. buy: we can think like a brewer, or like an engineer, or think about the customer. However we do it, hopefully it gets us to the same place, of building our core competencies and leaving the rest to others to build for us.
