It’s 2023, and all the talk in B2B SaaS is about what’s getting offloaded to AI. But what about good ol’ fashioned customer data?
Maybe it’s time SaaS orgs took control of their single most valuable asset with some intentionality.
- Why SaaS is plagued with a false dichotomy between product and GTM
- Why a unified approach to customer data makes all the difference in your GTM
- What changes you need to make to stop being bogged down by data issues
[Transcript] No One Owns Your Customer Data Strategy? #Fail
Although transcriptions are generally very accurate, just a friendly reminder that they could sometimes be incomplete or contain errors due to unclear audio or transcription inaccuracies.
This is section one of the second half of the Ops track. We like to remind people of that, Evan, because there’s a lot going on today, and it’s easy to get lost like four tracks and like 48 speakers. It’s a lot, it’s a lot.
I’m excited to have you, can’t wait for your session, “No one owns your customer data strategy? #fail” The stage is yours.
Alright, we’re going to dive in. I’m Evan Dunn from Syncari’s Growth Marketing. I’m a performance poet in my spare time. I do have COVID right now, so forgive me if I break down coughing; we’re just going to go into it.
B2B customer data has been a mess for a long, long time. Most of you probably have felt this personally. I definitely have, at two different hyper-growth unicorns. Data quality is still the reason everyone is miserable.
But let’s be specific: We’re talking about customer data quality, right? We’re talking about CS tools, marketing tools, sales automation, CRM, ERP, billing, and even product usage data.
Getting that all to run together for a cohesive customer experience is laughable to most people.
This whole journey around customer data has been interesting, right? A lot of people in B2B land, software companies, really have an allergic reaction to customer data. They think that’s CDPs, and that gets really confused because CDPs are really something kind of different than a universal or unifying approach to your customer data.
I started asking people, “Do you have an example of a B2B customer data model?” Right, like here’s the customer, and here’s how they’re represented across all the different systems, across opportunities, contacts, accounts, billing entities, user accounts, user entities, etc., and pretty much got crickets back.
Data teams tend to have something, but most go-to-market operators don’t have a unified model for their customer data. We’ll come back to the impact of this and why it’s such a big mess.
But we’re going to get into how we got here a bit, right? If you’re in software, there are two legs that pretty much walk the software company forward. You’ve got the product leg, you’ve got the go-to-market leg.
Typically, you start with one or both of these in the early days, and then all of a sudden, you want to analyze user data, you want to get into user behavior, and automate some triggers in your product. And you hire a data team to support that product team.
And then, on the go-to-market side, you’ve got sales, marketing, CS, and then you’ve got operations teams that start to help them be more efficient and effective with outreach and with their communications with customers.
Pretty quickly, data needs arise in three veins. You’ve got the product automation and analytics that becomes a warehouse with a product analytics tool, user behavior analysis, and feeding into, okay, how do we change the UI UX, how do we change engagement in there?
We’re not going to talk so much about that today. We’re going to talk about these two other scenarios: business intelligence, where leadership says, “Hey, I want to see what’s happening on the ground,” and go-to-market data quality and automation.
In other words, the fields, records, and mapping of data within the go-to-market stacks here and ERP, marketing automation, sales automation, etc. Both of these pop-up, and the question comes pretty quickly, like, “Who’s going to own this?” Well, the data team, because it’s in the name, right?
Traditionally, data teams take over this kind of holistic approach. So, you’ll notice that go-to-market data quality and automation don’t really roll off the tongue. There isn’t a category for this so much. There are data quality tools or bypass tools that live inside of the go-to-market stack, but that’s generally separate from a modern data stack or warehouse approach to solving those use cases.
Whereas the business intelligence stack is pretty much always a warehouse. As I just answered a question in the community this morning where someone said, “We’re going to build out a BI stack. I need good recommendations on a consultant who can get us a data lake or warehouse and a BI tool.” That’s just how it’s done.
Is this product-based data team really the best fit for BI and go-to-market data quality automation? We’ll come back to that a bit.
They still struggle with data quality from source systems, meaning the go-to-market stack, right? Are they the best fit for go-to-market data quality automation, or have we kind of been hoodwinked a bit over the last decade? No one’s fault, just the wrong approach.
If you look, I’m going to answer that last question: Has this been the wrong approach? I mean, the data team owns go-to-market data quality and business intelligence.
If you look right now in LinkedIn Sales Navigator, you, and you put in, you know, U.S software companies, 50 to 1,000 employees–so mid-market SaaS, let’s say, and you put in RevOps, go-to-market Ops, Marketing Ops, Sales Ops, etc., etc., so lots of different permutations of that title, you’ll stop at about, you’ll cap at about 6,000 people.
If, instead, in the same set, you put in data analytics BI titles, all together, you get about 41,000 people. Now, if even half of these people are dedicated to, on the data side, are dedicated to product engagement and analytics, it’s clear that the industry has made one really big bet, again, on the data team and the data stack.
We’re not the first to recognize this bias and investment and even call it some sort of bloat, right? Sacra, in September, and many others have followed suit, analyzed this as the fat data layer in B2B SaaS.
There didn’t used to be so many tools involved in handling data for go-to-market teams, right? Now, whether or not you feel like this lopsided investment is a problem, let’s talk about the situation again, right?
The sort of level setting: Go-to-market teams need more data support than they’re getting. Most data teams and leaders don’t see themselves as an active part of that go-to-market data quality and automation solution.
In fact, the thing now, if you’re in data, is to say, well, let’s do a data contract, which doesn’t actually help go-to-market operations. It says go-to-market operations need to adhere to these standards for data in order for us to work together and push data into the warehouse.
When we asked who owns customer data, Elise Vu of Syncari went to her audience on LinkedIn and asked, you know, sales and marketing folks, “Who owns customer data?” They all said RevOps.
When I went to the customer data quality camp and asked, “Who owns customer data in B2B?” they all said product. This divide is really important, and you see it all the time. There’s a go-to-market versus product chasm, if you will.
It was our newsletter last week. The RevOps teams rarely have the skills or resources to solve what Andy Moont of Gated, formerly Box and Upwork, calls the data layer. We had a podcast with him recently on this topic as well.
Now, stuff is really hitting the fan, and I want to be clear: We’re not saying this is anyone’s fault in particular, just that there needs to be a better approach, a holistic approach to customer data.
If you think about it now, we’ve got tons of layoffs in go-to-market teams, sales teams especially, CS teams, and even data teams are hit with these layoffs, right? Go-to-market efficiency is all of a sudden the number one priority, and you can’t go to market effectively with messy data.
Anyone who’s been in a demand gen or marketing role, like me, trying to get things done with messy data, you can’t. iPaaS and CRM-only data quality tools don’t solve it because they’re just moving the mess around or trying to clean up in the CRM and push it back out.
Data teams aren’t attached to business value, and now they’re suffering for it. Data teams on blind talk about this all the time. They can’t find data science jobs; they can’t find analytics jobs that aren’t miserable, right? Dealing with data quality issues and shifting stakeholder requirements.
So, there are a few antidotes I’ve got here from social. Here’s Mark Freeman talking about data quality issues: “We’re a data-driven company. We need to focus on building new features before we invest in data infrastructure. Why is it so hard to understand what our users are doing in our product?”
And that’s actually a product analytics data quality problem.
Here’s Julie Gilinets; it’s a CRO of Pocus. Now, congrats, Julia. Hopefully, I said your last name correctly. She’s just a bit ago was talking about why we are chasing down customer data everywhere. She’s been in tons of scenarios where we’re looking at five to ten different tools for this data.
Here’s Cassidy Shield of Refine Labs: “Our CRM data is a mess” is the number one issue he hears preventing marketing and sales progress. I commented to say, well, it’s more than just CRM, right? And he agreed. This is a pretty common issue across the entire go-to-market.
And here’s a data person on Reddit. Thank you, Richard McCar, for sharing this. Getting extremely fed up with how tedious this feels; clean data doesn’t exist. And here he’s talking about dashboard requirement changes, changing colors on a dashboard, and that sort of thing.
And this one is painful. This is a friend, head of CS at a unicorn: “Manual data work is the bane of my existence, but I’m afraid to leave and find the same thing somewhere else.” People leave jobs over data issues. Absolutely, they do.
So, symptoms of this mess: Are you one of these companies that struggles with the customer data mess, we’ll call it? High churn among GTM roles? Look for this. Frustration with Ops support from sales, marketing, CS, and finance. Do they feel like they’re not getting enough help when really the Ops people are drowning, too?
Last-minute scramblers to do anything that requires a data transfer requiring SQL and go-to-market roles like CS or just lots of wasted time auditing records and gathering context, chair swiveling. I’ve spent way too much of my life auditing leads.
What can you do? You can dig deep into the data issues and go-to-market. How much manual data work is actually happening in frontline teams? Where are the customer experience breakpoints? They usually happen in the handoffs between users and CS or sales to CS. Are accurate, consistent reports elusive, or even if they’re just basic reports on pipeline and things like that?
Identify one or two people, ideally one GTM Ops and one data person, to own the customer data. To sit down and create a customer data model and visualize what that means. Deploy the model to the best of your ability across your stack. Shift some of the data engineering power from the product side to the go-to-market Ops side. That doesn’t mean they need to change teams. They just focus on enabling go-to-market operators to have clean data.
Andy Mowat, on our podcast the other week, said, “The world should not have to learn SQL to be good in data.” And that was part of this whole story of, you know, we really need to enable go-to-market teams to be successful with business data across their entire stack.
So, if you want to be further part of this conversation, join our community syncari.com/cda. We’ll take you to the customer data automation community, where we’re having these conversations every day.
Hot Takes Live
Catch the replay of Hot Takes Live, where 30 of the top SaaS leaders across Marketing, Sales, and RevOps revealed some of their most unpopular opinions about their niche.
These leaders shared what lessons they learned and how they disrupted their industry by going against the grain (and achieved better results in the process).
Evan, thank you so much. I love this topic for obvious reasons, and I very, very much second what you just walked through. I have a few reactions. Number one, weren’t CDP solutions supposed to solve this?
Yeah, I think you know the answer to that, right? CDP came onto the scene when web analytics was a big need, and user analytics was a big need. And it didn’t really bring anything new to the table in terms of integrations. So when CDPs try to unify the stack, they’re running into the exact same problems as ETL and iPaaS providers. They’re just copy-pasting from A to B and trying to unify it in a warehouse, but that warehouse is just hidden inside of the CDP.
Right, right. Then the other question is about RevOps or Ops in general, as far as I can see. I’m curious about your reaction here, whether you see the same thing or not. It’s more often than not an operational role. It’s not a very strategic role, right?
They are like a service provider, for lack of better terms, to the rest of the organization. So they have a super long list of things that they need to look into and take care of, and they need to prioritize a lot of competing things in there. Is that your experience as well?
Oh, absolutely, and their bias naturally is to create a field to solve a functional flow, you know, workflow process use case, just to get it done and get it out the door because they’re in the revenue organization.
They’re under pressure for revenue, not pressure for data quality, whereas the data team is under pressure for pipelines that work. Maybe they should be attached to revenue a bit more closely.
But so data teams are mad at Ops teams, right, for bad data quality. Ops teams are, you know, underwater trying to just support this machine. Yeah, and this is how you get a decade and a half into this problem with no common solution.
Right, right. And so, first and foremost, if there are additional questions from the audience, feel free to just shoot them over in the chat. We’ll take them from there. But, like, so how do you solve this?
Yeah, I mean, obviously, I can give the Syncari pitch. But beyond that, today, right, like it starts by thinking through this logic, right? The customer data exists for the customer experience. There’s one customer. There are not five customers in many systems, right?
Yes, but that’s the mechanical part. Then, to some degree, there is also, like, there should be a strategic owner or like a customer or the strategy owner that’s higher up in the decision…
Yeah, yeah. And people get really hung up on titles here, Armando, all the time. They’re like, “Oh, should it be the head of data, head of RevOps?” I don’t really care, right, as long as it’s clear that this person’s job is to enable a holistic view of the customer across all systems and reports.
Without that mentality, nothing else can work. Right.
I think to me, it’s really two things. Right? Elevating this aspect, which is like mechanical, so you have to be able to navigate it to a decision-making level.
And then there is another aspect of it, which, again, curious about your reaction, which most companies don’t really think about is this idea of tying data back to actionability, some kind of business outcome that matters and moves the needle because otherwise, why are you even keeping all this data for? It’s just like a weight, a cost of doing business that doesn’t help anyone.
Yeah, absolutely. I think data teams tend to be biased toward the collection because it’s very hard to answer the question: Which data is valuable? Right. And the product data bias is to collect many, many, many, many events.
And then analyze to figure out, and there’s some wisdom to that, right? Because if you discard it, well, you know, maybe there was gold in there. But you’re right. The warehouse data warehouse industry push has been collection bias rather than action bias and utility bias of data.
RevOps uses data for what purpose?
Absolutely. RevOps and data teams need to get together and collectively determine what is the minimum viable data that you need in order to serve the customer well.
Love it. Well, Evan, thank you so much. Thanks for watching everyone as well.