The age-old question every business will face: do we build it or should we buy it? 

Almost every major product evaluation process includes this critical question for good reason — it’s all about time and resource investment versus return.

If we’re talking about critical product features that tie directly to your core value, it’s often a no brainer - build it. 

When it comes to tooling that enables your business to run — like go-to-market tools, HR tools, finance tools, etc.— the answer is less clear. These are critical business functions but are they core to your value as a business? The answer is usually no, buy it. 

In this blog we’ll break down how to evaluate a build vs. buy decision specifically for Product-Led Sales tools (although this can apply to other categories). 

If you are unfamiliar with Product-Led Sales tools, read this blog first about Product-Led Sales platforms and learn how PLS fits into the modern GTM tech stack. 

ps: Don’t feel like reading 2,700 words? Here’s the TL;DR

Buying is usually better than building because the options you have  are fairly limited. Plus, you take away resources from your core product into building and maintaining a tool that just never seems to be as fast and nimble as you need it to be. Here’s why common approaches to building, just don’t cut it:

1. Building a dashboard: It’s great for data visibility, but sales can’t use it to build workflows, action leads.
2. Building an internal tool: The cost of maintenance and the time it takes to iterate on feedback makes it a costly option, unless you’ve got a team dedicated to it.
3. Integrating data warehouse with CRM: CRMs just aren’t built for PLS. Between all the custom name fields and data manipulation it’ll fill like trying to fit a square peg into a round hole. 

Now onto the deep dive!

Just because you can build it, does it mean you should?

If you ask your technical teams and engineers if they can build something, they will almost always say yes.

That conviction to build anything you need is probably why you hired that engineer in the first place. Although, more often than not, engineering resources are the most precious resource within a company, so why would you want them working on something that is not a “core product”?

Based on community conversations, below are some of the reasons why companies are hesitant to buying a tool and an internal build seems preferred (at first): 

• “We cannot easily make product data available to third parties (usually due to some data quality concerns or a lack of a data warehouse).” 
• “We’re not sure how we’ll operationalize this within the GTM team, so we’d rather try and build an MVP internally first to test it out.”
• “All we need is our product data in our CRM, so we just need to build those data pipelines and everything else works well as is…”
• “Buying a tool will be expensive and make us reliant on a third party for the operation of our GTM motions.”
• “We’d prefer making existing tooling better with some customizations - rather than buying a new tool - to avoid retraining our GTM resources on a new solution.”

So instead they build their own.

If we break down these concerns, you see three major categories:

1. Lack of data readiness 
2. Lack of organization readiness 
3. Existing tools (sort of) work

Let’s talk about each of these in depth. 

#1 Lack of Data Readiness

“We can’t easily make product data available to third parties (usually due to some data quality concerns or a lack of a data warehouse)” ‍

The data readiness story boils down to “our data is a mess”. 

This is especially true for traditionally sales-led organizations who have recently made the switch to PLG. Their data infrastructure may not be capturing enough data yet, the data schema may not be well-defined, or the data  may not be accessible in an organized system like a data warehouse. 

We hear that a lot of the internal build process focuses on getting the various sources of data (typically product data and customer data) cleansed, shaped, and available. This is all required before you can even start to work on downstream uses of that data like building PQLs, creating scoring models, updating records in third party tools (like the CRM), or driving automation. 

Is it a valid reason to build internally?

Yes and no.

It is true that using a third party platform for PLS would be challenging without access to the data you need to power that platform (usually product data and CRM data). 

However, getting data into shape is only half the battle. Once data is ready to go, it is probably not the best use of your technical team's time to try and build the rest of the solution.

GTM teams require MUCH more than just raw data. They need insights that they can action and a tool to help orchestrate getting those insights into the hands of the right people at the right time. 

Typically, building this part of the Product-Led Sales machine takes much longer than just cleaning up the data (we’ll get to the numbers later in this post). Like we said, getting data into shape is only half the battle - the other half is building the automations, workflows, dashboards, scoring models and more. Not to mention, after you build them, you need to maintain and update them over time.

Our recommendation

Work with vendors that can act like partners. 

