Build vs. Buy?
The Ultimate Product Manager Decision
Each and every week, I make at least one build vs. buy decision for the digital products I manage.
Here’s a recent sample:
· Should we build our own onboarding for our social products or use an onboarding as a service provider?
· Do we want to manage our own iOS app notifications or use a provider to manage them for us?
· Could we use a partner to simplify our in-product marketing message delivery or do we need to construct marketing modals and messages ourselves?
Since the beginning of the modern service economy, businesses and consumers have had to decide:
Do I want to pay for this service or can I do it myself?
As a product manager with limited development resources, you surely face the same daily/weekly/monthly dilemma.
Add the other variables to consider of maintainability, scalability, user-friendliness, cost, customization, stability and you’ve quickly given yourself a migraine.
Build vs. Buy: 10 Factors You Should Consider
1. Is this project related to my team’s or my business’s focus?
2. How long would this take to Build? How long to Buy and integrate?
3. How much time do I have to launch this product?
4. What timing and knowledge uncertainties are there with each path?
5. What is the user-facing quality difference between Build and Buy?
6. What vendors sell a solution to the problem?
7. Are vendors dependable or small startups likely to shut down?
8. How much does it cost to Buy vs. Build? (Don’t forget to value your developer’s time!)
9. Does the solution match your business type? (Solutions that are right for an enterprise probably aren’t right for your startup.)
10. What’s the risk that a bought solution breaks in the future or a built solution needs to re-built?
When Should I Almost Always Buy?
Non-Core Competence:
If you’re in the business of Social Analytics as a Service, don’t waste time building out a Customer Management System when there are easy and affordable options like Intercom available.
Uncertain Technical Challenges:
If your team doesn’t have any idea how they would solve the problem, don’t make them spend days or weeks trying to figure it out. Bite the bullet, invest in your future and invest in the solution that someone else has already discovered.
Feature Doesn’t Deliver Highly Visible Value to Your Users:
For problems generally not visible to your users (ex. Server errors, Click Tracking, Purchase Analytics), you’re usually better off going with a purchased solution than building your own. Save yourself time, headaches, and (surprisingly) money by integrating NewRelic instead of combing through your server logs every night when something goes wrong.
Rapid Prototyping/MVPs:
If you’re trying to validate or test a hypothesis in the market, buying (or even better, trialing) a few key products could shorten your time to answers by weeks, if not months.
Thanks for reading! If you’re enjoying this post, I know you would enjoy my 2 brand new courses on Product Management.
Whether you’re an aspiring Product Manager or looking to level up, I know you’ll learn a LOT from the >50 hours of course content I’ve assembled.
I’m also offering a very limited time discount to my Medium readers.
(use promo code: 25PCTOFFMPM)
If you prefer books, I think you’d also enjoy Disrupting Yourself (how to succeed in the new economy) or Building Digital Products.
- Disrupting Yourself Special Offer
- Building Digital Products (New 2nd Edition!)
When Should I Almost Always Build?
Core Product Features:
Don’t ever purchase a product as a core product feature (or be extremely careful if you do). Even if that product strengthens yours in the short-term, it will be more difficult to maintain, harder to update/remove, and much more expensive in the long term than building it yourself today. Lightweight and well-maintained APIs are an exception, however, especially for complex product features like payments and email.
Control and/or Customization Are Vital:
If design, function, and flexibility are incredibly important in solving a problem, don’t fool around with trying to intensely modify a bought solution into your product. Chances are, even if you can get their solution to meet your strict guidelines, it won’t stay that way for long and one update by your provider will force you to rewrite all of your CSS.
How Do I Know When Buying was a Fail?
So you bought a solution and you’re already regretting it. How do you know if you’re just experiencing buyer’s remorse or if it’s time to cancel the contract and get building?
Here are some signs of Buyer Fail:
1. Your developers have spent over 3 days working on CSS styling
2. Every day, you think of 5 new ways that the bought solution could be improved. Yes I know, as a Product Manager, this is almost impossible not to do, but you get the point!
3. Every month when you pay your subscription bill, you regret it.
How Do I Know When Building was a Fail?
So you started building a solution and you’re regretting it. How do you know if you’re just experiencing growing pains or if it’s time to buy a solution?
Here are some signs of Building Fail:
1. You find yourself saying this every day: “I can’t wait until we get back to …” This means you and your team aren’t working on the most important thing.
2. Your launch plan for the solution doesn’t include user testing or user feedback.
3. More than half of the first week of development work is filled with spikes (discovery) instead of actual development work.
How have you struggled with Build vs. Buy decisions on your teams?
What factor(s) usually tip the scale one way or the other for you?
Share with me on Twitter: @amitch5903
Check out my other blog posts:
Find More by Alex Mitchell:
Blog: https://medium.com/@Amitch5903
Twitter: @amitch5903
Check out Alex’s Book: Building Digital Products
Amazon: https://www.amazon.com/Building-Digital-Products-Ultimate-Handbook/dp/1522824936
Digital Download: https://gum.co/CLccb
