WEBVTT

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

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/L4I7WgiEquo.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.800 --> 00:00:14.960
Well, first of all, hi everyone.

s3
00:00:14.960 --> 00:00:21.600
I'm an engineer on the product growth team at Notion and now working on the GTM engineering team.

s4
00:00:21.600 --> 00:00:26.960
A year ago, I would have told you that building a GTM system was a marketing ops problem.

s5
00:00:26.960 --> 00:00:33.520
And today, I think it's one of the most interesting distributed systems problems that I've worked on.

s6
00:00:33.520 --> 00:00:46.320
GTM at most companies involve a spiderweb of tools like what you see here, and they're stitched together by customer notes, proposals, contracts that are passed back and forth.

s7
00:00:46.320 --> 00:00:54.719
Over the last few months, a small team and myself, um, we've been trying to turn this spider web into a unified GTM system.

s8
00:00:54.719 --> 00:01:00.640
We're still in the midst of it, but we've learned a ton that I'd like to share with you today.

s9
00:01:01.039 --> 00:01:03.920
So, this isn't really a new problem.

s10
00:01:03.920 --> 00:01:06.560
We've been wrestling with pieces of it for years.

s11
00:01:06.560 --> 00:01:14.479
Life cycle messaging, product recommendations, sales automations, customer data, and onboarding.

s12
00:01:14.479 --> 00:01:20.560
But the solutions were fragmented because the underlying technology forced them to be.

s13
00:01:20.560 --> 00:01:34.799
Then over the winter break, our CEO Ivan built spent it building a video game and he came back convinced that software engineering could be applied to many problems that were previously unwieldy or too costly.

s14
00:01:34.799 --> 00:01:44.640
At the same time, our ability to execute skyrocketed with agentic technology and the breath of problems we could solve did too.

s15
00:01:44.640 --> 00:01:51.280
the costly, time-consuming, and previously unsolvable spaghetti could now be sorted.

s16
00:01:51.280 --> 00:01:56.000
So, what we found is that GTM had become a systems problem.

s17
00:01:56.000 --> 00:02:00.399
That made us realize we could chip away at this holistically.

s18
00:02:00.560 --> 00:02:06.799
In case you don't know, notion's platform is a collaborative brain for human and agents to think together.

s19
00:02:06.799 --> 00:02:13.920
Over the years, we've evolved into a context layer for your company and AI agents can act on it.

s20
00:02:13.920 --> 00:02:18.879
Notion's business moves between self-s serve growth and sales assist.

s21
00:02:18.879 --> 00:02:23.840
Um, and customers move between these two motions all the time.

s22
00:02:23.840 --> 00:02:34.560
The problem is that customers experience one journey, but internally it is supported by disconnected systems that don't actually talk to each other very well.

s23
00:02:34.560 --> 00:02:41.040
These processes were rife with human error and put a lot of cognitive burden on our teams.

s24
00:02:41.040 --> 00:02:51.040
For example, sales reps are probably not the strongest at managing systems, but their strength is in sussing out human signals during the buying process.

s25
00:02:51.040 --> 00:03:02.319
So, every time they had to context switch between after a call, doing research, drafting follow-up, they were spending less time with our customers and customer problems.

s26
00:03:02.959 --> 00:03:07.360
Most companies have separate systems for sales assist and productled growth.

s27
00:03:07.360 --> 00:03:09.920
And this is actually also true for us.

s28
00:03:09.920 --> 00:03:16.239
Marketing run runs on one set of tools, sales on another, customer ops on a third.

s29
00:03:16.239 --> 00:03:22.000
But all of them are looking at a customer independently and making decisions separately.

s30
00:03:22.000 --> 00:03:29.440
So what we set out to build is a single decisioning system that spans self-s serve growth and sales assist.

s31
00:03:29.440 --> 00:03:36.400
and it can help the customer decide the next step so that everything is cohesive.

s32
00:03:36.400 --> 00:03:43.120
Our vision is for this system to be programmable, proactive and continuous.

s33
00:03:43.680 --> 00:03:47.200
When we started, we were faced with some challenges.

s34
00:03:47.200 --> 00:03:49.440
There was so no single source of truth.

s35
00:03:49.440 --> 00:03:56.239
So customer data was spread across Salesforce, Gong, Outreach, Zoom Info and many more.

s36
00:03:56.239 --> 00:04:02.560
Product usage lived in Snowflake and a decade of the most important context lived in notes and meeting docs.

s37
00:04:02.560 --> 00:04:05.760
Yes, our sales reps do use notion for that too.

s38
00:04:05.760 --> 00:04:15.280
Notion employees were actively using MCPs and their own agents to solve problems already, but they were innovating within their own departments.

s39
00:04:15.280 --> 00:04:20.079
So it was single player mode or you could say here single department mode.

s40
00:04:20.079 --> 00:04:33.759
Marketing built tools for tool uh marketing sales built tools for sales and each tool served a tiny slice of that customer journey and it would make it really hard to create something that was more holistic.

s41
00:04:34.240 --> 00:04:38.320
When we tried to automate across all of that we hit some roadblocks.

s42
00:04:38.320 --> 00:04:44.880
First data quality conflicting systems of records wrong contacts tied to different accounts.

s43
00:04:44.880 --> 00:04:49.040
One bad mapping was enough to lose trust for sales rep.

s44
00:04:49.040 --> 00:04:51.120
Secondly, data latency.

s45
00:04:51.120 --> 00:05:00.240
Every vendor added a hop and this lag was causing us to act on stale data and that meant we were automating on yesterday's world.

s46
00:05:00.240 --> 00:05:04.800
Third, and this is a big one, structured and unstructured data.

s47
00:05:04.800 --> 00:05:13.360
The most important facts about a customer were left in notes like the champion just left or don't contact this customer again.

s48
00:05:13.360 --> 00:05:15.840
Um or they're blocked illegal.

s49
00:05:15.840 --> 00:05:21.759
And so these are exactly the types of notes that help sales rep move forward and decide what to do next.

s50
00:05:21.759 --> 00:05:28.800
And if an automation couldn't see it or process it, it could do something catastrophically wrong.

s51
00:05:29.199 --> 00:05:36.160
So our project team consisted of CX, RevOps, product, engineering, sales.

s52
00:05:36.160 --> 00:05:43.039
And after brainstorming together, we all kept finding the same patterns underneath that complexity.

s53
00:05:43.680 --> 00:05:44.080
Whoops.

s54
00:05:44.080 --> 00:05:45.039
Oh.

s55
00:05:45.039 --> 00:05:47.840
Every workflow could be reduced to four questions.

s56
00:05:47.840 --> 00:05:50.320
What do we know about the customer?

s57
00:05:50.320 --> 00:05:52.160
What should happen next?

s58
00:05:52.160 --> 00:05:54.560
How do we execute that safely?

s59
00:05:54.560 --> 00:05:56.560
And did it work?

s60
00:05:56.560 --> 00:05:59.520
That became our architecture.

s61
00:05:59.520 --> 00:06:01.759
So the system has four layers.

s62
00:06:01.759 --> 00:06:05.759
Know a context layer we can trust about every customer.

s63
00:06:05.759 --> 00:06:09.759
Decide, choose the single next best step for them.

s64
00:06:09.759 --> 00:06:25.840
Third, fire act and fire a concrete action that could be a life cycle email um an inapp nudge or a task handed to a rep and then learn watch what happened and feed it back into the decisioning so that it's a loop.

s65
00:06:25.840 --> 00:06:30.479
But this architecture is missing something important.

s66
00:06:31.520 --> 00:06:37.039
The most important part is that humans and agents are operating on the same loop.

s67
00:06:37.039 --> 00:06:46.000
Concretely, this means that the context needs to be displayed so that humans and agents can read and operate on it together.

s68
00:06:46.000 --> 00:06:50.560
So you can see that they're working in the same system, but they might have different roles.

s69
00:06:50.560 --> 00:06:59.680
Agents do the repetitive work at scale like gathering context, researching, drafting recommendations, and writing artifacts.

s70
00:06:59.680 --> 00:07:06.400
Humans provide the judgment, adding nuance, deciding what to do next, and if a recommendation is correct.

s71
00:07:06.400 --> 00:07:09.520
and owning the customer relationship.

s72
00:07:09.520 --> 00:07:22.319
We found that instead of building an AI layer on top of our business, we designed our architecture so that the agent can operate as another operator within the same system as humans.

s73
00:07:23.039 --> 00:07:28.080
Before we built the system, we made some choices about how we were going to implement this.

s74
00:07:28.080 --> 00:07:33.599
Firstly, we deliberately chose not to let an agent talk directly to a customer.

s75
00:07:33.599 --> 00:07:40.560
For sales assist workflows, humans stay in the loop by default and approve anything the agents do.

s76
00:07:40.560 --> 00:07:42.800
The agents do the busy work.

s77
00:07:42.800 --> 00:07:47.039
That decision that decision also has a security dimension too.

s78
00:07:47.039 --> 00:07:53.520
If a prospect fills out a contact sales form online, we treat that as untrusted user input.

s79
00:07:53.520 --> 00:07:59.520
And so trust boundaries don't break down, especially because there is an agent in the middle.

s80
00:07:59.520 --> 00:08:04.400
Secondly, routing and eligibility became a first class primitive.

s81
00:08:04.400 --> 00:08:07.680
Eligibility used to be scattered in all over the place.

s82
00:08:07.680 --> 00:08:18.720
We had one check or rule in an email tool, another in sales and we pulled that all into one place so that these rules can be consumed across our codebase

s83
00:08:18.720 --> 00:08:35.519
uh product sales engineering and these are like customer segmentations or signal signal definitions and then a single classifier will route what the customer should do and this will actually prevent double sends from our system and create very cohesive communication

s84
00:08:35.519 --> 00:08:45.440
across And last but not least, we decided that it was very important to own the contact layer and we decided to rent everything else.

s85
00:08:45.440 --> 00:08:51.680
Since we are a lean team, we will not build our own email vendor or enrichment services like Clay.

s86
00:08:51.680 --> 00:08:56.880
We use Clay and we believe that we understood our customers the best.

s87
00:08:56.880 --> 00:09:00.959
So we will not um give that away.

s88
00:09:01.360 --> 00:09:04.160
So let's get into what we built.

s89
00:09:04.160 --> 00:09:09.279
The first step was to gather a consolidated view of all of our customers.

s90
00:09:09.279 --> 00:09:13.200
Snowflake, which is our data warehouse, is where we compute this truth.

s91
00:09:13.200 --> 00:09:17.760
We ingest data from all the vendors in our GTM stack to Snowflake.

s92
00:09:17.760 --> 00:09:30.240
We run daily transforms and in some cases real time to produce a small set of modeled versioned entities and these are accounts, contacts, workspaces, eligibility, and facts.

s93
00:09:30.240 --> 00:09:36.720
And this also has clear ownership of what teams or uh tools they come from and like timestamps.

s94
00:09:36.720 --> 00:09:42.240
Dynamob is our key value store and it's where we compute our truth or serve our truth.

s95
00:09:42.240 --> 00:09:50.720
We publish a denormalized key addressable profile that agents can quickly query in milliseconds with no joins.

s96
00:09:50.720 --> 00:10:09.360
We also persist agent uh persisted uh or generated artifacts and these are research snippets, summarized notes, rolling summaries and these unstructured data are also keyed by the same ids so that downstream systems can read all of this in one shot.

s97
00:10:10.240 --> 00:10:18.800
So this data was normalized and of course we brought it into notion so that we could work with structured and unstructured data at the same time.

s98
00:10:18.800 --> 00:10:28.560
So some of the data I showed you in the boxes earlier, there's like product usage data, there's activity log from across our vendor stack, and then we also have like unstructured

s99
00:10:28.560 --> 00:10:36.240
data that like I mentioned that is most important for sales context with research reports and notes.

s100
00:10:36.240 --> 00:10:39.920
And this turned out to be powerful for two reasons.

s101
00:10:39.920 --> 00:10:45.760
First, our internal GTM teams didn't need to jump between many tools anymore.

s102
00:10:45.760 --> 00:10:58.160
They could use notion itself, a tool they were already using to explore context, investigate investigate accounts, answer questions, and they could even take actions like sending to Nooks or

s103
00:10:58.160 --> 00:10:59.920
um sending to outreach.

s104
00:10:59.920 --> 00:11:05.440
This is a tool that they were very familiar with, and they didn't need to open seven tabs anymore.

s105
00:11:05.440 --> 00:11:13.600
Secondly, because we weren't building an AI layer, um humans, workflows, and agents could all operate on the same source of truth.

s106
00:11:13.600 --> 00:11:18.720
In a very literal sense, we are using notion to grow notion.

s107
00:11:20.480 --> 00:11:26.880
The next primitive we decided that we needed was a way to turn customer events into actions.

s108
00:11:26.880 --> 00:11:29.040
The unit here is a signal.

s109
00:11:29.040 --> 00:11:35.760
A signal is a single customer event that's important enough to change what should happen next for a customer.

s110
00:11:35.760 --> 00:11:43.760
Some are userdriven like a customer hitting their a AI limit or maybe they reached out to contact contact sales.

s111
00:11:43.760 --> 00:11:54.480
But some of them are not user initiated at all which are these external signal examples I listed here like company raising funding, hiring signals or shift in their tech stack.

s112
00:11:54.480 --> 00:12:00.160
Those external signals are what allowed us to be proactive instead of reactive.

s113
00:12:00.880 --> 00:12:14.560
So this is the signal service that watches the customer profile, decides whether a single action is available, decides who should own that action, and then it emits a concrete task

s114
00:12:14.560 --> 00:12:17.120
following the architecture I described before.

s115
00:12:17.120 --> 00:12:20.560
And this task could be for a human or an agent.

s116
00:12:20.560 --> 00:12:28.800
If there's a task for sales rep, that actually just lands in their notion database and they can quickly view it and act on it.

s117
00:12:29.279 --> 00:12:38.480
What's what's interesting about the way we built our GTM systems is that if there is no signal about a customer, the marketing component of our system kicks in.

s118
00:12:38.480 --> 00:12:53.839
We have a predictive engine that will recommend product features most relevant for that customer and it will send out life cycle emails and inapp nudges or multi-channel communication to drive a customer towards adoption automatically.

s119
00:12:55.279 --> 00:13:02.800
So diving deep into a small slice of what happens when we decide what action should be emitted.

s120
00:13:02.800 --> 00:13:15.839
Um this is for like the sales workflow and we shadowed our best reps to capture something that was the most repetitive part of our job and encoded it as a durable multi- aent workflow.

s121
00:13:15.839 --> 00:13:26.800
Every signal becomes a workflow on temporal which is something we rent and a single run will touch enrichment web search draft generation and more.

s122
00:13:26.800 --> 00:13:30.560
Each of these is a network call that could fail or rate limit.

s123
00:13:30.560 --> 00:13:45.279
And so temporal lets us focus on writing the sequential logic for our GTM use cases while it will handle the retries, ddupes um and handling and going back to exactly where failures left off.

s124
00:13:45.279 --> 00:13:51.279
and one malformed transcript can't take down the whole batch which was really important to us.

