Product-Led Sales tools: Build or buy?

The age-old question every SaaS company 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. The user experience is the driving force of PLG investment.

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, first check out this blog to learn how PLS fits into the product-led growth 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 to build and maintain 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 and action qualified 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.

Convinced? Then, dive into this framework on how to evaluate Product-Led Sales platforms and choose the best one for your business - scoring template included!

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 is the most precious resource within a company, so why would you want them working on something that is not a “core product”?

Your engineering resources are better spent on your product roadmap, adding value with features that increase product adoption, improve in-app onboarding, and move the needle on activation and retention. In other words, they should be focused on building an amazing product.

Based on community conversations, below are some of the reasons why companies are hesitant to buy 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 go-to-market 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 SaaS businesses that 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 usage 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 to execute a product-led growth strategy. They need insights on user behavior 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). As we said, getting data into shape is only half the battle - the other half is building the automations, workflows, dashboards, scoring models, and everything else that influences the customer journey. 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 the metrics you’ll need to 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 playbooks, lead scoring models, and PQL and PQA definitions, without re-building the tooling each time.

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 - and start optimizing fast! You should make sure that the PLS vendor enables experimentation (aka no-code) 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 favorite tools like HubSpot or Salesforce and combine them 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 analytics 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 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, 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 action, or qualify leads, in real-time. A successful PLS motion hinges on reaching out to potential opportunities at the perfect moments during the user journey - with messaging that resonates with their specific use case. Dashboards just don’t support this level of PLS maturity.

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 and PQAs 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 outreach or could benefit from customer success to help them hit the next milestone, or “aha moment” in your product.
• CRMs’ rigid hierarchy for data objects don’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 self-service sign-up a lead? Or an account? In a product-led world, objects beyond lead and account are crucial to keeping a tight pulse on the product experience, potential churn signals, and finding the product champions that will help you expand from individual users to accounts. 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 building 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 product-led 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 large 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. Startups move fast. 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. A bulk of those 4 months were spent building and testing the infrastructure for piping data into Salesforce.

The biased truth, is still true

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 building internally 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 toward buying because we are, in fact, a Product-Led Sales (and more generally, a Revenue Data) platform.

However, just like every other software company, we also make build vs. buy decisions internally. 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?

🪄 Request a demo, or do the PLG thing and explore Pocus on your own!