Product managers, during the course of creating a product, are often stuck between the proverbial “rock” and it’s neighbor, “a hard place.”
That’s usually as a result of the fact that when a product fails to generate the users or revenue that are expected of it upon its release, the product manager tends to be the one with their head on the metaphorical guillotine. After all, developers, marketers, and designers do their very best with the product they were tasked to work on. If the product fails, that’s on the product manager, for better or for worse.
So, when it comes time to plan your product roadmap, and you find yourself with the age-old question of “Build Vs Buy?”, there are many considerations to keep in mind. Let’s take some time to go over all of the reasons why you should or should not build the functionality that your product needs to succeed.
Does It Define Your Product?
We know you have a talented team of engineers. You hired them for their impressive skill sets, and it’s not a question of whether they have the ability to properly build the functionality your product requires; it’s a question of “is it worth it?”
Unless the particular functionality that you build is what will garner you revenue, it’s probably always a better idea to seek out an existing solution to that problem. This is usually true for the following reasons.
Building software is expensive. The scope of your project will no doubt grow as you begin to work, as will the length of your time to market, leaving you in a position of releasing half-baked features, or functionality riddled with bugs and technical debt. If you truly believe your team can release a product that solves an industry problem better than solutions that have already been released, it may be worth it, but watch out for unexpected problems that may arise.
If you need a commonly-tackled solution, such as email, CRM, or file storage, you are not going to be able to compete with the major players in that sector. Building an equivalent product to Salesforce or Google is incredibly unlikely, and doing it in a cost-effective way is nigh-impossible.
This can lead to one of the largest “product killers.” Being overtaken by another organization. If you aren’t working on a product with an incredibly unique use case, then a larger well-funded company may very well release a product that jeopardizes your own. If your business model depends on the success of that feature-set, you may wind up having sunk a considerable amount of money into development that is now useless.
At the end of the day, building yourself will be more expensive, more technically complex, less secure, and most importantly, harder to maintain. Once it’s all said and done, if you build your functionality in-house, you are now responsible for keeping that code operating smoothly, even as you hopefully scale up.
So, does that mean you should never build?
Of course not. Technically, everything is “built” somewhere, and there are a handful of reasons why building in-house is a great way to go. Let’s cover some of those reasons.
When to Build?
There are obviously some cases where it makes sense to build what your application requires. For instance, if your app requires a product that doesn’t exist, then it’s obviously time to build it. You can always look for products that offer partial solutions, but even in that case, you’re probably going to be left with having to build a considerable amount of the functionality your product requires. Take something like ELSA, for example. Speech recognition is by no means something you have to build yourself to take advantage of, as trained models for machine learning are easily available. But, to get the desired functionality of recognizing American speech patterns out of it, a good bit of extra training, fitting and testing had to be done on the side of ELSA’s engineering team.
This also applies to applications with rare or unique intellectual properties. If you’re getting ready to start building an application to predict the outcomes of baseball games for betting purposes, you’re probably going to have to come up with that algorithm yourself. However, you can easily supplement that functionality with data from pre-built APIs and payment processing services like Stripe.
When you choose to build, make sure that you still buy when you can to lessen the load on your engineering team. You don’t have to paint the whole picture from scratch. You should just be filling in the blank spots on the canvas.
Bang for Your Buck
Not all “buys” are created equal. There are some occasions where you can stretch your money the furthest and bring in a considerable amount of functionality in one fell swoop. Unified APIs are a great example of this. If your application requires many different services along a single category, such as file storage or CRM providers, connecting with a single Unified API will provide you with unrivaled functionality in one quick connection.
Let’s say your application needs to allow the syncing of files and folders across different cloud storage providers. In the same amount of code it would take to connect to a single cloud storage API, a Unified API can provide you with dozens of different services, giving your users the ability to choose whatever service they are already comfortable with and have their workflows set up in. Adding on to that, a Unified API handles all maintenance and upkeep of these connections, so anytime an API response or endpoint changes, your application’s connections stay sound.
When it comes time to choose between building and buying for your product, make sure you take the time to research all of the available solutions at your disposal. The most important thing will always be deploying your product on time, so try your best to seek out viable resolutions to your problems.