s125
00:13:51.279 --> 00:14:06.320
So an example of a cold outbound signal for us will have a research sub agent do concurrent researches then it'll draft like an email and those emails uh there should be three of them so they're scored

s126
00:14:06.320 --> 00:14:11.519
and then a review agent will pick the highest scoring one and make any updates if necessary.

s127
00:14:11.519 --> 00:14:16.399
And this also operates on a loop um so that the email drafts are improved.

s128
00:14:16.399 --> 00:14:23.680
And then when it's ready, this email draft will land in the sales task that is available for for them to act on.

s129
00:14:23.680 --> 00:14:29.519
Um for more reactive signals after a follow-up call, the Gong transcript will come in.

s130
00:14:29.519 --> 00:14:46.160
Our agent will parse the transcript and then um again it will extract the critical sales medpic data uh metrics economic buyer decision criteria plan and champion and draft a grounded followup for that.

s131
00:14:46.160 --> 00:14:52.800
Every LLM step is traced so that we can evaluate quality and improve over time.

s132
00:14:53.600 --> 00:14:59.040
The third layer is what turns this automation into a system that self-improves.

s133
00:14:59.040 --> 00:15:05.839
Every action is a decision log and every outcome threads back to the decision that caused it.

s134
00:15:05.839 --> 00:15:13.199
So the naive version of this is a data analyst coming in and trying to understand if the output of this could be better.

s135
00:15:13.199 --> 00:15:25.279
The rebuilt version of this is wiring our engagement history back into the decision layer so that the system decides whether or not to continue a thread, advance to the next step or pivot.

s136
00:15:25.279 --> 00:15:31.199
The system will continue to do that with the life cycle message performance history as well.

s137
00:15:31.199 --> 00:15:38.959
So these verification loops are really critical so that the system can self-heal and continuously improve.

s138
00:15:38.959 --> 00:15:43.199
Let's see how an agent and human work together in this shared customer view.

s139
00:15:43.199 --> 00:15:51.519
In the customer view, a rep can come here and see the product usage, the recent activity and get an answer using that same data.

s140
00:15:51.519 --> 00:15:57.519
They used to find all of this across many different tabs and now they can just come here each day.

s141
00:15:57.519 --> 00:16:04.160
The rep can ask an agent and the agent will reply uh querying our context layer.

s142
00:16:04.160 --> 00:16:14.079
We can also use notion custom agents which are sharable across companies to access this data context for recurring automated workflows.

s143
00:16:14.800 --> 00:16:25.120
In the task view, a rep starts their day with an already prioritized task box and they already know how to move forward with accounts and contacts.

s144
00:16:25.120 --> 00:16:31.519
And the email draft for an outreach task is already pre-ressearched and available for them to review.

s145
00:16:31.519 --> 00:16:42.240
The human is still in the loop and actually adds their own judgment and taste um and sales secret sauce, but they're no longer starting from a blank sta slate.

s146
00:16:42.240 --> 00:16:46.480
And this does more than one help one rep be productive.

s147
00:16:46.480 --> 00:16:50.800
Um our goal is actually to raise the floor for the entire team.

s148
00:16:50.800 --> 00:17:06.720
So a Neil sales rep coming in, they can learn the notion sales process, understand what signals are important to look for, um, understand which playbooks are effective, and basically know what good followup looks like.

s149
00:17:06.720 --> 00:17:15.760
Reps who can are ramping can still learn from the patterns of the strongest reps without needing every lesson to be passed down manually.

s150
00:17:16.480 --> 00:17:22.400
So, one of the questions that we came across along every step of the way is a classic question.

s151
00:17:22.400 --> 00:17:25.039
Do we build or buy?

s152
00:17:25.039 --> 00:17:29.120
And it's very tempting and trendy to say build everything.

s153
00:17:29.120 --> 00:17:37.039
But what we found is that there are still key areas to build and rent access to at every single layer.

s154
00:17:37.039 --> 00:17:41.840
Internal agents are actually cheaper and faster to build than most people assume.

