WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=UhCY231d0FQ

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/UhCY231d0FQ.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.760 --> 00:00:13.920
Okay, good morning everyone.

s3
00:00:13.920 --> 00:00:17.080
I'm stoked to kick things off this morning.

s4
00:00:17.080 --> 00:00:29.560
Um, today's talk is going to start off with just a brief look at GTM engineering and what it is, and then I'm going to get into kind of the areas that I consider to be the most technically interesting and challenging

s5
00:00:29.560 --> 00:00:30.880
um, within this space.

s6
00:00:30.880 --> 00:00:33.320
So, GTM is pretty new.

s7
00:00:33.320 --> 00:00:42.640
Um, it's arisen out of a couple factors, but one of the main motivating ones is that GTM teams have kind of realized that it is now possible to ship

s8
00:00:42.640 --> 00:00:45.760
as fast as a product and engineering team.

s9
00:00:45.760 --> 00:00:57.360
And so, the best GTM teams that I work with are generally um, pushing changes to their GTM structure almost at the same cadence that an engineering team might be doing releases.

s10
00:00:57.360 --> 00:01:07.400
And so, at Clari what that looks like is something like this, where every 2 weeks we're pushing new data to our teams, we're pushing new automations, we're of course running new campaigns,

s11
00:01:07.400 --> 00:01:15.280
and we're constantly iterating on the things that we're shipping and trying to keep pace with the speed that is um, that our engineering team is working at.

s12
00:01:15.280 --> 00:01:27.200
So, um, to do this you need a couple fundamentals in place, and in my view GTM engineering at its heart is really about removing the constraints that have historically stopped GTM teams

s13
00:01:27.200 --> 00:01:30.760
from shipping at speed using technology.

s14
00:01:30.760 --> 00:01:33.160
Um, and the role itself has exploded.

s15
00:01:33.160 --> 00:01:48.000
So, um, I would venture to say that most advanced GTM teams are now hiring GTM engineers or looking for this role, and in my opinion it's one of the first roles that actually is an index on the advances that we're making in AI.

s16
00:01:48.000 --> 00:01:58.760
And so, as models have become more powerful, GTM engineers have gained more leverage within their organization and become more valuable, and we've seen tremendous growth in this role.

s17
00:01:58.760 --> 00:02:02.120
So, um I kind of break it down into four areas.

s18
00:02:02.120 --> 00:02:08.960
And what I hope to do with this talk is kind of lightning round go through some of the technical problems and solutions that I see for this.

s19
00:02:08.960 --> 00:02:14.480
If you're not familiar with Clay, we are obviously building infrastructure that kind of attacks these areas.

s20
00:02:14.480 --> 00:02:16.720
But this is not meant to be a sales pitch.

s21
00:02:16.720 --> 00:02:23.680
It's more meant to be if you're an engineer or GTM engineer that's working on these things, some ways to think about how to structure it.

s22
00:02:23.680 --> 00:02:30.160
And then if you're a founder in this space, some of the interesting problems that I think are worth uh tackling.

s23
00:02:30.160 --> 00:02:32.200
So, the first is data.

s24
00:02:32.200 --> 00:02:37.959
And more than most teams within a company, data is the lifeblood of GTM.

s25
00:02:37.959 --> 00:02:49.120
And the core goal that I think we're trying to accomplish with our data is to create a perfect virtual copy of the market, the ideal customers, the accounts and contacts that you're going after.

s26
00:02:49.120 --> 00:02:53.280
So, um most teams start out with something that looks like this.

s27
00:02:53.280 --> 00:02:59.040
You have accounts, which are the companies that you're targeting, and contacts, which are the people that you're going after.

s28
00:02:59.040 --> 00:03:05.519
The problem though that makes this challenging is that accounts at least exist in a state of constant change.

s29
00:03:05.519 --> 00:03:13.000
As an organization, a company might be getting acquired, it might be spinning up new offices, it might be launching new products.

s30
00:03:13.000 --> 00:03:15.200
So, the company itself is always changing.

s31
00:03:15.200 --> 00:03:20.920
In addition, you as the GTM team are doing things that company that is making it change as well.

