See how you can create, deploy and maintain analytic applications that engage users and drive revenue. See a Logi demo

Product Management

The Product Dilemma: Build vs. Buy

By Yen Dinh
Share on LinkedIn Tweet about this on Twitter Share on Facebook

Sometimes, a product can be quite simple. But oftentimes, there’s more complexity than meets the eye. There’s a lot to consider when you have multiple products or sub-products, competing timelines for feature delivery, limited resources—the list goes on. Product people are faced with a decision: Build every product and feature, or buy them and integrate?

Chances are, if you and your team have reached this point, you’ve already identified a market need or your customers have presented you with a problem to address. Ardeshir Ghanbarzadeh, Senior Product Marketing Manager at Logi Analytics, talked through the “build vs. buy” debate in a recent INDUSTRY Product Interview. He shared his insights into key issues to keep in mind before making any decision.

INDUSTRY Product Interviews: Why is the buy versus build decision so important for product people?

Ardeshir Ghanbarzadeh: At its core, the buy versus build decision is also very much a business decision. Both approaches carry a certain amount of risk and cost, and this is different for every organization depending on where they are and where they’re doing their business. The reason it is essential for product people to understand all the cost drivers and potential risks is they need to be able to appropriately balance those costs and mitigate the risks when it comes to making the build versus buy decision. Because there are long-term implications, especially with software that could have a five-, seven- or 10-year lifecycle.

What factors should we consider when we make buy versus build decisions?

Beyond figuring out the problem you’re trying to solve, start asking yourself some pretty critical questions. Is what you’re considering building part of your core IP? Is it going to uniquely differentiate your product and advance the value? Or is it something that is very easy for somebody else to pick up and integrate (your competition, for example)?

Then you have to start thinking about whether you want to spend time building it. Do you understand the problem domain enough to actually be able to pursue a build strategy? Or is this completely out of your wheel house? If you don’t have the expertise for this particular capability, consider partnering with an expert vendor to get help.

The final consideration, and this is sometimes a critical event, is how quickly do you need to have this capability? Do you have time to invest in research and development and go through the learning curve to build on your own? Or is your need much more immediate? If so, it makes more sense to buy something and have access almost immediately for faster implementation.

What are the most common mistakes that you’ve seen made in both the build and buy scenarios?

When it comes to building, oftentimes what we see go wrong are the very considerations we talked about in terms of the long-term risks and hidden costs. For example, one of these costs is that when you are building in-house, all the support, maintenance, enhancements, scale, and upgrade responsibility for the application falls on your internal team. If the application becomes successful and starts to scale up, that will lead to more demands for features and capabilities⁠—which could create a development backlog and technical debt.

One of the most overlooked consequences (and another hidden cost) is tying up the application team by building something homegrown when it is also very easily available in the marketplace. In this case, you’re not letting the team actually invest in and create more value for the core IP of the company.

When it comes to buying, the biggest problem that companies typically find themselves in is when they have not adequately mapped or vetted their requirements to the vendor’s capabilities. They have a set of requirements, and they want to buy something to satisfy those requirements, but they don’t go through a proper evaluation process.

When this happens, some customers realize further down the lifecycle of the product that they have a need for embedded analytics, for example, to mimic the look and feel of their native application. But they’ve selected a vendor that doesn’t allow any theming or customization, and now the application has a poor UI experience or there are serious shortcomings. All these things can slow down adoption or increase cost.

I would wrap it up by saying that overall, when it comes to simple requirements, it is probably more efficient and cost effective to build. But if the requirements are more sophisticated and you can foresee that as the business grows, you’ll be faced with having to deliver on even more complex requirements, then a buy decision might make more sense (especially if there is a solution already available in the marketplace).

Originally published May 14, 2020

About the Author

Yen Dinh is a content marketing coordinator at Logi Analytics. She has more than five years of experience writing content and is passionate about helping audiences stay updated on emerging technologies.

Subscribe to the latest articles, videos, and webinars from Logi.