Earl Lee, co-founder and CEO of HeadsUp, on the modern data stack value chain

Fundamentally, what you're looking for is the ability to give visibility on who is using the product a lot to the sales assist team or product specialist team. That’s the baseline. The question is, how can you provide this data in some sort of dashboard? Some teams have taken it further and set up some set of automations or alerts that trigger based on users hitting certain points in the activation flow. As soon as someone adds their fifth colleague onto the product, that's probably a good, opportune time to reach out as a salesperson and try to convert that user or to reach out and help that fifth user get onboarded onto the product and start to unlock some of the multiplayer use cases of a PLG product. It's that combination of providing a way for these reps to dig into what's happening in the product, and then also making sure that you can be proactive about it and flagging those accounts when these sorts of events occur.

Now, the way that people do it today oftentimes is with a combination of more generic data tooling: like Looker, and we've also heard Retool being used frequently as well. Most of this will hinge around some kind of data warehouse, whether it's BigQuery, Redshift or Snowflake. And then of course you've got reverse ETL syncing data back into the CRM. When you're not using a dashboard tool like a Retool or a Looker, we've also seen some companies hack together a solution where you're using the campaign object in Salesforce to house a lot of the same data that you might see on a dashboard. People are finding very creative ways to use essentially generic data tooling to push reps the right information. It’s probably also worthwhile mentioning the IPaaS solutions here. Some companies are using that instead of reverse ETL to push data back into the CRM, but increasingly I think reverse ETL tools have taken the forefront on that.

Permalink

I'd love to dig into the marketing, sales and success teams. Could you speak to how those teams are organized, what their roles are, and if there are common metrics of engagement or usage that they look at?

I think the big difference is that we see a lot of sales and success being blurred together. The person that I've been talking about -- this sales assist or product specialist -- they're essentially a hybrid between a sales rep and a customer success rep and even a customer support rep. They usually do belong to the sales team formally at these sorts of companies, but we've also seen the inverse where some companies are very light on actual formal sales reps and heavier on a customer success team whose whole goal is to drive these account expansions.

I don't think the market has found or coalesced on the right way to do things because we still see a lot of different structures. But I think that one consistent theme, long-term, will be that the lines between sales and success increasingly become blurred, because there's not much difference between a user who's free and a user who's been a paying customer for a while. Your job as a go-to-market team should be to help that user unlock value from the product and continue to realize new value in the product, because that's ultimately how you're going to drive revenue. The role increasingly becomes much more consultative and success-driven than what I think we view traditional sales as.

Now, the marketing teams. It's interesting because we see in most cases that marketing teams are still focused more on just getting people to reach that sign-up status. Where you see the notion of marketing applied in a product-led sales context is more in growth teams that are thinking through, “Well, what are the types of email campaigns I should be sending to get people activated?" Because ultimately activation drives towards conversion, so these growth teams are, I would say, a parallel layer on top of traditional sales, marketing, and customer success. They're the ones focused on, "How do I set up all these automations that allow you to have a scaled way of nurturing and eventually converting users?"

What we also see is that sometimes growth teams will own conversion or the sale where there isn't a need for a human to drive that conversion. With product-led sales there are customers that will just sign up for the product and realize value really quickly, and you don't need a person to intervene and be like, "Hey, you should sign up for this business tier or enterprise tier." They'll just do it on their own. In fact, you don't want that because otherwise you're spending precious sales calories or sales reps time on things that would've already happened. So there's this segmentation of a growth team that would own this fully automated sale, and then a true sales team that is inserted to help grease the wheels and convert users that may not otherwise convert if there weren’t some hands-on help in figuring out how do I apply the product to solve my business problem.

There are essentially two primary buckets of “sales” here. One is a team that's dedicated to do fully automated at-scale conversion, and then there's a team that is much more of the human consultative-driven motion, where you're helping people realize value in a much more hands-on way. This is the case with products where there is a single-player mode that eventually tees up into multiple different stakeholders in the business. Consider a tool like Mongo. Any developer can start using Mongo on their own and start realizing value in that product in isolation. But if you, as a sales rep at Mongo, are going to make a large enterprise sale, you need some human being in the loop to talk to, like the IT department or the VP of engineering, who's not actually the one implementing things, but who will basically map out how this solution, as a whole, fits into the organization.

At the same time, Mongo has plenty of fully automated sales as well -- much smaller teams that are just signing up for their cloud product. That's where you might have these sorts of sub-automated email campaigns to drive people towards conversion there.

Permalink