s32
00:03:20.920 --> 00:03:24.959
So, you're marketing at them, you're selling towards them, you're trying to book meetings.

s33
00:03:24.959 --> 00:03:26.920
That's changing the state of the account.

s34
00:03:26.920 --> 00:03:34.280
And then also, the company itself is hiring people and firing people and doing things that provide signals for you.

s35
00:03:34.280 --> 00:03:39.000
So, as GTM engineers, we need to manage all of this state within our accounts.

s36
00:03:39.000 --> 00:03:44.440
And um we don't have all the data that we need to do this kind of right off the bat.

s37
00:03:44.440 --> 00:03:48.360
So, um this is what a an example from Clay's CRM looks like.

s38
00:03:48.360 --> 00:03:56.360
You can see I have a ton of fields that are simply telling me what state this account is in, whether they're a customer or not, whether they're expanding or churning,

s39
00:03:56.360 --> 00:03:58.640
how big they are, how well they're scoring.

s40
00:03:58.640 --> 00:04:08.080
And so, one of the fundamental things that we need to do is make sure that our records are updated so that we can actively accurately action on what's happening here.

s41
00:04:08.080 --> 00:04:17.880
And so, as a you know, in a brand new CRM or a or a CRM that I'm going into, the first thing that I am doing is actually filling up the account with relevant contacts.

s42
00:04:17.880 --> 00:04:24.640
And then I'm layering in third-party information that is going to help me figure out which accounts to target and which ones are in in market.

s43
00:04:24.640 --> 00:04:37.360
Primarily, I'm looking at the account hierarchy, the firmographics that uh describe how big the company is and so forth, the technographics that describe what technology they're using, and then I'm trying to create signals on top of those accounts

s44
00:04:37.360 --> 00:04:42.080
that are going to allow me to go after that um that company.

s45
00:04:42.080 --> 00:04:49.880
And so, because uh there's a lot of third-party data involved here, we need to actually go out and source and procure that data.

s46
00:04:49.880 --> 00:05:01.640
And within GTM, there is literally hundreds of vendors that you can turn to to um to get the data that you need, but none of those vendors is going to have a complete picture of all the information you you desire.

s47
00:05:01.640 --> 00:05:04.560
And so, the key technique here is called waterfalling.

s48
00:05:04.560 --> 00:05:10.200
This is where I'm going to actually go and look into multiple providers to try to fill in all the information that I need.

s49
00:05:10.200 --> 00:05:17.120
If you see here, if I was just using Forager to get phone numbers for this um this set of countries, I'd only get halfway there.

s50
00:05:17.120 --> 00:05:21.000
So, instead, what I need to do is layer on all of these other providers.

s51
00:05:21.000 --> 00:05:26.080
And that's not only true for phone numbers, but for most the other data points that we care about within GTM.

s52
00:05:26.080 --> 00:05:35.280
And so, either you or the vendor that you're using needs to run evals against these data providers in order to obtain the most accurate information.

s53
00:05:35.280 --> 00:05:44.280
And so, not only do I need to sync in third-party information to my data layer, I also need to incorporate first-party information, and I need to keep that constantly up to date.

s54
00:05:44.280 --> 00:05:49.040
It's also incredibly expensive to update data all the time, especially if you're purchasing it.

s55
00:05:49.040 --> 00:05:50.840
So, I can't just update all the fields.

s56
00:05:50.840 --> 00:05:53.920
I need to kind of selectively choose which fields to update.

s57
00:05:53.920 --> 00:06:01.640
And not only am I pulling information from various sources, but if I'm running a signals program, information that I need is getting pushed to me all the time as well.

s58
00:06:01.640 --> 00:06:09.440
And because I'm using multiple third-party sources, the actual representation of a single account in those different sources is going to be different.

s59
00:06:09.440 --> 00:06:12.720
So, I need to resolve the entities um in between them.

s60
00:06:12.720 --> 00:06:24.240
And so, a great data layer will tackle all of these things and allow me to kind of move on to the more interesting work, but without this, it's really, really hard to execute automated GTM plays.

