Skip to main content

"Buy, partner, build" - an order matters


Have you ever got into a "build trap"? I certainly have. "Build trap" is the answer "let's build it" to any question asked. It's so easy, isn't it? After all, we are in product development so why can't we build stuff all the time?

Build

Remember product managers? Those guys, by their job description, are responsible for the overall product success. And consequently for their company success. A lot of aspiring PMs, myself included in my days, understand this ambitious goal as building the best product. "Build" being the key word. Scrum facilitates this thinking as Product Owner role assumes product needs to be build! Otherwise, Scrum team is not needed. So as PO. Sometimes this approach results in longer time to market, longer time to value and revenue. Company success delays or in danger of not realizing. What is the alternative?

Buy, Partner

Product managers after completing some "classic" PM course, like "Pragmatic Marketing," know the alternative to "build." "Buy," "Partner" are equal alternatives to "Build." Instead of building a feature you buy it from the market. When you can't buy or when you see more possible synergies you can partner with those who have this feature. Instead of building you're integrating.

Imagine you build a task management software. Users need to authenticate (register, login) to use it. You can solve the authentication problem by either building the service yourself or buying/partnering with a solution already existent on the market. Another example: email sending. If your product needs to send emails do you really want to build this feature yourself or better use, for example, MailChimp who nailed it?

How do you choose between Buy, Partner or Build?


Main rule

The main rule is simple: build your core differentiators. For the rest - buy or partner.

What does it mean?

You should build your core functionality. The key job users need to do with the help of your product. For additional capabilities, you should seek buying or partnering options.

Coming back to the example above. If your product is a task management tool make sure you build the best possible task manager. For the authentication and sending emails don't waste your time and buy or partner with somebody.

Meta-products

Does all this mean your product might be just a combination of other products with a bit of original code? Yes, and it's not a bad thing. Your customers need to solve their problem. Get a job done. They don't care how you or anyone else would do it.
Best products don't always win. That's an unfortunate truth. For some though it's quite fortunate, because even if you can't create the best product you still have chances for success. Not having resources is no longer an excuse. You can't afford best network engineers, but you can buy AWS. You don't have the time or skills to build performing eCommerce system, but you can buy Shopify and start selling. Time to market is one of the most important criteria of success. In a lot of cases, you can be faster to market choosing to buy or partner to building non-core features of your product.

Popular posts from this blog

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior?
BJ Fogg, from Stanford University, has created simple and powerful behavioral model for persuasive product design.


Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions. But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

2017: Less of How, more of What, and a little bit of Why

Focusing less on how (methodologies, frameworks, processes). For me, that was the most important product management trend in 2017. Surely, "Agile" talks are bottomless. Yet, I noticed a certain tiredness and dare I say, boredom among product community with regards to this topic.
- Maybe that's enough? Haven't we discussed that like thousand times? Shouldn't we all have that figured by now?