Swiss Army Knife vs. Precision Tool
Build it or buy it? If you're talking about adding capabilities to CRM, it helps to start with an all-in-one solution. Read: "Everything Starts Out Looking Like a Toy" #195
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: using data to decide which character to play in Mario Kart. It might seem like too much analysis for the task, but pay attention. There’s some great data visualization here and a process that you can map easily to other less silly things. And in the meanwhile, you’ve got a data edge the next time you play. Edition 195 of this newsletter is here - it’s April 22, 2024.
Feeling lost in a sea of sales tools? Apollo.io has your entire GTM stack covered.
A true end-to-end sales platform with a huge (and very accurate) lead database, enrichment, outreach, call intelligence, scoring, calendaring, and email automation. They integrate seamlessly with your CRM and existing workflows. The quality of Apollo’s data is unmatched; they are ranked #1 for contact and company data accuracy on G2 with over 6800 reviews and a 4.8 star rating. Book a meeting to get started for free.
If you have a comment or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ Swiss Army Knife vs. Precision Tool
This conundrum comes up almost every time you think about buying a Revops tool: "should we buy the best-in-class precision tool or find the best swiss army knife all-in-one product that does a good enough job?"
In the CRM (Customer Relationship Management) world it’s particularly challenging. The goal is to get you to standardize on a single platform for ease of use, limiting the number of vendors, and taking advantage of an ecosystem that grows up around the tools.
A CRM is an application built with data models that are converging to things like Companies, People, Sales Opportunities, Campaigns, Campaign Members, and custom objects. But there are newer event-driven time series that are also important, tied to product usage, external third-party events and other novel data.
This leads to a conflict when you need a new capability: build it, or use the equivalent (or lesser) capability in the all-in-one tool?
Why to use the All-In-One Tool
The best reason to use the capability that exists now is simply … that it exists now. If I wanted to build an approval process in Salesforce, I could choose to build a Salesforce Flow to model this capability; or I could use a webhook to trigger an external service to start the approval process; or I could use the built-in feature.
The opportunity cost for building a new capability is high. This doesn’t mean that you should always use the All-In-One idea. What it means is that regardless of the method that you use to model the work that gets done it’s important to abstract the Job To Be Done from the Feature That Already Exists. If you find that it’s not that much of a tradeoff to use something already built, you can get to using it faster.
And speed to solution might be the goal in RevOps today.
The value of a solution looks like:
How many times (a day, a week, a month) does someone run into this problem that needs remediation?
What’s the value of getting it right? Conversely, what’s the value of leaving it alone and doing nothing? (Does it cause harm to keep the null state)
Do you have a good mental model of what fixing it would look like and how to build that solution?
Is building a custom solution the only way to solve that problem OR the best way to solve it to maintain it for the future?
Pay attention to Step 4 above. Maintainability and usability are key to thinking about infrastructure so that you end up with a series of capabilities that are related instead of an assortment of unrelated features built in different all-in-one tools.
The case for precision tooling
The beauty of making a custom solution is that you don’t have to build all of the features you would build if you were creating a commercial product. The downside of making a custom solution is that if you want to build some of those features it will take longer, or you need to rely on different custom frameworks (hello, Pipedream!)
The best case for a custom solution is that it allows you to do something faster, more efficiently, and better than the version of the solution in the all-in-one tool. Have you ever tried to send a notification from Salesforce to an external system when an important event happens based on data that combines information in Salesforce with information in another system?
If you try to do this using the all-in-one approach, you need to echo other data into Salesforce and rely on its timing and broadcasting features to send your request. Now, think if you’d like to customize the message with data from another system. And whether you want to memorialize the current version of this workflow to source control.
Once you go through this mental calculus, you’ll end up likely thinking that it’s reasonable for Salesforce (or another all-in-one system like Apollo or Hubspot) to trigger the event in a webhook when it happens, but to use a custom external product (I use Pipedream, but Zapier, Make, and others are good solutions for many integrations) to bridge the gap to the next step.
Centralize the activity where it makes sense
You’ll notice I’ve been talking about using the outputs of an All-in-one system to drive additional capability for Revops teams. A sales user or a marketing user has different needs - namely, to work in the same system as their peers or to work in a system that shows them similar views of the companies, sales opportunities, and contacts they are using.
Over time, I’d argue for a customized CRM (and maybe even custom software verticalized for your need) if you have the engineering resources to support it. But if you don’t have that resource, using the All-in-one software most of the time makes sense to get the capabilities you need. And it has the added bonus of providing market validation for the precision tools of the world to build an integration ecosystem around that tool.
What’s the takeaway? Although All-in-one platforms often seem like they are not customized for your use case, the act of figuring out what problem you’re trying to solve often opens up a way to solve it in that all-in-one platform. And for the instances where only custom code will do, using an integration bridge like Pipedream is a critical component to building a maintainable process for the future.
Links for Reading and Sharing
These are links that caught my 👀
1/ Video game art - The illustrations in video games are awesome. Yet this art form is threatened by the tools in generative AI that make it easy to parrot the design aesthetic presented here. It’s an ongoing debate to identify which parts of creativity happen through tool usage, and which ones are simply imitation.
2/ Distributed source of truth - Eliya Elon writes on the Intent Data Stack and how to build your own data pipelines for intent. This is a great example of why not to rely on the all-in-one CRM products for everything, and how you can stitch in best-in-class information at the right time to make an impact.
3/ The Best EULA - The only EULA song I’ve ever heard. Before you dismiss AI music generation, it might be a great way to get us to pay attention to the details of legal agreements.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon