Good Product Teams Should Buy More!

Editor’s note: The following is a guest post written by Toucan Toco. If you would like to contribute to the blog, please review the Product Blog contribution guidelines and contact [email protected]

2 years ago, we accelerated our investments to help SaaS companies integrate Dashboarding into their product rather than developing it from scratch. So we become a third party provider for tech and product teams. It was only then that I realized, as a CPO, I’d always elected “build” in the build vs buy debate. Not even a debate, I just defaulted to build without even stopping 1 second on the buy opportunity. Let’s just stop there and make sure everybody is on board: Build vs buy? What do you mean by that? 

Well, as a SaaS provider, when you’ve prioritized a specific user pain and identified the solution you can offer, you essentially have 2 choices :

●  build the feature yourself through (many) development iterations

●  find someone who has already built the solution and can give (open source) or lease it to you → that’s what l’ll call “buy” here (we’ll see that open source is not exactly free)

After 2 years and hundreds of discussions with my peers at other tech companies, I can say that the majority of CPOs and tech teams share the same experience. Yet we’re not even proactive about it. Build just happens to be our default mode, no matter how unjustified. 

There are exceptions, of course! And a number of them have become our clients such as PA from Libeo, Xavier from Pricing Hub, Arnaud from Onbrane, or were already using third party analytics solutions (Jobteaser, Mano a Mano, WTTJ, …).

Of course building our own OEM (Original Equipment Manufacturer) offer was an easy eye-opener for me but, I hope, that this article and a series of others helps you challenge the unconscious default to building.

Let’s suppose, just for a minute, that building products from scratch is usually the wrong decision. You’re not convinced yet, I get it! 

Consider what it would mean to buy this thing? Does it even exist in the market? How much do you think it would cost? How extensively would it meet your needs? And your future needs? 

If I can convince you to try this exercise at least once in the coming weeks I will have reached my goal! Particularly if you do it when considering the development of your users’ dashboarding 😉.

In this article I want to recap the classic Build vs Buy arguments. Later articles will touch upon each of them more in detail. 

Let’s start with…

nervous Robert Hays GIF

Very good reasons to build your own product/feature!

Well… this chapter will be brief… just kidding! 😜

There are certainly very good reasons to build things in-house – it’s all about context. 

An off-the-shelf product doesn’t exist to solve your problem

Ok, so it’s 1983 and you’ve just started building this amazing product. Let’s imagine that you need  version control – It makes total sense to build your own before even starting the project, right ? I mean there is nothing available on the market, and you won’t get far without one.

Fast-forward to today, and think who in their right mind would build their own version control system? We just default to github or the OGs go with gitlab. And you would, in all likelihood, argue with me that’s actually a SMART decision. Because why reinvent the wheel

Plus this is a commodity right? I mean the way I use version control and the way you do are probably not all that different, if at all. I wouldn’t  get any further ahead of my competition were I to develop my own version control solution.

What you intend to build is rare or unique

We can use Toucan as an example in this case. 

When we launched in 2016, there were already other data visualization solutions and frameworks out there. But our goal was to build the next generation data visualization solution, and we simply couldn’t build that on top of any pre-existing platforms. 

That’s why, even now (with my eyes wide open on the buy alternative!), I still think it’s a good choice to not have to turn to highchart, vega or other frameworks, but instead towards rather low level d3. JS or raw JavaScript and HTML.

Most of the time, however, what we’re aiming to build is neither rare nor unique. If you’re not a data visualization solution, chances are what you want to build is a commodity and a solution exists out there (and maybe closer than you think… just saying). For example, when we added a search feature in our documentation we turned to Algolia (quick shout out: their customer support is amazing!).

So there you have it folks! Unless an off-the-shelf product doesn’t exist to solve your problem, or what you intend to build is rare / completely unique you should seriously consider the  “buy” alternative.

We’ll be diving more into the “why” in a follow-up article that you can check out on the Toucan blog

Until then!

Meet The Author: Charles Miglietti

Charles Miglietti

I love when things are easy to understand, and I always appreciate people who explain things well. That’s why I started Toucan – to tell stories and help organizations make their data more meaningful and understandable. We empower people, both technical and non-technical, to make better decisions throughout the day with the data they already have. We work with product teams to integrate reporting and analytics functionality for fast, flexible decision-making without the massive time and development resources that are otherwise necessary. 

Data driven product manager banner

Enjoyed the article? You may like this too: