Create, deploy, and maintain analytic applications that engage users and drive revenue. See a Logi demo

Buying BI

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

By Cliff Gilley | February 16, 2017

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 these 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 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 come to the following conclusions:

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 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.


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.

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