Jun 7, 2023

Build vs Try: A new approach to build vs buy that accelerates GTM iteration

Ki Moon

In this guide, learn how the traditional approach to build vs buy is incomplete and how build vs try can help you accelerate GTM iteration.

How Build vs Buy typically works

Build vs Buy is a classic framing in B2B software. Typically, it starts with looking for any low-hanging constraints that simplify the decision, like:

Is the tool a core competitive differentiator that you need complete control over?
Are there proprietary or regulatory factors that restrict data exposure externally?
Do you need a more robust solution than your current internal resources can build?

If yes to any of the above, the answer is straight-forward. But we rarely have the luxury of black or white choices - we live in a world of grays, constantly juggling complex and dynamic factors with imperfect information that may become obsolete tomorrow.

In the case of Build vs Buy, that calculus typically centers around capacity assessment, future considerations, and opportunity costs, such as:

Team resources: Do you have the cross-functional resources and expertise to build and manage the solution? If not, is filling that gap the best next hire for the org? Are there more impactful strategic projects they could be doing instead?
Strategic direction: Is the solution intended to solve for a point in time or low-level operational need? Is it an ongoing strategic priority that will require dedicated resources to align with evolving scale, scope, functionality, and needs?
Cost-benefit analysis: What are the cost components and the expected impact of the tool? How do you account for the opportunity cost of time to pipeline and revenue? What is the time horizon over which to aggregate both sides of the ledger?

This is a well-trodden approach that checks all the boxes of a Build vs Buy evaluation. If you want a full run through of the typical "Build vs Buy" evaluation, you can reference our guide on build vs buy for product-led sales tooling. However, we think the classic evaluation process is broken, so keep reading to see why Build vs Buy should actually be Build vs.Try.

Build vs Buy misses the bigger picture

While this approach isn’t necessarily wrong, it should be reconsidered, because at its core are two outdated assumptions.

Assumption #1: Build vs Buy is permanent

Historically software has been expensive to configure, hard to adopt, and even harder to replace, so buyers have taken the approach of having to get the decision 100% right.

But ask yourself, what % of the tools you had 2 or 3 years ago are you still using today? And how many times has your business changed in a way that forced a change to your tooling? Some tools have stuck around (looking at you Salesforce), but I bet change happens more often than we realize.

Buyers tend to over-index on the sunk-cost fallacy - in reality Build vs Buy decisions are often more multi-directional than they are one-way.

Assumption #2: Cost-benefit analysis is the bottom line

Cost-benefit analysis is an effective tool for simplifying complex questions into a well-understood framework - it normalizes dissimilar factors into a single quantifiable dimension that enables comparison and supports a straightforward conclusion.

However, cost-benefit analysis is based on what is known or assumed at a point in time. The reality for buyers is go-to-market strategies evolve, products change, and your business’ economics are fluid inputs that are unlikely to hold true for 3 months, much less a year.

This means that while cost-benefit analysis is worthwhile, it limits what’s controllable, what can change, and consequently, the scope of potential outcomes that is the basis of the analysis itself.

Indexing on these two assumptions can lead to a counterproductive dynamic once the decision is made - a shift in focus to how “correct” the Build vs Buy decision was. You assess how well you are executing against the parameters of the decision framework, and how accurate those parameters were in predicting the future. But in doing so, you miss the forest for the trees.

Technology is a catalyst for better decision making

Stepping back from the pull of today’s fire-drill or the frantic EOQ push, it’s easy to forget that how well you make decisions is the primary determinant of the company’s success and the not-so-secret sauce of how the best companies grow.

Companies continually face decisions as they build and scale their organization that deploy far more resources than any single Build vs Buy decision. These decisions can typically be framed in terms of hypotheses, the results of which inform the next course of action.

To illustrate, let’s look at a few examples:

Revenue hypotheses

We need to generate XX% of revenue from expansion in order to hit our target
A human-driven sales is economically scalable when deal sizes are >$XXk
There is $XXm of attainable revenue opportunity within our existing free user base
Human in the loop will help me drive the maximum revenue penetration within an account

Revenue decisions

Double-down by hiring more reps to maximize throughput of your asymmetric funnel
Apply a product led sales motion for expansion in the MM segment
Build a sales assist team to increase conversion earlier in product journey
Update your revenue attainment assumptions and reallocate resources to other growth initiatives

Making better decisions over time is mainly driven by the fidelity and speed of information that is incorporated against a set of working hypotheses, and as the business evolves, the context of information and hypotheses requires constant updating.

PRO TIP 💡

Ultimately, the speed at which you can get evidence for decision-making will make or break hitting goals and succeeding as a business. We should view the output of Build vs Buy with a similar lens; what decisions and learnings can it provide outside just the tool itself?

The goal is to make high velocity, high quality business decisions

So let’s look at a Build vs Buy through this new lens - where neither path is permanent and subsequent decisions are prioritized and contextualized by company progress. In this context, opportunity costs are more appropriately valued and the most important dimension becomes how quickly are you getting high fidelity information to lead you to the best next decision.

The truth is, building a product (especially not your core IP) takes time. And that time pushes out tactical programs like QA/QC, pilots, enablement that lead to the necessary learnings to inform the next progressive decision you have to make.

Buying a solution shortcuts this process, and allows your GTM teams to get their hands on solutions faster, leading to shorter cycle times between new learnings and strategic decision making.

It’s actually build vs try

Unless you know exactly what you are building and are confident you can nail it, buying is the better option because you are going to be learning faster, at lower risk, and at lower cost, and will be in a better position to make the next decision.

And if you decide to build after buying, you will be able to do much faster and more effectively than starting from scratch because you’ve already navigated the challenges and empirically know what good (and bad) looks like.

We look at this as a ‘Try’, where you get the best of both worlds – the ability to partner with people dedicated to solving a narrow problem for your business so you can learn exactly what you need or go off to the races with the ideal vendor.