A Product Manager’s Dilemma: Buy vs. Build
The Clash
Darling, you got to let me know
Should I stay or should I go?
If you say that you are mine
I’ll be here ’til the end of time
So you got to let me know
Should I stay or should I go?
The Clash had this dilemma that still stays unresolved until this day 🙁. Luckily as Product Managers, our dilemma is less emotional and more rational. We often find ourselves thinking about whether we should use third-party services to have additional functionalities on our product or should we build these internally ourselves.
Should I buy or should I build?
I am confident that unlike The Clash, we as PMs can resolve our dilemma. I will use my least favorite phrase to answer this. It depends :) (feels good to be the one who says it this time). There is no single answer to this, but there are questions that you can ask in order to come up with your own decision for your products or services.
Below is a list of considerations that I think can help us make better and more informed decisions:
Buy
Quick Added Functionality: Integrating a 3rd party tool/service to your software can enable your team to add complex features to your product quickly.
Low Effort & Faster Development: It reduces development cycle time and cost. Your engineers can help you set a target for the desired speed improvement as well. If buying this tool means that the speed of development is beyond the target then it may be a good idea to buy it.
One size does not fit all: Every product is unique and off the shelf 3rd party tools often cannot meet with all your needs. They are generally tailored to address the common needs of many products and services in order to serve a large group of people. Make sure you read their documentation clearly and understand what they can and cannot do for your specialized needs. Another issue to be mindful about is that sometimes they may say they can provide the functionality you need but “can” may mean that they can build it for you with additional cost and time.
Unexpected Fees: You should clearly understand the payment structure and licensing fees. Some companies have monthly subscriptions, while some companies charge you based on how much data required or how many users you expect to have. Let’s say you decided to go with #of users approach, what if you have a higher demand than you expected? Moreover, what will happen if/when your company decides to grow its user base? You may end up paying a lot of additional fees. The same goes for the data usage approach.
Cannot have full control or access: Since you will not have access to their source code, you won’t be able to customize it or access it immediately if anything goes wrong. If you discover a bug, you will have to submit the issue on their website and then wait for it to be resolved. What if they cannot fix the issue before their next release but you have to launch your product before that? Ouch…When you use an external service you introduce additional risk for your product.
Dependencies: If you have so many integrations in your product then your product will have to rely on all these third party solutions which create dependencies. This is tough, especially if you are used to being an independent person! 😜
Reliability and Risk: What if some of the companies you used go out of business? You should make sure you are using a service/product from a reliable company that you think will be around for a while.
Build
Skillset: Do you have the required skillset in-house? Are your engineers familiar and experienced with the technologies and tools needed to build this tool/service?
Budget: Does your company have a budget to build this tool/service?
May not add value to your core business: Before deciding to build any tool, you should ask whether this will bring additional value to your core business or not? Can the resources that will be used to build this tool be better utilized somewhere else? Your engineers should focus on building differentiated components that will help you to achieve your product vision. Just because your engineers can build this tool/service it does not mean that they should. It is your role as a Product Manager to keep your team’s focus on what is important and what is not.
Hard to estimate the time and effort accurately: Building an internal tool will be like building another product where you will need to follow the entire software development cycle and it takes time. Does your team have time for this?
One time Use: Is it a single use case or can it be used across different products and platforms? If there are other existing or future products in your roadmap that can use the tool, then it may make sense to build it. Implementing it would speed up the release of multiple products for you.
Maintenance: The story does not end when you build it. After building it you need to still assign engineers to maintain and update it regularly. So, you need to consider your maintenance resources as well before deciding that it is a good idea to build it internally.
Final Thoughts
Build vs buy decision is one of the many Product Management tradeoffs that you will have to navigate throughout your PM career. It is the tip of the iceberg. iOS vs Android, Angular vs React, Native vs Hybrid, shipping now vs shipping perfect, increasing technology debt vs speed, and many more decisions are waiting for you!
But for now.. you got to let me know should I buy or should I build?🎵🎶🎤
