Concept 3 of 4

Buy, build or partner

3 questions test this

A market problem rarely gets solved by one component. The framework's Buy, Build or Partner box asks a specific question, which is how to complete the solution where the current offering has gaps, and it treats building as one option among three rather than the default.

The three options and what each costs

Build. Full control of the roadmap, the data and the experience. Slowest, and the cost does not stop at delivery. Every component built is a component maintained, documented, supported and migrated for as long as the product lives.

Buy. Acquire the capability, whether that is a company, a product, a licence or a data set. Fastest route to a capability that already exists elsewhere. Costs capital and integration effort, and the integration is usually underestimated by a wide margin.

Partner. Someone else's capability, reached through an agreement. Low upfront cost and fast to arrange. In exchange the partner's priorities, pricing and viability become yours, and unwinding it later costs more each year.

The test that decides

The question is not what is cheapest today. It is whether the gap sits on the distinctive competency.

If the component is the thing customers cannot get elsewhere, build it. Handing that to a partner gives away the reason the product wins.

If the component is necessary but undifferentiated, buying or partnering is usually correct. Every week spent building a commodity is a week not spent on the part nobody else can build.

If the component is differentiating but the company has no route to building it in a useful timeframe, buying is what the option exists for.

Questions worth asking before committing

How long until the capability is in customers' hands under each option.

What the total cost of ownership looks like over three years rather than the first year.

What happens if the partner is acquired, changes their pricing, or closes.

Whether the option can be reversed, and what it would cost to reverse it after a hundred customers depend on it.

Whether the buyer would notice or care that this part came from somewhere else.

Revisiting the decision

The right answer changes as a market matures. Capabilities that were differentiating become commodity, at which point a built component is a maintenance burden and switching to a bought one releases the team. Partnerships made when a capability was scarce become expensive once three vendors offer it. The box is reviewed on the same cycle as the competitive landscape, not once at the start.

Common misconceptions

If it is core to the product, build it.

Core is the right test and it is narrower than it sounds. Core means the part that carries the distinctive competency. Everything else, including things that feel technically central, is a candidate for buying or partnering.

Partnering is the low risk option.

It moves the risk rather than removing it. A partner's roadmap, pricing and continued existence are now inputs to your product, and the exit cost grows quietly with every customer onboarded.

Building is cheaper because the engineers are already paid for.

That reasoning ignores opportunity cost and total cost of ownership. The engineers building a commodity component are not building the part only this company can build, and the component needs maintaining for as long as it exists.

3 questions test this concept

A company needs a document signing capability to complete its solution. Three vendors offer it, none of the company's customers ask who provides it, and it is not related to the company's distinctive competency. What does the framework suggest?

  • ABuild it, since owning the whole stack gives full control.
  • BBuild it, because the engineers are already employed so it costs nothing extra.
  • CLeave the gap, since customers have not complained about it.
  • DBuy or partner, since the component is necessary and undifferentiated, and every week spent building a commodity is a week not spent on the part nobody else can build.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
Playing to Win, On which capabilities must be owned to win where you have chosen to play.
Book
The Innovator's Dilemma, On what happens when a capability commoditises.
Book
Build: An Unorthodox Guide to Making Things Worth Making, On deciding what a team should actually make itself.