Tim Cook on Apple’s approach to deciding when to build:
“We believe that we need to own and control the primary technologies behind the products we make, and participate only in markets where we can make a significant contribution.”
Jeff Bezos on AWS and deciding when to buy:
“We build muck, so you don’t have to.”
Product people regularly face a critical decision: whether to build solutions in-house or purchase existing ones, and if building, to what extent. These are common tradeoff decisions that many PMs and product leaders will have to make at different points in their career.
The excitement is often palpable when teams are starting to build something new; the thrill we get from starting from scratch and experimenting. This is often compounded by the Dunning-Kruger effect where people overestimate their abilities, working in a state of blissful ignorance and understand the work and (hidden) cost of building. Like strategy, deciding whether to build or buy is a choice and one that needs to be made carefully.
There’s no silver bullet that will help us make better buy vs build decisions but there are several factors worth taking into account when deciding to build or buy:
Decision factors
Investment Cost — What is the cost of the off-shelf alternative? How does this compare to the cost of building in-house? When we look at the pricing of solutions available in the market we should compare this against our the cost of building — now and in the future (don’t fall in the trap of forgetting about ongoing maintenance cost).
Opportunity Cost — There’s also the challenge of opportunity cost when we choose one alternative over another. What won’t we be able to do when we build a solution? Consider speed to market and whether your business will miss out on other market opportunities if you decide to build.
Differentiated value — Do we have a right to play in this market? Can we win in this space? To answer these questions we need to understand our core value proposition and capabilities. Would building a solution strengthen our product offering? How would the solution help us differentiate in the market?
Timing — How quickly do we need a solution? Can we meet customer or business timelines if we build? Speed to market is a big advantage of buying a solution, but don’t underestimate the work of integrating with an existing solution or customising it to meet your specific needs.
Control — Do we expect to add specific features to the solution in future? How much control do we want over the solution’s functionality and technology? Deciding to buy a solution typically means being dependent on the vendor for updates, maintenance and additional features. Avoiding this dependency is one of the reasons why companies will often consider open source solutions when evaluating build vs buy.
Evaluating these factors is complex, and companies often choose a hybrid approach combining built, bought, and open-source solutions. Notwithstanding the complexity of many build vs buy decisions, there are situations where either option feels obvious:
Buying feels obvious
- When the solution that you’re looking is far removed from your company’s core competency.
- When the solution that you’re looking for has been solved by many others (it means that you pay for someone else’s lessons learned and subsequent product improvements).
- When you don’t have the capacity to fully maintain and update the solution throughout its lifecycle (and there are SaaS vendors that will automatically upgrade for you).
Building feels obvious
- When we strongly believe that we can differentiate through building a solution ourselves, with the capability being core to our value proposition (and we’re confident in our ability to build and maintain the solution).
- When it’s cheaper and faster to build instead of integrating with a 3rd party solution.
- When we believe that no one can offer the unique solution that we’re looking for (and we’re convinced that we need a bespoke solution).
Main learning point: Start by evaluating how the solution aligns with your company’s core competencies and value proposition. This foundation will naturally guide your assessment of costs, timing, and other buy vs build decision factors.
Related links for further learning:
- https://productcoalition.com/buy-it-dont-build-or-you-may-violate-product-management-s-golden-rule-1f53761c1581
- https://productsthatcount.com/build-vs-buy-a-product-manager-s-guide-to-not-building-things/
- https://medium.com/startup-frontier/build-vs-buy-8854eab0a3ba
- https://www.youtube.com/watch?v=9tWEKHXnpoM
- https://www.linkedin.com/pulse/build-vs-buy-make-beer-taste-better-sean-o-neill/
- https://www.linkedin.com/pulse/build-vs-buy-open-source-perspective-gil-yehuda/
- https://medium.com/box-tech-blog/finding-the-perfect-solution-build-vs-buy-vs-open-source-1c316fe28b98
- https://skamille.medium.com/why-is-it-so-hard-to-decide-to-buy-d86fee98e88e
- https://www.linkedin.com/pulse/technology-build-vs-buy-modern-perspective-steven-stone/
- https://www.asymco.com/2011/01/17/the-cook-doctrine/