s155
00:17:41.840 --> 00:17:51.679
And so since we have the most data on our con on our data model um we build it there first and then we uh rented the generalizable parts later.

s156
00:17:51.679 --> 00:17:55.039
So for us the build versus buy as a per layer decision.

s157
00:17:55.039 --> 00:18:00.559
We will not build a lot of these tools like orchestration, email, CRM.

s158
00:18:00.559 --> 00:18:02.799
Um vendors do that really well.

s159
00:18:02.799 --> 00:18:07.360
We refuse to outsource the context layer because that's where our edge is.

s160
00:18:07.360 --> 00:18:20.960
a generic tool can't capture all of our esoteric data models or workflows and we do not want that context layer to be something we can't um debug and so as I mentioned before

s161
00:18:20.960 --> 00:18:32.720
that context layer is a notion it's built off of plain markdown a language that agents are fluent in and we have databases and hierarchies that they can navigate easily

s162
00:18:32.720 --> 00:18:41.919
at the same time this is well designed for human um so this is what lets our engineers, agents, and GTM work off the same context.

s163
00:18:41.919 --> 00:18:46.240
And this has all the data synced across sources.

s164
00:18:48.400 --> 00:18:54.400
Ultimately, the reason to see if we can do all of this is to see if we could get a better throughput on deals.

s165
00:18:54.400 --> 00:18:56.080
It's very early for us.

s166
00:18:56.080 --> 00:18:59.120
We're still building this out, but the initial signs are promising.

s167
00:18:59.120 --> 00:19:06.480
In the last 13 weeks, we are already seeing enterprise reps have increased qualification or qualified opportunities.

s168
00:19:06.480 --> 00:19:14.880
And on the life cycle marketing side, users who received contextaware recommendations were 63% more likely to take the next step.

s169
00:19:14.880 --> 00:19:26.960
This is the early days with a lot more features we want to build, but our thesis that us building a single system on no, decide, act, and learn seems to be right so far.

s170
00:19:26.960 --> 00:19:29.039
A few key takeaways.

s171
00:19:29.039 --> 00:19:36.559
um from entering entering this world as an engineer in the last six months is that before you build shadow your best human.

s172
00:19:36.559 --> 00:19:52.240
I talked to many sales reps and when I opened uh when they opened their computers I saw how many tabs and tools they were navigating between and that was a chaos but it was also the spec and so if you encode a mediocre process you get a mediocre agent.

s173
00:19:52.240 --> 00:19:54.559
Start with the most legible workflow.

s174
00:19:54.559 --> 00:19:57.360
That's the one that's documented and repeated.

s175
00:19:57.360 --> 00:20:02.320
And let humans stay in the loop on where there are risky possibilities.

s176
00:20:02.320 --> 00:20:13.039
Model GTM as primitives, entities, context, triggers, actions, eligibility rules, and the alien world becomes a system you can engineer.

s177
00:20:13.039 --> 00:20:19.440
Last but not least, be headless by default and design for agents as operators and not just co-pilots.

s178
00:20:19.440 --> 00:20:27.039
If humans and agents can't read from the same substrate, you're basically building two systems that will eventually drift apart.

s179
00:20:27.039 --> 00:20:30.480
For us, that layer is notion.

s180
00:20:30.640 --> 00:20:36.240
Right now, humans are the primary consumer of GTM data and agents are helping at the edges.

s181
00:20:36.240 --> 00:20:49.679
Soon, agents will become primary first class consumers within the system, moving from drafting to acting within guard rails by creating the best context and substrate for humans and agents to collaborate together.

s182
00:20:49.679 --> 00:20:53.600
Now, you're setting up your team to sprint faster.

s183
00:20:53.600 --> 00:20:59.280
Um, yeah, and feel free to contact me if you guys want to ask more questions.

s184
00:21:12.679 --> 00:21:14.679
[music]