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

Product Management

To Build or Not to Build? How to Create Great Products and Avoid Overengineering

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

The two most common development approaches for embedding analytics are to build a solution with the help of UI component libraries or buy a solution from an analytics vendor. Application teams are often tempted to take the first approach because they can build exactly what they want using low-cost (or even free) component libraries. One reason for this code-intensive approach is to maintain complete control over the product. But this control often comes at a cost that can significantly impact the time to market, ability to scale, and overall software maintenance.

So, as you look at your product roadmap, how do you know which features and functionality to build or buy? Mark Ridley, owner and founder of Ridley Industries, recently tackled this subject in a Product Management Today webinar.

Let’s start with the big question: Build or buy?

Mark Ridley: Whether we’re on the product side or on the engineering side, there is a lure to building products, to creating something new. I think it’s a very human urge to feel we’re creating something which is unique to us. And certainly, it’s something I’ve felt. Eighteen years of my life went into creating the Reed website, and I still feel a great deal of paternal ownership of Reed.

Nonetheless, I’m going to start from an assumption or a hypothesis that today, building products from scratch is usually the wrong decision. And this really is true across all the organizations I’ve worked with. Unless you are truly a tech business, then generally the right thing to do is buy technology and products.

What are your biggest reasons not to build?

The first is that building software is really, really expensive. And it’s very rare that I see a company who has actually made the right guesses around how much it’s going to cost. You can almost always assume that however long you think it’s going to take to build your project, it’s going to take longer and cost more.

The second key point is that actually running the product is often the most expensive part of the product lifecycle. Often, as we start looking at how we can validate the product—it’s a great problem to solve, the market is big enough, it’s going to make us lots of profit, etc.—all that we have done to forecast our costs is think about the full build and release. And that’s where our worry stops.

But actually, supporting what you build is often the largest cost through that entire lifecycle. So, either we have to go back and ask for additional spend, or more likely, these products are put into maintenance mode and don’t have the care and support they need.

The third reason, and probably the most interesting for me, is if there is somebody in the market that is providing this across multiple clients, you’re unlikely to be able to compete. With the product that you have created internally, you have your engineering resource, and that’s dedicated to your team. It’s a one-to-one relationship and they’re going to be vying for new products, developments on the roadmap, and obviously the support and ongoing maintenance of the product.

If on the other hand you have a company that suddenly realizes they have a product they can sell to a large number of companies, their engineering resource is actually spread across an entire range of clients. So, tens of thousands of users are all benefiting from the constant evolution of an engineering team. And that engineering team can be resourced against an income stream directly.

Are there any cases where build is actually the better approach?

There are obviously times when it is the right time to build. The key one here is that if you’re in a situation—as I was at the beginning of my tenure with Reed—in which an off-the-shelf product doesn’t exist to solve your problem. If this is a unique problem to you and nobody is actually providing the capability, and you can genuinely say you’re building it because you have to, and not because you want to, then it might be the right thing to put an engineering team on this problem.

Airbnb and Spotify are great examples. In both cases, the underlying technology they required didn’t exist to serve their markets.

Another case, obviously directly addressing one of the reasons not to build, is if you plan on creating a business so that you can serve other businesses. This is the “picks and shovels” model—where in a gold rush you don’t want to be out hunting for gold, you want to be in the market of selling everybody the tools they’re using to mine the gold.

Find out more of Mark Ridley’s thoughts on the build versus buy debate in the full on-demand webinar, sponsored by Logi Analytics and Project Management Today >

Originally published March 17, 2020; updated on March 22nd, 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.