You’ve described growth teams doing at-scale conversion versus a success-sales hybrid doing more hands-on conversion. To what extent do you see the PLG software stack fall along those lines in the organization, where there might be more developer-centric tools, like reverse ETL, on one side and then tools like Zapier or Segment on the more marketing-success side?

We see reverse ETL tools being owned and operated more by the data team. Sometimes there's a little bit of a blurred line between the data team and the growth team, so if you're talking to a growth team, they're probably going to be fluent in SQL and are going to be able to implement reverse ETL really well. If you're talking to a more traditional sales or revenue ops team, they're not going to be able to do that. They might be able to figure out Zapier. For that reason, there is some distinction there, but I'm not sure it maps cleanly to a broad category of developer tools. Beyond reverse ETL, I'm trying to think what else would be in that first bucket.

I guess a different way to think about it would be: you've got the data stack tools, and then you've got tools that are much more functionally focused on solving a sales problem or a marketing problem or a success problem and that try to do things more end-to-end and to be as non-technically friendly as possible. I think you can consider tools like Workato or Zapier to be in that bucket, just because everything's much more drag-and-drop and GUI-based. But you do see the data tools being owned by the data or analytics team and sometimes the growth team, and then separately rev ops or sales ops will find more end-to-end solutions like a HeadsUp to solve similar problems, but instead of only doing, let's say, this reverse ETL portion really well, these tools will  bleed the edges on what happens before reverse ETL and after reverse ETL. It's things like finding insight or driving automations, not just pushing data around.

One thing that a lot of companies in this PLG CRM category converge upon is moving beyond just displaying usage data in a way that is actionable for sales reps. It's also driving, let’s say, email cadences based on that usage data or alerts so that sales reps know immediately when to take action. You can hack those things together using reverse ETL, analysis, or IPaaS, but the PLG CRM category and tools within it  it make it much easier to ultimately drive that business solution of, “My reps know exactly when to act and they can much more easily take that action.” You'll see integrations into tools like Outreach and Salesloft that make it easy for a sales rep to push an email campaign against a user when a user unlocks some value in the product and have that email cadence ultimately drive towards a conversion.

Permalink

How do you think about CDPs like Segment, etc. and also tools like Zapier? Do you see these tools as nontechnical or less technical counterparts to reverse ETL?

I don't see that. You could say Zapier is a less technical version of a reverse ETL tool, but that's not quite true because the way they function is different. One is much more event-driven than the other.

When it comes to CDPs like Segment, I would consider them in the category of data stack tooling, which rev ops and sales ops teams don't normally have ownership over or really even the ability to deeply configure and control. Some do -- there are always exceptions. But when we're talking about the norm, Segment is usually going to be owned by the data team, and it's hard for the sales ops or revenue ops teams to use that in devising a solution for their needs, because they always have to go through some other stakeholder at the company. That's a huge friction point.

I’m curious how you think about reverse ETL tools more specifically. Is it possible that some of these automation tasks that are currently done less efficiently in tools like Zapier will be taken over by reverse ETL? Is there a world where reverse ETL, as a concept, is so successful that it puts a ceiling on other forms of automation? Or is reverse ETL a small part of what other tools are doing?

It's interesting because I saw recently that Zapier launched a feature that is reverse ETL.

I think reverse ETL has been very successful because it's a very clean solve. You plug in a warehouse, you connect to some SaaS tool, and you've already done the work of configuring these SQL queries or dbt to generate the data you want to sync. It’s almost like a light bulb switch, where you then can start to see that same data in Salesforce instead of having to look in a dashboard.

But to me, I feel like that's going to be functionality adopted by other parts of the data stack. We just talked about Zapier, but there’s Airbyte as well. They started before ETL, but they recently announced that they're going to get into reverse ETL as well. So I’m not sure where the defensibility comes from.

One thing that we’ve been thinking about is where consolidation might happen in this space. An example that comes to mind is RudderStack, which started as an open-source Segment alternative and then took on a reverse ETL component, and you mentioned Airbyte, which went forward to reverse. Where do you see that value and where might you see companies layering on other functionalities of the modern data stack?

There's value for all. I think that's probably the most interesting question in this modern data stack: where does the value accrue? The way I think about it is, one dimension is: what's hard to replicate? Then the other dimension for the end user is: what actually provides the most value?

I think a ton of value accrues at the actual data warehouses that all of this runs on top of, because literally every operation you're doing in forward ETL, reverse ETL and dbt is money for Snowflake and Redshift -- it's all about that compute cost.

