Deciding whether to build or buy (i.e. partner for) functionality is a key question you have to answer on an on-going basis as you develop product roadmaps. This is definitely one of the grayest areas of product strategy, and this article is an attempt to highlight some of the most important considerations.
A few definitions before jumping into details. In general, there are three types of partnerships that you might want to think about:
- Embedded components: this refers to partner functionality that is buried in your products and is not visible to end customers. Example: the comment spam filter in wordpress.com is based on such an embedded component. Google Analytics is another embedded component in wordpress.com.
- Bundled products: this refers to partner functionality that is delivered as an add-on to your products. Example: WordPress themes are delivered this way. Many features of LinkedIn, such as its integration to twitter, Facebook and WordPress are good examples as well.
- Go-to-market partnerships: this refers to channel partners that push your product. Example: you might use a Systems Integrator like Deloitte Consulting to drive solutions based on your offerings.
The focus of this article is to answer when you might want to partner for embedded functionality (#1 above) or bundled products (#2 above). The key questions that will help you get to an answer include:
1) What portion of the value delivered by your product is attributable to the candidate functionality?
2) Is the functionality critical to the way you compete?
3) Are there established players for this functionality with a track record of partnering?
4) Will partnering significantly impact cost of goods?
5) Will the answers to these questions change over time?
These are discussed in what follows.
Value add of candidate functionality
If the value added by the functionality being considered relative to the value of your solution is small, you might want to consider partnering for it. For example, the main value of WordPress.com is the ease with which non-technical users can create and publish web content. Given this, features such comment spam filtering are important but not central to the value of wordpress.com. Put another way, authors might choose to disable comments altogether if they think comment spams are a big headache for them. So, it does make sense to partner for this functionality.
Is the functionality critical to how you compete?
If the functionality is critical to why customers buy products in your category, you should consider building it. For example, Netflix’s ability to recommend movies based on your consumption is one of its main differentiators compared to a free video streaming site, which is probably why Netflix builds this functionality. To be sure, the dimensions of differentiation keep changing. For example, Youtube now recommends videos as well. As a result, functionality that was a differentiator at one point in a product’s lifecycle might not remain so, which should then force a re-evaluation of your build versus buy decision.
Is the functionality available from established players?
If the functionality is available from established players, it might make sense to partner with them. This is particularly true for functionality that is hard to duplicate because of proprietary technology, “hard science”, patents or other factors. For example, content search is a difficult technology problem but has established players like Google as well as Open Source solutions, so you would rather not build it if your product needs a search capability.
The converse is also true- if the functionality is not available, you have to invent it.
Impact on cost of goods
If the functionality adds significant costs to your product, you may want to consider building it in-house. If it is not possible to build it, you should consider partnering for the functionality but offer it as a separately priced add-on. For example, for some of my products, reporting/analytics is a critical value add. However, reporting is an established category with many leading players, however, with rather expensive software. So, for this functionality, I have had some basic reporting as part of the product, but have partnered with a reporting vendor to provide a separately-priced add-on to provide advanced functionality.
Impact of time
If any of these answers is expected to change over time, you should factor that into your build vs buy analysis. This might perhaps lead you to partner initially but plan to build (or acquire) the functionality over time or vice-versa.
As this article shows, multiple factors are involved in driving the build vs buy decision and the analysis may not always result in a clear-cut answer. Hopefully, the article helps you frame the issues involved.
