With Product-Led Sales as a new category, many companies wonder whether they should buy a tool or build something in-house to support new rep workflows. Reps need a way to see product insights, prioritize top accounts, and take efficient action to close deals.
So what does it take to build out these capabilities – and is it worth doing it yourself?
For starters, our founding team did build an internal tool at Twilio (called Monkey 🐵). We soon realized it was a huge pain to have to rebuild this at every company. We’ve also spoken to customers who did have internal tools prior to buying our platform, which we’ll cover in this blog.
We are obviously a bit biased, but there’s a reason many of the most successful PLG companies have realized PLS requires a platform, not a set of homegrown tools. Let’s go back to where it all started.
To build, or not to build!
It’s widely accepted that the fastest growing SaaS companies leverage both top-down sales and bottom-up adoption to drive revenue. Product-Led Sales creates a bridge between the two, and is consequently climbing in popularity.
Activating a PLS motion comes with 3 distinct hurdles:
- Challenge #1: no visibility into product usage
- Challenge #2: impossible to prioritize signups
- Challenge #3: difficult to take action between different tools
When deciding whether to build, it’s important to determine if you’re able to have full coverage of these key areas. Most teams like to leverage existing tools to solve these challenges.
Existing tools landscape
Existing tools that aim to solve the PLS challenge fall into three buckets: visibility, scoring, automation
Spreadsheets, dashboards, product analytics tools, and CRM integrations (or reverse ETL) can provide visibility. Lead scoring tools can prioritize signups. Workflow automation platforms can minimize tab jumping between tools.
Product usage visibility
- MadKudu, 6sense
- Zapier, Workato, Tray.io
You’ll notice there are far more tools in the first bucket than the last two. That’s because Challenge #2 and #3 are more sophisticated than Challenge #1. PQL scoring and actions are typically harder to build for. Lack of actionable PQL workflows is a common problem experienced by many sales teams.
Biggest in-house pitfall
Fair warning before you build anything – the pattern we’ve seen with many teams is that their in-house tools aren’t actionable enough. Most approaches to building internally consist of dashboards or CRM integrations to push product data in front of sales teams. But bringing product and CRM data together is just the bare minimum.
These internal solutions usually lack the ability to have:
- PQL signals and insights instead of raw data
- Proactive alerts instead of passive dashboards
- Automated workflows into downstream tools
A Product-Led Sales platform needs to be actionable and proactive, instead of static and passive. Keep this in mind before building, otherwise the benefit to sales is greatly reduced. The next section explores the top ways people build for Product-Led Sales.
Five approaches for in-house – and what it takes
After chatting with hundreds of product-led companies, we’ve uncovered five common approaches to building in-house. These approaches are ranked in order of low investment to high investment needed from technical teams.
The amount of impact you ultimately have on the sales org depends on the level of commitment and resources you dedicate to building and maintaining the solution. You get out what you put in.
1. Product analytics tools
Sales team adoption: low
Technical team overhead: low
Not exactly. This solution has the lowest adoption by sales teams, because you’re essentially having them work inside a platform built for product teams. Without a sales-centric view, it’s common to involve developers to help digest product analytics data for GTM purposes. Reps are tasked with hours of data analysis instead of actual selling.
As Erin Tran, Co-founder at Hookdeck and a Mixpanel user shared with us: “There's a real gap between product analytics and the action needed to move people along the sales funnel.”
Sales team adoption: medium low
Technical team overhead: medium low
Many companies decide that since PLS is a priority, data teams should cater to sales teams more. Spreadsheets allow data teams to curate the specific accounts and product metrics reps care about.
The drawback is that there’s still a slower time to value. Sales orgs that depend on a data team usually lose weeks of time for data requests – eliminating any chance of speed-to-lead. Even worse, requests are often ignored because data resources are expensive and not dedicated to sales.
Netlify previously used an in-house data team for sales, but switched to Calixa to reduce the wait time.
3. BI dashboards
Sales team adoption: medium high
Technical team overhead: medium high
If product analytics tools are too technical and spreadsheets too slow, what about BI dashboards? Companies build dashboards in Looker, Mode, or Tableau to offer a better dynamic view for sales teams.
While there’s some progress compared to the previous two solutions, it’s still just a view. Reps will dig around for insights and then must leave the tool to take action. Working off of dashboards is very manual, since there’s no way to update records and kick off sequences. This hurts sales efficiency.
Instead of adding a BI tool to their tech stack, Opencomp went from juggling 5 tools down to 2 with Calixa.
4. CRM integrations
Sales team adoption: medium high
Technical team overhead: medium high
To reduce context-switching, some teams decide to pipe product data directly into the CRM. This can be done through custom integrations or reverse ETL solutions. Reps can then see CRM fields that have product usage insights about their accounts – and create an opportunity right then and there.
The main issue here is that CRMs are not typically built to handle product data. For example, it is tricky to plug in data about team workspaces into a rigid Company/Contact hierarchy. If reps cannot see dozens of workspaces inside of a single enterprise account, they’ve missed out on potential revenue in their account base.
Calixa built Flexible Account Models to solve this problem. But for teams building in-house, having mismatched account models between the product and CRM could very well become a sales blindspot.
5. Custom tools
Sales team adoption: potentially high
Technical team overhead: extremely high
Obviously we can’t generalize on a custom tool. We can assume that if the project is well-executed and actively maintained, then sales teams will greatly benefit from using it. But that’s a big assumption to make!
It takes a highly-involved technical team to build and maintain a custom tool. So the first thing to overcome is lack of dedicated resources. For most technical orgs, building an internal tool for sales is never the top priority. They can easily kick the can so that a 6 month project becomes 2 years. You can’t really blame them, because successful companies don’t want to waste time building internal tools.
Even after you’ve secured the resources, there’s still risk. Building a PLS platform is non-trivial as it comes with a steep learning curve and ongoing maintenance. As people get pulled off the project or leave the company, all that hard-earned tribal knowledge gets lost – and the tool can no longer iterate and improve.
Common objections to adopting a PLS platform
Sometimes, companies are hesitant to involve a vendor because they believe certain things must be exclusively dealt with themselves. The top three concerns we see are around data ownership, data complexity, and overall strategy.
Our data team wants complete ownership
No data team wants to be reliant on a third party for data operations. It’s worth noting that Calixa still gives data teams control over their data. They won’t lose access. In fact, features like Property and Metrics Manager might even offer them greater control than before! Calixa lets data teams focus on more impactful projects instead of one-off data requests.
Our data is too complex for vendors
Another concern is whether the vendor can handle your data. Calixa offers Flexible Account Models and easily works with custom CRM objects. We adapt on our end to ingest any type of metric, and we partner with our customers to ensure their data is clean and usable.
We’re still figuring out our product-led strategy
It’s normal to delay purchasing a tool when you’re unsure how you’ll use it. Calixa’s entire sales team (Stephen, Kevin, and Jacob) has been in the trenches and spent years selling in a product-led environment. We offer consultative guidance from actual PLS people.
👉 Learn more about how to choose a Product-Led Sales platform.
Benefits of buying
Let’s say we give 2 handymen a task:
Build the best treehouse possible in a month.
The first handymen only focuses on the treehouse, while the second is instructed to also build an outdoor kitchen, dig up an outdoor pool, do the gardening, install new grass, etc.
Who do you think will build the nicest treehouse?
The same applies to software. Buying makes sure that you have the very best solution for your needs. Because people working on it spend 100% of their time and energy on making it as great as it can be.
Free up your team’s time
You want your team to focus on your business’s core offering, not internal edge uses. The opportunity cost of
Satisfy all use cases
The MoSCoW framework consists of four categories:
- Must-haves: Non-negotiable features
- Should-haves: Important features
- Could-haves: Nice-to-have features
- Will-not-haves: Lower priority features
Buying software from the 3rd party guarantees that you not only get must-haves, but should-haves and could-haves as well. Your team may not be aware of high-quality features that aren’t part of the main feature set, yet heavily affect the efficiency of your process if in your team’s hands.
After factoring in the cost of the initial build, support, bug fixes, upgrades, and keeping up with market trends, it’s no surprise that Gallup reports one in six IT projects have an average cost overrun of 200% and a schedule overrun of almost 70%.
Adaptability & connectivity
Third party software will improve over time and keep up with upcoming tools in your stack (through integrations), whereas built solutions won’t.
The inability to pivot a solution fast is itself an opportunity cost as the limitations of your in-house platform could compromise the desire to turn disruptive change .
There’s one big topic we’ve barely scratched the surface on in this blog: AI. Majority of the companies we’ve recently surveyed say they lack the in-house expertise needed to create AI-Powered Prospecting. It’s another big reason to consider Calixa over building in-house, which we’ll cover in future blogs.
If you’re using an in-house solution or have already started building one, don’t get too entrenched in the way things have always been done. Existing tools might look convenient, but it’s a mistake to fall for the sunk cost fallacy.
Calixa helps you realize the full potential of your PLS motion – while freeing up bandwidth for your technical teams to do what they excel at.