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.
At Pocus, we’ve had these conversations firsthand with our customers and with the broader Product-Led Sales community. In fact, according to our recent benchmark report, 10.6% of survey respondents have plans to internally build a PLS solution. The question has come up enough that we think it’s time to share what we’ve learned.
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).
Just because you can build it, does it mean you should?
As I mentioned above, 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 buy a new tool - to avoid retraining our GTM resources on a new solution.”
If we break down these concerns, you see three major categories:
- Lack of data readiness
- Lack of organization readiness
- 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.
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 whether they can help get your data ready, 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.
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.
Also, word of caution that even building an MVP can be massively time consuming for your precious technical resources and that MVP may not adequately demonstrate the value of a PLS motion. If your goal is to build an MVP and then implement a third party solution, we recommend skipping the MVP part and working with a third party vendor that enables experimentation.
#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?
A handful of GTM teams in the community have been executing on their PLG and PLS strategies by building incredible customizations within their CRM. 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?
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.
Most GTM teams do not have full- time technical resources assigned to their projects, so it usually turns into a resourcing battle.
Additionally, the solution works, but doesn’t work well. You may be able to see “this account has 5 DAU”... but, who are those users? What features did they interact with? How many invites did they send? This is typically data that is not easily accessible with internal builds without switching between multiple tools.
Getting the most out of your existing GTM tech stack does not require you to build your PLS solution within the 4 walls of your CRM or marketing automation tool.
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.
CRMs like Salesforce were not designed to be rich data visualization tools like a BI dashboard nor were they designed for the realities of PLS. We have more thoughts on this topic here.
The real cost of internal builds
Now that we understand the common objections, let’s talk brass tacks.
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
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.
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.
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.
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
- Cost of ongoing maintenance for internal teams
- Slower time to value
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:
- Is this a core competency I want to invest in for business growth?
- Is this something worth spending precious engineering resources on?
- 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.