s61
00:06:24.240 --> 00:06:27.400
So, the next piece that I need to get right is orchestration.

s62
00:06:27.400 --> 00:06:33.640
And this occurs because within go-to-market, there are literally dozens of tools that most teams are using.

s63
00:06:33.640 --> 00:06:40.000
So, I might have a sequencer or a dialer or a bunch of places where my reps are living or my field marketing is living.

s64
00:06:40.000 --> 00:06:46.240
And in most cases, the view of the world that those tools have is different depending on where you look.

s65
00:06:46.240 --> 00:06:51.600
And so, orchestration, in my view, is really the act of keeping all of that up to date.

s66
00:06:51.600 --> 00:07:00.600
And so, what happens to our data model then is I'm um on top of my enriched information, I'm sending emails and calling into my contacts.

s67
00:07:00.600 --> 00:07:04.000
The account is generating events that I need to keep track of.

s68
00:07:04.000 --> 00:07:08.480
And I now need a system to actually plug all of this into my data layer.

s69
00:07:08.480 --> 00:07:20.280
And so, most teams are going to have something that looks like this as their basic stack: CRM, data warehouse, sequencer, a dialer, a note taker for call recording, and some chat interface like Slack.

s70
00:07:20.280 --> 00:07:27.080
However, um I usually see like 10 or 20 or 30 tools that actually these teams are interfacing with.

s71
00:07:27.080 --> 00:07:31.280
And orchestration needs to kind of keep that information up to date.

s72
00:07:31.280 --> 00:07:35.960
The problem with orchestration is um all of these different systems have different data needs.

s73
00:07:35.960 --> 00:07:40.120
So, some systems need kind of like real-time updates one record at a time.

s74
00:07:40.120 --> 00:07:44.520
Other systems are going to need hundreds of thousands of records, maybe updated once a day.

s75
00:07:44.520 --> 00:07:49.600
I might need to schedule updates on a monthly or weekly basis depending on the data I'm using.

s76
00:07:49.600 --> 00:07:52.160
Some data points like employee count change all the time.

s77
00:07:52.160 --> 00:07:55.760
Other data points like headquarters location change very rarely.

s78
00:07:55.760 --> 00:07:59.280
Um and I'm not going to be making updates to all the fields at the same time.

s79
00:07:59.280 --> 00:08:02.680
So I need logic within these systems that helps with that.

s80
00:08:02.680 --> 00:08:10.600
I also need to be able to take a single um system that I'm working with and actually fan its information out to multiple different systems.

s81
00:08:10.600 --> 00:08:15.720
And because I end up with this kind of distributed setup, I also have failures that are happening all the time.

s82
00:08:15.720 --> 00:08:21.000
So this turns into a fairly complex data engineering problem that we need to resolve.

s83
00:08:21.000 --> 00:08:33.840
A classic example of this is um when I'm working with these different systems, usually they are not fully orchestrated, which means that one system is talking to each other while I'm trying to talk to both of those systems at the same time.

s84
00:08:33.840 --> 00:08:43.760
So for example, if you have a salesforce uh connected to outreach or a sequencer, usually that CRM that seek sequencer are syncing independently of your orchestration system.

s85
00:08:43.760 --> 00:08:50.839
And so if you create contacts in your CRM, you actually need to wait for that contact to sync to the sequencer before you can then take action on it.

s86
00:08:50.839 --> 00:08:58.280
This creates some difficult problems where you actually need to introduce things like weights and loops to check if information is ready.

s87
00:08:58.280 --> 00:09:08.200
So Clay, we've iterated on this problem um quite a bit and we've ended up in a place where we are basically taking a graph-based view of the orchestration problem

s88
00:09:08.200 --> 00:09:12.560
with a series of general purpose nodes that are executing various things.

s89
00:09:12.560 --> 00:09:25.880
And so we have nodes that run agents, nodes that make tool calls, nodes that handle our conditional logic, nodes that run code, and then nodes that run effectively this map reduce system to fan out the information and bring it back.

s90
00:09:25.880 --> 00:09:36.000
And so a great orchestration layer will handle all of these and whether you buy it or build it, I think this is like fundamentally the the kind of modern way to set this up.

s91
00:09:36.000 --> 00:09:38.640
Here's an example of this um in in clay.

s92
00:09:38.640 --> 00:09:46.880
And again, you can use other tools for this, but basically I'm going to have some sort of event that kicks off my orchestration, some trigger or some schedule.

s93
00:09:46.880 --> 00:09:49.440
I'm going to then talk to a couple different systems.

s94
00:09:49.440 --> 00:09:57.120
I'm going to combine that information back together, and then I'm going to push it out to different interfaces that, uh, my reps are using.

s95
00:09:57.440 --> 00:10:07.040
Okay, so now that I have a data layer set up and I have my everything orchestrated, I now have this system which is starting to look a lot more complex.

s96
00:10:07.040 --> 00:10:20.720
And if you spend a lot of time in go-to-market, uh, I think this is actually like one of the simplest views of what is happening with an account, where I have multiple signals that are occurring, I have data that needs to be updated, I have actions that my agents or reps are taking,

s97
00:10:20.720 --> 00:10:24.280
and then I have meetings that are happening and feedback that's occurring.

s98
00:10:24.280 --> 00:10:32.840
And so, um, the state of the world today is that we are relying on sales reps in a lot of cases to manually sort through this, but one of the great advances

s99
00:10:32.840 --> 00:10:38.600
in the last year or so is that we can now use agents to take care of all of this context.

s100
00:10:38.600 --> 00:10:45.200
Um, however, if you use agents, you actually run into some of the same problems that you are dealing with if you just use LLMs.

s101
00:10:45.200 --> 00:10:55.920
So, um, in GTM in particular, we are trying to build very long-running agents, agents that run over a course of weeks or months that keep track of the state of an account throughout a deal cycle.

s102
00:10:55.920 --> 00:11:06.640
We also have a high bar for error because a lot of the results of our GTM work is customer communication and getting that wrong can have disastrous con- uh, consequences.

s103
00:11:06.640 --> 00:11:13.960
And then finally, the agents are often doing unstructured work and pushing that into systems that are highly structured like a CRM.

s104
00:11:13.960 --> 00:11:19.640
And so, the the mapping of what the agent is producing is is super important.

s105
00:11:19.640 --> 00:11:28.440
So, the architecture that we've landed on for this that I think is most powerful is an agent that exists for each account and maintains a persistent state of that account.

s106
00:11:28.440 --> 00:11:37.560
It's always going to execute, and because it's executing over a of weeks or months, it's often going to be dormant for most of the time that it's available.

s107
00:11:37.560 --> 00:11:42.120
So, we need to use smart triggers or a heartbeat or something to wake it up.

s108
00:11:42.120 --> 00:11:48.560
And then when it wakes up, it needs to kind of ingest the current context of the account from our data layer and our orchestration layer.

s109
00:11:48.560 --> 00:11:55.880
And because the agent is making decisions for us in many cases automatically, we need to allow for feedback on the agent as well.

s110
00:11:55.880 --> 00:12:06.760
The um cutting edge of doing this is the learning phase where as the agent works on an account or a series of accounts, it updates its own view of what's working.

s111
00:12:06.760 --> 00:12:09.680
Today in GTM, this is not fully solved yet.

s112
00:12:09.680 --> 00:12:18.880
And in fact, the continual learning um effort and the next best action suggestions are kind of one of the cutting edge problems that that we're working on.

s113
00:12:18.880 --> 00:12:22.560
So, here's a look at um a a kind of a basic agent.

s114
00:12:22.560 --> 00:12:26.480
You can see here that I'm pulling in information from a couple different sources.

s115
00:12:26.480 --> 00:12:28.440
I'm using reasoning steps here.

s116
00:12:28.440 --> 00:12:33.760
And then critically, I'm also updating different values in my CRM that are just for the agents.

s117
00:12:33.760 --> 00:12:41.839
So, I always recommend separating the fields that agents are updating from the fields that deterministic systems are updating or that people are updating.

s118
00:12:41.839 --> 00:12:46.360
And to look at a full uh view of an agent, this is a closed loss free awaken agent.