When choosing a PLS platform vendor, it will be important to evaluate not only product capabilities, but also willingness to meet you where you are in your journey. 

Don’t be shy to ask vendors if they have suggestions for a data warehouse, or if they can provide  additional insights that can expedite your process for getting data ready for third party PLS tooling. 

#2 Organization Readiness

“We’re not sure how we’ll operationalize this within the GTM team, so we’d rather try and build an MVP internally first to test it out.”‍

Enabling your team on a new tool can be especially hard to do when you haven’t quite nailed down your Product-Led Sales goals, motion, and how you’ll measure success. You’ll want to experiment with a variety of workflows and models before nailing down the right one.

It may sound more appealing to try and build an MVP solution internally as you work out those kinks before investing in a third party solution. 

Is it a valid reason to build internally?

Yes and no. 

If you are very early on in adopting Product-Led Sales, our advice is to not buy a tool you are not ready to use. Despite being a PLS vendor, we want to be honest and tell you - it will be a terrible experience for you and the company desperately trying to activate you on their product.

But, if you are in the phase where you have various hypotheses for Product-Led Sales (eg. goals, PQLs, workflows, etc.) and you want to test them out, we’d suggest using a third party solution that allows for experimentation. PLS platforms can help you experiment with different workflows, dashboards, and PQL scoring models without re-building the tooling each time. You’ll avoid bothering your data engineering and data science teams every time you have a change in the model.

Our recommendation

If you’re early on, try a good old fashioned excel analysis to organize your motion and use your project management skills to map out the process for operationalization. DO NOT bring in technical resources just yet - you can do this all without relying on heavy data analysis. Host a workshop to align your team on PLS goals and how you’ll define PQLs (or work with a vendor that can help you - hint it’s us). 

If you’re a bit later on the journey and have hypotheses to test, we recommend engaging a vendor that can help you validate those hypotheses by testing them on the platform. You should make sure that the PLS vendor enables experimentation (aka nothing hard-coded), so that you can learn and grow before you scale.

#3 Existing tools investment

“All we need is our product data in our CRM, so we should just build those data pipelines and everything else works well as is…”

Three words: sunk cost fallacy.

The desire to try and make it work with your existing set of tools is not at all unreasonable. You already pay your CRM vendor a lot of $$$, so why wouldn’t you try and get more value from an existing tech stack?

We’ve seen some pretty impressive setups between product data warehouses and CRM systems using custom integrations with Zapier + BI tools + reverse ETL solutions. Credit where credit is due, a scrappy GTM team will always find a way to DIY their needs. 

Is it a valid reason to build internally?

Unfortunately, no.

The issue is that all of those customizations, automations, and administration probably required precious time from your technical resources. In order to maintain this system or add to the customizations, you’ll once again need to bring in a technical resource. 

Our Recommendation

Leverage the best parts of your CRM and marketing automation and combine it with your product data warehouse and a purpose-built solution for PLS. 

What if I’d rather build anyway?

Well, first you have to decide what you’re building. It boils down to three options depending on your resources and existing workflows. 

1. Dashboards in tools like Looker, Metabase, or Tableau 
2. A custom built tool that connects product and CRM data
3. An integration that pulls product usage data into your CRM 

And then you have to decide which compromises you’re willing to make — since all three of these have different downsides — but they also offer a solution to different needs. 

Let’s dive into the first one: 

Building custom dashboards for PLS

A custom-built dashboard is pretty great when talking about data visibility. Get your data and eng teams together to make an easily scannable and filterable product analytics dashboard and you’ve won half the battle.

But, that’s kind of as far as you’ll get. The other half, which is turning those insights into actionable leads and revenue (fast) is almost impossible with this option. Data dashboards aren’t really built for sales, they can’t be set up with signals, triggers or basically any automation. So, although the insights could be helpful, your Sales team won’t be able to quickly action incoming leads.

Building a whole new internal tool for PLS 

This one is tempting, especially if you’ve got a top-notch dev team. But that’s just it, is an internal tool really where you can put their skills to use? It’s not just the time it takes to build, there’s the cost of regular maintenance, which is a high one. PLS relies on defining and redefining PQLs with ease and flexibility. 