Then later, further in the stack, I think a lot of value will accrue to whatever is the tool that helps you assign semantic meaning to the data. Just because you have all this raw data in one place doesn't make it valuable. You need to be able to draw insight and to structure that information such that people can then act on it. What is doing that? Today, transformation tools like dbt are doing that, if you take the lens of the data team really owning everything end-to-end, but I think also applications that are able to plug into the data warehouse, consume this raw information and then turn that into actionable insights. That's also assigning meaning to the raw data. The tools that are less about moving data around and more about, how do you take all this crude oil and refine it -- I think those refineries are where a lot of the value will accrue.

Permalink

I'm curious how you think about Snowflake, which has Snowplow, and the potential for data warehouses to take over some of that assigning of meaning to data and helping to move data into other tools. What, if anything, is keeping data warehouses from building the reverse ETL that takes over that whole end of the stack?

There's nothing really keeping them from doing that, but it's also not their core competency. You've built a data warehouse, you've built the platform on top of which all these things sit. If I were in their position, I'd just continue enabling other tooling to be built on top of my platform. Ultimately, Snowflake is still getting a cut of the reverse ETL tools, so it's not clear to me why it would be a high source of leverage of their time to do that as well.

There's also a really long tail of integrations that you'd have to build out and maintain if the data warehouse tool started to do reverse ETL. I would think more about, how do I enable other applications and other tooling to continue to be built on top of my platform? Like, innovation core to making the data warehouse itself operate faster, more efficiently, and more cheaply. You’re building the tools for this gold rush around data, so you don't have to be out there digging for gold yourself, because it’s your underlying tool that everyone actually uses to do that.

Permalink

On the topic of the center of gravity shifting, do you have any thoughts on how that might affect the moat of companies like Salesforce, HubSpot, and other systems of record that were previously the center of gravity?

It definitely weakens it long-term. I think it's a much more gradual shift, though. There's now customer data being generated in so many places that's not the CRM, and fundamentally, all of that has started to gravitate towards being stored in the warehouse, so the gravity is shifting towards the warehouse. But at the same time, all of this workflow tooling and all these go-to-market applications are built on top of the Salesforce platform. All the VP of Sales are used to Salesforce. I feel like it is going to take a generational change to eventually get to a place where the fact that all of the data is now centralized in a warehouse is reason for people to stop using Salesforce.

To me, it feels like it is somewhat of an existential threat, and I think they realize it. But it's hard, as Salesforce, to re-architect your entire platform to be built on top of this notion of a cloud data warehouse, especially when all these other vendors have already built tools on top of your own platform. I'm not sure how you go from point A to point B there. Then there's also this inertia around people's habits and workflow and the way go-to-market stacks are already set up, that it's just not going to happen overnight.

You mentioned the defensibility of reverse ETL. What’s your perspective on what the switching costs look like in the space of reverse ETL and other tools that you might associate with it?

I should caveat that. We're not a big company that uses a reverse ETL tool, so I can only infer what the switching costs look like from the experiences of others.

I think that the switching costs are low, but at the same time, the reasons to switch are also pretty low. It's a pretty simple job that you have to get done as a reverse ETL tool, like move data from point A to point B reliably. It's hard to differentiate, so I feel like there's this land grab going on right now with Hightouch and Census trying to grab as many customers as they can, because once you start using a tool, even though it is easy to switch, there's not much reason to switch.

I saw Hightouch recently raised a large growth round, and I'm sure they're going to use that to invest in sales and marketing resources to get out there. But fundamentally, you own the data that you're syncing and the SQL queries. You can just as easily plop that into Hightouch as you can into Census.

Permalink

Is there anything that we haven't discussed that you feel is important to understand this space?

For us as a company, there are some questions around the data warehouse being the center of gravity and this wave of tooling that is trying to be built on top of the warehouse.

But the big wave or macro shift is less about the change in the data stack and the rise of the data warehouse, because that ultimately is a solution. Whenever you talk to founders, they always say, "Fall in love with the problem, not the solution." The big shift that we're bullish on is the shift towards product-led sales and the opportunity to rebuild the go-to-market stack from the ground up, because fundamentally the business processes are different. That requires different tooling, and it requires a different way of structuring your team. We've talked a little bit about that at the beginning of the conversation.

There's so much dynamism in the problem space of product-led sales that that's ultimately what we're really betting on and what we're really excited about. It's less so the whole data ecosystem and how it's changing, even though that is also a huge shift. I think there are just so many interesting problems to solve in this space, and part of the reason is that the underlying foundation around data collection has changed, so there are new ways to solve old problems. But there are new problems to solve as well.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.