s119
00:12:46.360 --> 00:12:52.320
So, you can see it's talking to Gong, email, CRM, and um my data warehouse.

s120
00:12:52.320 --> 00:12:55.240
And so, it's pulling together multiple pieces of information.

s121
00:12:55.240 --> 00:12:57.960
And this agent is triggered on a time basis.

s122
00:12:57.960 --> 00:13:03.080
So, if if we lose an account, we're not going to kind of like immediately go after that account again.

s123
00:13:03.080 --> 00:13:07.960
We're going to wait for a little bit of time in order to um in order to attack it again.

s124
00:13:07.960 --> 00:13:15.120
So, there's a number of kind of timing and context issues that we have to address when we're building agents for GTM.

s125
00:13:15.120 --> 00:13:19.920
The last step um that that is important here is the actual execution step.

s126
00:13:19.920 --> 00:13:28.640
So, now that we have a data layer that contains the perfect copy of the virtual world, we have an orchestrated system that's um sharing context with all of our systems.

s127
00:13:28.640 --> 00:13:31.760
We have agents that are making decisions and reasoning about what to do.

s128
00:13:31.760 --> 00:13:36.520
We actually need to get in front of customers and execute our messaging.

s129
00:13:36.520 --> 00:13:41.680
Uh unfortunately, uh messaging and execution is one of the hardest problems in GTM engineering.

s130
00:13:41.680 --> 00:13:47.640
Here's a look at some of the um email open and reply rates over time.

s131
00:13:47.640 --> 00:13:52.000
Generally, what we observe is that cold email works less and less well as the years go on.

s132
00:13:52.000 --> 00:13:54.880
This is a trend that's been true forever.

s133
00:13:54.880 --> 00:13:56.720
Look at a snapshot of this.

s134
00:13:56.720 --> 00:14:05.480
Um if you look at the far left here, I actually think these are pretty uh elevated rates for some of these, but the relative differences between these channels is correct.

s135
00:14:05.480 --> 00:14:09.400
So, you know, LinkedIn can be three to four times more effective than cold email.

s136
00:14:09.400 --> 00:14:12.120
Cold calling and cold email are roughly the same.

s137
00:14:12.120 --> 00:14:18.040
And then on the right here, um this is a series of uh statistics from Smart Lead.

s138
00:14:18.040 --> 00:14:20.440
This is across, I think, 20 million emails.

s139
00:14:20.440 --> 00:14:25.160
And so, you can see we've got somewhere between a half a percent and 1% reply rates.

s140
00:14:25.160 --> 00:14:30.800
So, what that means is, of course, if we've got 100 contacts that we're sequencing, maybe one of them will reply.

s141
00:14:30.800 --> 00:14:41.720
And so, that really raises the stakes for agentic execution within GTM because if your agents are doing the wrong things, then you're missing out on the margin, which is where most GTM teams

s142
00:14:41.720 --> 00:14:44.880
are uh are having success.

s143
00:14:45.560 --> 00:14:49.080
The other thing with execution is you have to solve some very human problems.

s144
00:14:49.080 --> 00:14:55.560
So, for example, do you email on behalf of the rep, or do you let the agent do the emailing?

s145
00:14:55.560 --> 00:15:01.880
If you email on behalf of the rep, what that means is like everett@clay.com is actually reaching out directly to customers.

s146
00:15:01.880 --> 00:15:11.080
But, if I do that in the wrong way, or I don't get the replies that I need, that then means that my overall domain reputation is going to suffer for for my company.

s147
00:15:11.080 --> 00:15:15.080
So, a common technique then is to use multiple domains to get in touch with customers.

s148
00:15:15.080 --> 00:15:22.360
But, then if I do that, I actually need to find a way to route responses on that domain back to my main domain so my reps can process it.

s149
00:15:22.360 --> 00:15:23.400
And that's just email.

s150
00:15:23.400 --> 00:15:32.920
There's also multi-channel outreach, which is tricky as well because you then have to, for example, if you get a call connection and a meeting booked on your call sequence,