Odds are your GTM team will find themselves requesting changes they can’t execute and your engineers will be stuck in a slow feedback loop, with a hefty backlog. 

Integrating usage data into an existing CRM

This one is the closest to a middle ground between the first two. It requires some eng power, but it can be done faster than building a new tool and provides more actionable insights than a dashboard. However, CRMs like Salesforce aren’t built for PLS — so after a while it’ll start to seem like a bandaid on top of a much bigger problem. 

• CRMs are not built to handle time-series data. The only way to get important product usage data into your CRM would be to create custom fields and populate those with aggregate product usage data. If you can only ever see a few aggregated data points in a few custom fields, then you may miss out on important trends in product usage that could inform whether an account is ready for sales
• CRM’s rigid hierarchy for data objects doesn’t support a PLG motion. So you are forced to shoehorn your PLG motion into this hierarchy, which creates a lot of confusion. Is every product sign-up a lead? Or an account? In a product-led world, objects beyond lead and account can be a helpful way to measure the growth of your product and CRMs make it difficult to break the rigid hierarchy of data objects. 

👉 Read more on the pitfalls of CRMs for PLS from Pocus Co-Founder Isaac here.

The real cost of internal builds

Now that we understand the common objections, let’s talk brass tacks. 

The numbers. 

The numbers are not on the side of build when it comes to PLS. From a time to value and cost perspective, buying a third party tool is the clear winner. The only exception is if you are a very large enterprise where you have the means to staff a fully loaded internal team who will be responsible for not only the build but also ongoing dedicated maintenance. 

Let’s look at some examples

Enterprise  

A large enterprise software company who is well-known for being early to the PLS approach took 1 year, 3-4 engineers (including a data scientist), and 2-4 operations resources to build out their Product-Led Sales solution on their first attempt. They still have significant resources dedicated to maintaining the internal solution today.

One of their biggest challenges: hiring the right team to build the tool. 

Mid-market

A fairly large mid-market company also well known for their PLS approach had a team of 3-4 technical resources and 2 ops/data resources working on this for many years. It took 6 months for an MVP version of the internal tool to be released, despite the vast subject matter expertise on the team. 

One of their biggest challenges: combining data from their vast data warehouse and CRM and making it actionable/relevant for individual sales reps.

SMB  

On the flip side, sometimes being a smaller team makes it easier to get things done faster internally. However, beware of the double edged sword. A smaller team also means that a larger percentage of your total employees will be working on an internal tool instead of focusing on the core product. 

In this example, it took 6 people 4 months to build the initial PLS solution internally. With a bulk of those 4 months spent building and testing the infrastructure for piping data into Salesforce. 

Conclusion

Every single person interviewed who built their solution internally said that it can be done, but they would rather not do it again. They especially would not do it all over again because tools now exist that solve this problem in a more scalable and robust fashion.

The main challenges of internal build will always be:

• Lack of dedicated resources, or it takes them away from your core product 
• Lack of adoption from non-technical teams, like your SDRs (who really need this data!)
• Cost of ongoing maintenance for internal teams 
• Slower time to value 
• Can’t be iterated on fast enough
• It’s usually not as sophisticated as it could be 

Now you might be thinking, “well obviously you think we should buy it, you’re a vendor!”

And yes we will admit, all of our advice is probably biased towards buying because we are a vendor.

However, just like every other software company, we make build vs. buy decisions internally as well. While the advice in this blog is focused primarily on Product-Led Sales tools, we would apply the same logic to any build vs. buy decisions we make in other categories. 

For example, a lot of companies in SaaS outsource 100% of their content marketing, which is a build vs. buy decision. In our case, content is core to what we do, so this blog post was written 100% by me (and some helpful copy editors 😉).

When faced with a build vs. buy decision for anything, ask yourself:

1. Is this a core competency I want to invest in for business growth?
2. Is this something worth spending precious engineering resources on? 
3. Are there vendors who obsess over this and can do a better job than us at a lower cost?

Want more advice? Join the PLS community to ask GTM experts who have “been there, done that”. Request an invite. 

Ready to make the "buy" decision? Join our waitlist.