Buying BI

3 Build vs. Buy Software Considerations for Product Managers: Tips from The Clever PM

By Cliff Gilley
Share on LinkedIn Tweet about this on Twitter Share on Facebook

This post was written by Cliff Gilley, Product Management Specialist and Founder of The Clever PM 

One of the bigger challenges that Product Managers often face in their daily work of identifying  innovation opportunities and satisfying customers with their products is the decision whether to build a new feature, whether to buy an existing tool that provides such a feature, or whether to partner with a third party to help their clients and customers be successful. 

>> Build vs. Buy: Calculating the ROI for Embedding Analytics in Your Application <<

There’s a lot that goes into software build vs. buy decisions—everything from fighting internal “not built here” biases against third-party solutions to negotiating favorable economic relationships with those third parties so that they both benefit from the work. In general, though, we can usually boil these issues down to three key software build vs. buy considerations—(1) whether the function fits in your company’s core or distinctive competence; (2) whether the space that the function is trying to fit is a known and solved space; and (3) whether this is a one-time effort, or an ongoing project with unclear end points. When we look at these three considerations, we can determine what solution makes the most sense for your business model.

3 Software Build vs. Buy Considerations and Solutions

BUILD When It’s In Your Core Competence

Every company should know what its core or distinctive competence is. This is the thing that makes your company and your product differ significantly from the competition, and something that cannot be easily replicated. When a feature or function falls into this area, it’s imperative that you do the work yourself. If you’re a messaging system, and you’re considering some component that ties into that core system—adding emoji to your base product, for example—then you need to own that space.

But all too often, features and functionality that are being asked for by your customers and clients, or by your sales and marketing teams, really don’t fit into that core competency. Adding web-based user profiles to your messaging app, for example—it’s a given that your talented development staff can solve this problem, but is it worth the investment in something that isn’t core to your product?  Probably not, so then you need to look at whether to buy the software or partner.

BUY When It’s a Known, Solved Space

When we’re looking at buying another solution and integrating it into our own, we primarily want to ensure that there’s not a huge amount of technical debt that we’re taking on by choosing that particular product. Thus, the “buy” solution is more often applicable when you’re looking at a space that’s been solved before.

Nobody builds a SQL database from scratch; you buy MS-SQL or MySQL. Those are known, solved spaces—and they’re well-established enough that the likelihood of maintenance being a significant drain on your ongoing efforts is small.

It gets a little trickier as the space becomes more nascent and not clearly “solved.” For example, many blogging platforms have written their own text editors because the out-of-the-box solutions didn’t cut it. But that’s squarely within their competencies, isn’t it—they’re not writing their own web servers or email platforms. Buy when there’s something fairly solid, relatively stable, and the domain is outside your competence—you’ll save so much time and be able to invest so much more in your own innovations.

PARTNER When It’s a Not a One-And-Done

The third option is often the most overlooked—finding a solutions partner to assist you in creating the feature or functionality that you want. There are several situations in which this path makes the most sense, but they all have something in common: they’re ongoing or multiple-instance engagements.

If you have a feature that you want, but it’s both outside your core competence and not a solved space, you seek someone with that knowledge and competence—but they’re not going to just drop something in your lap, it’s going to take time and iteration. They become a partner. When you have a feature or functionality that can be achieved through training or consulting services, you find someone who can sit on-site with your clients—but they’re not likely to just drop in and out, it’s going to be a relationship.  

This is when and why you partner. It’s far cheaper in the long run to leverage someone else’s knowledge and skill than it is to train your own resources up. And, if you play it right, the partnership path often leads toward acquisition or closer relations with the partner.

These are, of course, general guidelines. There are good reasons to create a partnership in a known and solved space, and there can sometimes be significant economic pressures that force us to build something that’s reinventing a wheel. But overall, if you look at these efforts through this lens, you’ll start down the best path to solving for your customers—even if you wind up at a different destination in the end.

Bringing It All Together: Deciding Whether to Build or Buy Software

It can always be helpful to see what options you have when deciding whether to build a new feature, buy an existing tool that provides the feature, or partner with a third party. To help you decide how to proceed, we’ve put together a free ebook on evaluating factors to guide your Build vs. Buy decision. In addition, it may be worthwhile to investigate what a “buy” tool looks like – see a demo of our product here!

Originally published February 16, 2017; updated on May 21st, 2021

About the Author

Cliff Gilley is a Product Management Specialist and Founder of He has worked as a product manager for over 10 years in a variety of markets and on a variety of products.