Ten key considerations for Build vs Buy in your product journey

As we begin 2021, let’s explore some salient points and key considerations for a build vs buy decision in your product journey. If you come from an engineering mindset, the natural inclination is to build things as that is what you take pride in. If you come from a business perspective, the interest is to get a profitable product, often leaning towards a buy to make an impact in the market. As a product manager, let’s take a balanced approach to making the right decision or advising to build or buy.

Penned down some 10 Key considerations that can be useful in making this decision based on my experience of doing some due diligence as well as being part of the decision making process. The focus of this blog is in the context of software products companies, but could be applicable for other products as well.

  1. Faster to market: as pointed in one of my earlier blog, timing to market is a key aspect for products. Let’s consider the current pandemic situation and one of the areas is digital foray including video / online platforms. Many companies have looked at getting to the market faster and may lean towards a buy as it could get them faster by 2-3 years.
  2. Solved vs Unsolved Problem: solved problems are another area for usual buy whereas for unsolved problems you may need more R & D, and therefore a build approach may be more suitable. Solved problems with a good market could be bought over and integrated for better penetration.
  3. Unique IP: connected to the previous consideration, there may be a unique solution IP that solves some unique problems, while it may make sense to invent and build if you find that unique IP, it’s very much possible that you can consider buying out for the IP. We have seen a lot of such things in ML / AI area or in other emerging tech.
  4. Aligned Tech architecture: in software, one of the other consideration when making a buy decision is to understand the tech architecture and if it would be easy to align and integrate the tech into the overall architecture, how much effort is it to integrate, whether the buy would stay standalone, etc. Many times, while the decision may be towards buy to get faster to market if the tech is too different and if there is enormous effort to integrate, it may be more suitable to build it.
  5. Culture fit: the faster to market is ticked, the tech architecture is also ticked, but when you buy it’s not just the product but also the culture that matters a lot. Lot of buy decisions may make sense, but have failed with a misfit in culture of the companies that are buying vs that is being bought. The company that is buying may be a large company and the company that is being bought is a small startup but with some passionate folks, or they may be having a risk-taking vs risk-averse culture.
  6. Price of buy vs cost to build: beautiful, the reasoning is all good, there is tech alignment, and sounds like the culture will be good – but what about the price. What is the viability of investments? This is more of a financial decision, sometimes it could be based on product-market fit, and the timing balanced with price of the buy. What would it take to build this, whether the market is going to grow after a certain period, so building would be better option?
  7. Customers or Users: this is another clear business reason to buy a product. A certain product may be a very successful product, has a huge user base, the buyer company sees a huge synergy of upselling their other products to this customer base or users. This may be useful when you want to expand to a new user base e.g. selling to Sales while you have momentum with Finance.
  8. Talent: we have seen this sometimes, there is a niche product or a popular product, but more than the product, the consideration is the talented engineers or the founder behind the product, their knowledge of the domain, their unique understanding of the problem statement or their reach to the customer network. When you have to build something, it’s going to be hard to build a product team that runs together in unison. Another side of the argument here is if you have a talented team that has a great understanding of the problem statement as well as the technical acumen, it may make more sense to build the product.
  9. Expansion front and back: often product needs more features or needs certain areas for vertical/horizontal expansion on the front or back of existing products. It could be some failed attempt at building that will lead to buy or could be an unsuccessful buy that would lead to build. Sometimes it could be buying an application that showcases an use-case for your product  and at other times it could be building a platform that is behind your application to bid adieu a competitor dependency
  10. Data: this is another new area for buy decisions. To expand your platform you need data, for which another product acquisition can help. Leaving aside any legal implication, this has become an important consideration in a buy vs build decision

Making a buy or build decision is a key aspect of software product lifecycle and growth. Hope the above helps a bit

Wishing you all a great 2021!