s151
00:15:32.920 --> 00:15:39.240
you then need to suppress your email sequence and maybe unenrolled someone from a life cycle marketing campaign.

s152
00:15:39.240 --> 00:15:50.440
So, the coordination of the execution of all of this is also a hard problem and also something that we can use agents to to help resolve.

s153
00:15:50.440 --> 00:15:53.280
So, here's a look at one way that that we're tackling this.

s154
00:15:53.280 --> 00:16:03.840
This is a setup for a kind of rep proxied view where we have a bunch of rep inboxes that are connected to our sequencer and we're actually sending that on behalf of reps.

s155
00:16:03.840 --> 00:16:07.480
But like I said, we do this for kind of a portion of our accounts.

s156
00:16:07.480 --> 00:16:14.880
For many of of our accounts, we actually use multiple domains to go after them and then we have to tackle the routing problem.

s157
00:16:15.560 --> 00:16:22.480
So, that was kind of a lightning review of what I consider to be some of the like harder problems within GTM engineering.

s158
00:16:22.480 --> 00:16:31.800
I think if you get these pieces right, you can end up in a place where you're providing a technical foundation for growth that is helping your company achieve incredible results.

s159
00:16:31.800 --> 00:16:42.480
But I think a lot of teams actually overlook some of the harder pieces here and and don't necessarily design around some of the constraints that they have to deal with.

s160
00:16:42.480 --> 00:16:43.960
So, that's my talk.

s161
00:16:43.960 --> 00:16:45.680
You can see me on LinkedIn.

s162
00:16:45.680 --> 00:16:53.640
There's a URL there and looks like I have about 90 seconds for questions if anyone wants to ask anything.

s163
00:16:55.916 --> 00:16:57.916
[applause]

s164
00:16:58.520 --> 00:17:02.040
Any any questions for Everett?

s165
00:17:02.040 --> 00:17:02.640
Raise your hand.

s166
00:17:02.640 --> 00:17:05.080
I can Okay.

s167
00:17:09.520 --> 00:17:18.640
Just uh curious as to what your um biggest challenge is with all these new um, within the org.

s168
00:17:18.640 --> 00:17:24.360
I think one of the harder problems is probably the interface between the human and the agent.

s169
00:17:24.360 --> 00:17:34.280
Like I said, I think the most powerful use of agents within GTM is to act as the reasoning and decision layer for a lot of tasks that a sales rep was previously doing.

s170
00:17:34.280 --> 00:17:42.800
Um, and so you run into a lot of instances where the rep might think that they should do something different or the rep might not know that the agent did something.

s171
00:17:42.800 --> 00:17:59.920
So, um, because ultimately a human still needs to get on a call with a prospect, coordinating the, uh, connection between what the automated systems are doing and what the, um, what the human sales rep is doing and making that work well, I think is probably one of the hardest problems.

s172
00:18:00.760 --> 00:18:04.120
Okay, well, oh, yeah, one more.

s173
00:18:08.040 --> 00:18:09.080
Um, I have a couple questions.

s174
00:18:09.080 --> 00:18:15.360
So, um, GTM engineers are fundamentally software developers that have this, uh, knowledge.

s175
00:18:15.360 --> 00:18:21.680
And, well, my other question is that, uh, this is mainly for outbound or inbound as well is included in this product.

s176
00:18:21.680 --> 00:18:22.560
For everything, yeah.

s177
00:18:22.560 --> 00:18:26.760
So, um, like the orchestration problem is pretty acute in inbound.

s178
00:18:26.760 --> 00:18:28.040
You have to get the routing right.

s179
00:18:28.040 --> 00:18:30.160
You have to qualify the account properly.

s180
00:18:30.160 --> 00:18:35.240
There's usually historical context on inbound that comes in that needs to be, um, needs to be understood.

s181
00:18:35.240 --> 00:18:40.440
So, uh, yeah, this I think GTM engineering covers, uh, covers all of GTM.

s182
00:18:40.440 --> 00:18:45.640
And, uh, if you want to chat with me more about this, I'll just be right outside, but I will hand it to the next speaker now.

s183
00:18:45.640 --> 00:18:47.840
Thank you.