Artwork for podcast RevOps FM
Building a Next-Gen Composable Martech Stack - Niels Fogt
Episode 23 • 13th March 2024 • RevOps FM • Justin Norris
00:00:00 00:44:40

Share Episode

Shownotes

For most of us in B2B, the marketing automation platform - aka "MAP" - is the anchoring piece of technology in the martech stack.

When I was first buying a MAP, there were way more options than today, but generally they all bundled a few core features together — sending emails, segmenting audiences, and creating workflows.

But is there a reason why you need to do your lifecycle processing in the same tool that you send emails with? What does a Martech stack look like where these roles are distributed differently?

Today's guest has answered that question and built an elegant and high-performing composable stack.

Thanks to Our Sponsor

Many thanks to the sponsor of this episode - Knak.

If you don't know them (you should), Knak is an amazing email and landing page builder that integrates directly with your marketing automation platform.

You set the brand guidelines and then give your users a building experience that’s slick, modern and beautiful. When they’re done, everything goes to your MAP at the push of a button.

What's more, it supports global teams, approval workflows, and it’s got your integrations. Click the link below to get a special offer just for my listeners.

Try Knak

About Today's Guest

Niels Fogt is Sr. Director, Automation Solutions at tray.io. He's led and participated in a wide variety of initiatives within growth and marketing. Strong technical acumen. UX roots.

https://www.linkedin.com/in/uxstrategist/

Key Topics

  • [00:00] - Introduction
  • [02:31] - Niels’ journey as a martech architect
  • [06:06] - Challenges with the traditional martech stack
  • [09:13] - Developer mindsets and service-oriented architecture
  • [12:10] - Applying automation capabilities across the organization
  • [14:09] - Components of Tray’s martech stack
  • [15:02] - The role of a customer journey tool
  • [16:07] - Centralized lead processing in Tray
  • [17:23] - Event collection
  • [19:09] - Streaming events into automation tool vs. data warehouse
  • [22:21] - Native vs. custom integrations
  • [29:15] - Benefits of having a workflow layer in Tray vs. in a MAP
  • [32:02] - Economics of using an iPaaS as a workflow layer
  • [34:50] - Composable martech stacks
  • [39:03] - Skillsets needed to operate a composable stack
  • [40:01] - Future capabilities
  • [41:25] - Relationship to business stakeholders

Resource Links

Learn More

Visit the RevOps FM Substack for our weekly newsletter:

Newsletter

Transcripts

Justin:

For most of us in B2B, the marketing automation platform,

2

:

AKA map is the anchoring piece of

technology in the Martech stack.

3

:

When I was first buying a map, there

were way more options than today,

4

:

but generally they all bundled

a few core features together.

5

:

They provided a database for

your lead and activity data.

6

:

They provided a way to segment audiences.

7

:

They send emails, they give

you forms and landing pages.

8

:

And they provide workflow functionality,

the ability to execute if this, then

9

:

that style logic for various things

like your scoring, your data management,

10

:

your pipeline management, and so on.

11

:

So whether you're using Marketo or Pardot

or Eloqua or HubSpot, you're kind of used

12

:

to thinking of all those functions bundled

together, but does it have to be that way?

13

:

Is there a reason why you need

to do your lifecycle processing

14

:

in the same tool that you send?

15

:

And of course there isn't, but what

does a Martek stack look like where

16

:

these rules are distributed differently?

17

:

Today's guest has answered that

question and put it to the test.

18

:

Neils Fogt is senior director

of automation solutions at tray.

19

:

io, where he's been for almost five

years and he's built a composable stack

20

:

and documented exactly how it works

in a really interesting series of blog

21

:

posts on the And one thing I'll say

Niels is I've been thinking about these

22

:

problems for a lot of years, and you

really have put something together.

23

:

That I've thought of a few times,

but hadn't yet seen or done,

24

:

which is a pure workflow layer

that's abstracted from the map.

25

:

And you've done it in a really

thoughtful and well architected way.

26

:

So I'm really excited to dive

into the details with you.

27

:

Welcome to the show.

28

:

niels-fogt_1_02-20-2024_140545: Awesome.

29

:

Thanks for having me, Justin.

30

:

And just want to say a big thank

you for having me on the podcast.

31

:

did have a chance to listen to your

episode on the humans of Martech this

32

:

morning and just really appreciated

the level of depth and of insight that

33

:

you had as you were talking through

how we're all thinking about AI.

34

:

these are all really interesting

technical challenges and speak to me

35

:

and my technical itch when it comes to

working on these kinds of problems and

36

:

understanding I think that affinity

towards looking at these sorts of

37

:

technical problems innovating on

technology is kind of what drove me to

38

:

rethink how we approach the Martech stack

and Anyway, I'm happy to go wherever we

39

:

want to go and talk through that journey.

40

:

But this is definitely

a privilege to be here.

41

:

So thank you.

42

:

Track 1: Oh, thank you so much.

43

:

I really appreciate that.

44

:

And why don't we start with just

like a quick replay of your journey

45

:

as a martech architect, because

I think all of us make decisions.

46

:

In large part, based on our past

experiences, what we've seen

47

:

that's worked and didn't work.

48

:

So, before you came to Trey, were the

sort of tools that you had worked with?

49

:

niels-fogt_1_02-20-2024_140545:

Good question.

50

:

. I actually didn't start super heavily on.

51

:

Ops and rev ops until I got to Trey.

52

:

was always in and around it and always

working closely with ops people, but

53

:

it was not my primary profession.

54

:

So I actually came up in the tech

space through a user experience agency.

55

:

So what we would do is we would,

this was in the lean startup days.

56

:

If you're familiar with.

57

:

When the Eric Ries craze was going

on, we were working with a lot of

58

:

high growth startups who needed

help with user experience design on

59

:

their either through their product

or through their marketing website.

60

:

Going crazy and their needs

are constantly evolving.

61

:

That's the type of work I came up doing

and what I always gravitated towards that.

62

:

Is the technical side of it.

63

:

And so for example, I would

basically be like a product or

64

:

project manager for a UX engagement.

65

:

And we would have inevitably

some kind of technical piece that

66

:

needed to be delivered with that.

67

:

Let's say front end code or

website CMS or something like that.

68

:

And on the background, what I would

be doing is actually can I help

69

:

with Devin, some of that WordPress

side, or can I like, figure out

70

:

how to hack in tag manager here?

71

:

I would, always just find ways to insert

myself into the technical side and

72

:

self taught myself a lot of that stuff.

73

:

So, ended up doing was I went

in house to a company called New

74

:

Relic, basically doing exactly

what I was doing in an agency.

75

:

Setting and inside new relic, which

was a high growth dev tool startup.

76

:

And I got exposed to a lot

of interesting technology.

77

:

So at the time segment came along

and we were using analytics dot JS

78

:

as our data layer, so to speak for

collecting all this clickstream data.

79

:

And we're like, okay, well now we've got

to put it in a data warehouse, right?

80

:

So we got red shift, right.

81

:

And we started putting all that data

into Redshift and they're like, Oh, crap.

82

:

Now what do we do?

83

:

We've got to get it back out.

84

:

So we were doing like reverse

ETL before reverse ETL is cool.

85

:

I like to say and so, Redshift, analytics.

86

:

js, tag manager.

87

:

Those were like where I came up on the

data side and just kind of like, how

88

:

do I pull this all together and use it?

89

:

And then as I.

90

:

Come into more of a

operations role here at Trey.

91

:

I've gotten exposed to the classic MarTech

stack, which when I first got here was

92

:

Marketo and Salesforce and outreach and,

all the sales enablement side, sales

93

:

navigator and sales OS and all this

kind of enrichment vendors, all of it.

94

:

, I'm also, I'm familiar with a lot of

the traditional sort of Martech stack

95

:

and have a really close familiarity

with, I would say like the whole

96

:

data stack that's been evolving

over the last, , six or seven years.

97

:

Track 1: I could really relate to what you

were describing on those projects, like

98

:

gravitating towards the technical, because

I felt very much the same when I first

99

:

started getting into MarTech more broadly.

100

:

And I don't know what it is, but

there's just something about the.

101

:

Oh, this is cool.

102

:

Like I could, stitch these things

together and build something cool,

103

:

almost like playing with toys, but not to

trivialize it and describing it that way.

104

:

But there's something very fun

about making something work

105

:

and stitching it together and

having an elegant architecture.

106

:

So there's a certain scrappiness to

your approach that you described.

107

:

And even though you dent inherited

a conventional stack at Trey, you

108

:

were starting out, it seems like at

new relic with a lot of different.

109

:

So it wasn't like this scary

undiscovered territory, you were

110

:

already exposed to, you know, what these

alternative paradigms would look like.

111

:

So you came to Trey, you've got, your

standard Marketo Salesforce outreach,

112

:

which a lot of us can relate to.

113

:

What were the pain points and what

were the challenges that you were

114

:

experiencing with that design?

115

:

niels-fogt_1_02-20-2024_140545: Yeah.

116

:

So when I first came in, my job was

actually nothing to do with this, right?

117

:

So what they actually wanted me to

do was a lot of what I was doing in

118

:

Heroic, which was like, hey, help

us stand up a PLG motion, right?

119

:

We've never had a trial.

120

:

How do we do that?

121

:

And help us get our web presence up

to snuff and like that sort of stuff.

122

:

But again, inevitably I found

myself gravitating towards

123

:

those technical challenges.

124

:

And so I was talking to our.

125

:

CMO one day.

126

:

And he's look, like we are having all

kinds of data reliability problems, right?

127

:

Whether it's with not understanding what

stage our leads are at in the funnel or

128

:

not being able to attribute all these

programs that we're working on, right?

129

:

We're spending all this money.

130

:

And doing ungodly amounts of paid

advertising events, all the things right.

131

:

And I just don't feel like I can

trust what this data is telling me.

132

:

And yeah, we've got all this great

tooling but you still have to be

133

:

able to orchestrate that tooling and

make everything work and make it work

134

:

consistently in a reliable fashion.

135

:

And so I think it was like a lot

of the classic problems that young

136

:

marketing teams have and young

evolving organizations have, and they

137

:

just needed help perfecting that.

138

:

Now the interesting part was I didn't come

into it with a preordained mindset, right?

139

:

Like I didn't come into it with.

140

:

Okay.

141

:

Well, this is how you solve

that problem on Marketo.

142

:

I just came at it from a more, I don't

want to be snobbish about it, but

143

:

I a first principles like mindset.

144

:

It was like, okay, well, what

are the jobs to be done here?

145

:

What do we actually need to do?

146

:

And with that different perspective,

I started trying chipping away at it.

147

:

And I worked pretty closely with a,

died in the world marketo champion

148

:

who we had employed there who was

also struggling with these problems.

149

:

Like she too was.

150

:

Going I don't know what's happening when

and where, and things are overwriting, and

151

:

I can't seem to quite choreograph things

in the way I need it to choreograph.

152

:

And so we paired together and slowly, but

surely we started building capabilities.

153

:

And so a simple first

version was email validation.

154

:

Like it's really simple and silly,

but every time we get a new lead,

155

:

we need to conduct some email

validation post processing, right?

156

:

And so I built her a little service that

called clear bit risk and never bounce.

157

:

He did some basic syntactical

validation and a workflow.

158

:

And I'm like, here, just call

this through your Marketo program.

159

:

It'll tell you if it's good or not.

160

:

And we started just standing

up these little capabilities.

161

:

And that's how it started.

162

:

Track 1: What I was thinking in some

ways as you were talking was like,

163

:

Oh, this is really interesting.

164

:

Cause like you can solve a lot of those

problems with call it Martech, or map

165

:

native approaches or architectures.

166

:

Maybe the way that you're doing it is

probably better for various reasons.

167

:

Like actually have come around

to that conclusion, or at least

168

:

as a hypothesis, probably too

early to say it's a conclusion.

169

:

But you, Gravitated naturally.

170

:

I think it helps that you're

working at a, at an iPass company.

171

:

So you had those tools available

to you and there's a lot of

172

:

confidence in the tools, but

is a less conventional approach.

173

:

And was there anyone or any company

out there that you were inspired by,

174

:

or you really were just well, like

we need to put this nail into this

175

:

wood and this looks like a hammer.

176

:

And I think, you know, it looks

like a good way of doing it.

177

:

Let's do it that way.

178

:

niels-fogt_1_02-20-2024_140545: I would

say it was probably more the latter.

179

:

If anything, what I've been, was

inspired by was actually New Relic.

180

:

It mostly, I was really

exposed to developer mindsets.

181

:

And how you architect systems.

182

:

At the time we were real big into service

oriented architectures and that was right.

183

:

Break down the monoliths and to more

narrowly scoped services, which have

184

:

a very narrow function and purpose.

185

:

And then by doing that, you can

use them more interchangeably.

186

:

So just that idea was sitting there

in my head of okay, services, right?

187

:

Narrowly scoped.

188

:

I could build services on tray so

I can build a validation service.

189

:

I can build a MQL service.

190

:

I can build a routing service.

191

:

And so all these again, jobs to be done.

192

:

I was like, well, yeah, all

you need is some inputs.

193

:

Right.

194

:

And if you don't bloat it up

it'll be real easy to use.

195

:

. And then now they're like little

pieces that I can then choreograph.

196

:

And so that was really a big.

197

:

influence for how I just thought

about solving the problem.

198

:

We just kept chipping away at it, chipping

away a little bit more, a little bit

199

:

more, and to the point where it's wait a

minute, we just look back and we're doing

200

:

all this work that was previously done

elsewhere here and man does it scream

201

:

like it's like fast, like really fast.

202

:

Like from the time I see a lead until

the time that person's coming out of

203

:

outreach, it's like 45 seconds sometimes.

204

:

No more than 90 seconds

and that's pretty cool.

205

:

And

206

:

not only is it screaming fast,

but like I can, if anybody ever

207

:

has any complaint anywhere, like

I just go straight to the service.

208

:

And I can see exactly what happened when

and where and how many times it's happened

209

:

then go back to the process from there.

210

:

It just really felt

elegant and easy to manage.

211

:

Track 1: I love what you said

about the developer mindset.

212

:

And this is coming from, an English

major who fell into marketing and

213

:

then somehow fell into technology.

214

:

But I picked up a lot of that from

folks like Sanford Whiteman or Jep,

215

:

you also know who have kind of just

modeled a lot of those ways of thinking

216

:

and things like You know, don't repeat

yourself or having like loosely coupled

217

:

services, exactly what you said.

218

:

So it's kind of used to building those

within Marketo, which you can do in

219

:

a way like you can modularize things,

but it's not built to have the same

220

:

level of, let's call it like ability to

orchestrate in a defined way, or probably

221

:

the level of logging that you get.

222

:

Certainly you don't get to see

like a full JSON input and output

223

:

for everything the way you can.

224

:

I

225

:

think in a lot of I pass tools.

226

:

So where you went with it

seems really logical to me and

227

:

I've kind of had the thought.

228

:

You know, you're used to doing it one way.

229

:

And you don't go there.

230

:

niels-fogt_1_02-20-2024_140545: I'm

sure there are a lot of fantastic

231

:

Marketo power users out there, right?

232

:

You just have to know how to use the tool.

233

:

But one of the things I would maybe argue

is that, While things like use cases

234

:

around the bicycle are important and

probably, a first class challenge for

235

:

ops teams to solve, they're not the only

challenge where automation and a service

236

:

oriented architecture can be applied.

237

:

And as you look across there

are use cases in which this

238

:

core, fundamental skillset.

239

:

Is applicable meaning relational

systems, data models, service

240

:

oriented design, understanding

business logic, all that kind of stuff.

241

:

There are many processes which you can

apply that to that once you have that core

242

:

foundational skill set, make you a much.

243

:

Different player in the ops space, right?

244

:

You can impact many more parts of

the business that where they're

245

:

just not getting the love of

those kinds of capabilities.

246

:

Like a simple example is your

community experience, right?

247

:

So everybody's using a Slack based.

248

:

Community experience now where you

have this ability to have this very

249

:

interactive experience for your customers.

250

:

And the capabilities to, connect that

experience to your rev ops systems

251

:

or your product systems can create

some really cool things, right?

252

:

So like we have.

253

:

A very interactive slack community where

we built these various slash commands and

254

:

things that allow our customers to like,

check your user score progress, check your

255

:

education progress, apply a badge so that

all your best power users have a special

256

:

little annotation on their name, right?

257

:

And everybody knows they're the

best one at your tool, right?

258

:

Or , people have a lot

of workflows on trade.

259

:

So look up a workflow by keyword

through slash command, right?

260

:

Like use AI, it doesn't really matter.

261

:

What I'm trying to say is

there are many places in which

262

:

this capability can manifest.

263

:

And when you house it within this really

rigid frame of marketing automation,

264

:

then I think it limits your worldview.

265

:

can do a lot more.

266

:

Track 1: I want to zoom out for a second

and look at your stack as a whole tray

267

:

obviously being a critical part of it.

268

:

But what are the other main components

of your martech stack today?

269

:

niels-fogt_1_02-20-2024_140545: Like

traditional demand gen stuff, right?

270

:

So we have pay all the paid

social lead sources, right?

271

:

You have those we have all

your traditional enrichment,

272

:

like vendors, right?

273

:

So zoom info, clear bit.

274

:

We have event platforms.

275

:

We use zoom for our webinars.

276

:

We use a little bit of event here

and there for some bigger events.

277

:

We have, of course, Trey, right?

278

:

Acting as this orchestration layer.

279

:

We use iterable.

280

:

We use them for journey orchestration

and all the email campaigns

281

:

and all that kind of stuff.

282

:

We use iterable for that.

283

:

And then we have sales OS,

sales navigator, right.

284

:

For all the contact sourcing, that kind of

stuff and outreach for sales engagement.

285

:

Salesforce.

286

:

Track 1: I'm broadly familiar with like

kind of the iterable embraces and in my

287

:

mind, in this like customer journey.

288

:

engagement type of platforms, but in terms

of what parts of what we might think of

289

:

as Marketo functionality that iterable

is taking over and what parts are in

290

:

tray, how would you divide up those kind

of duties between the two platforms?

291

:

niels-fogt_1_02-20-2024_140545: centric.

292

:

Iterable is essentially what I call

journey orchestration, which is.

293

:

Most of your customer facing

communications, ? Usually there's a

294

:

variety of use cases for that, right?

295

:

So you might have a nurture journey

that you take somebody through once

296

:

they hit a certain status within your

CRM, or at least for us CRM you'd have

297

:

like fulfillment type stuff, right?

298

:

So you had some piece of content

that you need to fulfill.

299

:

Right.

300

:

And then you need to deliver that.

301

:

You might have just basic

database marketing stuff, right?

302

:

You have an event coming up.

303

:

You need to segment your

database by a certain, through a

304

:

certain group of people, right.

305

:

And get those communications out and

webinar operations, follow up, all of the

306

:

traditional customer facing journeys is

happening through iterable and then all

307

:

of the lead processing data management

is happening through Trey, meaning,

308

:

okay, from the moment you capture that

lead from any given source could be your

309

:

website, could be your chat platform,

could be your, ad vendor, whatever it is.

310

:

We ingest that through a Trey workflow.

311

:

We normalize the data.

312

:

So we need to then normalize it so

that it fits a common data model.

313

:

Apply things like lead source,

all that kind of stuff.

314

:

And then we run it through

what we call our lead pipeline.

315

:

And our lead pipeline is this sort of

amalgamation of lead processing jobs.

316

:

So the first thing we always do is

run it through email validation.

317

:

Then we run it through a lookup

process to see if we have that

318

:

record in our CRM already.

319

:

If we don't, we enrich it, create

it, lead to account match it.

320

:

Run our attribution process, which is

basically just stamping the dates and

321

:

stuff on the life cycle objects and

putting campaign memberships in place.

322

:

And we run it through an MQL process.

323

:

And the MQL process is

like, Hey, are you an MQL?

324

:

Yes, you are.

325

:

Okay, then route it.

326

:

Right?

327

:

All that sort of end to end

journey is happening on Trey.

328

:

And then there's always the ongoing

stuff of are we constantly making

329

:

sure we understand where somebody is

at in the funnel and progressing them

330

:

through automation so that we all, run

our reports and intelligence on, how

331

:

everything's working and where people

are standing, that's always up to date.

332

:

Track 1: I'm thinking of MQL and I'm

thinking as you're talking, all right,

333

:

there's that initial processing flow

and then potentially somebody comes in.

334

:

They're not an MQL yet.

335

:

Maybe you have a concept of an MQL

threshold, which is based on points or

336

:

an accumulation of activity, and it made

me think about where's that activity

337

:

layer like the piece that's tracking you

visited these web pages and then maybe Me.

338

:

You know, assigning some points to that.

339

:

Is Iterable responsible for

that, or do you have a separate

340

:

event collecting system?

341

:

niels-fogt_1_02-20-2024_140545:

Yeah, so we use analytics.

342

:

js.

343

:

You can think of it like munchkin.

344

:

So,

345

:

Segment provides analytic.

346

:

js.

347

:

So we collect all of our sort of

clickstream behavioral data through

348

:

segment, and that includes the

page view data, the form submit

349

:

events, all those sorts of things.

350

:

And so we can essentially listen for

those events through Trey, and then we

351

:

can action upon those events, whether

that be for changing data values or

352

:

trigger orchestrating some kind of like

internal action or external action,

353

:

we can just listen to those events.

354

:

Track 1: Are you streaming those

events also into a warehouse or

355

:

something, and simultaneously into Trey?

356

:

And

357

:

niels-fogt_1_02-20-2024_140545:

So segment has a native Redshift,

358

:

Track 1: get

359

:

niels-fogt_1_02-20-2024_140545: pipeline.

360

:

So they're constantly keeping up our

different segment sources that are

361

:

collecting all this behavioral data

and pushing it into Redshift and then.

362

:

They're all the data team will have like

jobs that sit on top of that to basically

363

:

amalgamated, you know, data and it's for

all form isn't always the most useful.

364

:

Sometimes you need to aggregate it and

create views on top of it to make it more

365

:

consumable for some system or process.

366

:

Track 1: Independent event collection

and storage, and then making those

367

:

events accessible to other tools.

368

:

There's a lot of debate around what's

that order of operations look like

369

:

and potential latency and, so you've

made the decision obviously to stream

370

:

it to, both places, which is the one

that makes the most sense to my mind.

371

:

Presumably you considered at least

the option perhaps of sending it to

372

:

Redshift and then pulling from Redshift.

373

:

What made you not go in that direction?

374

:

I guess, what were the disadvantages

if you did consider that?

375

:

niels-fogt_1_02-20-2024_140545: Well, for

the most part most of our needs are met

376

:

through this event driven architecture.

377

:

And we don't have like crazy

complex scoring and point systems

378

:

and those sorts of things.

379

:

Actually, we tried it and

we basically decided it was

380

:

this sort of like subjective.

381

:

Assignment of value that like, drinking

a lot of Chris Walker Kool Aid these days

382

:

where like he has this point of view on

your declared intent or high intent, like

383

:

leads being your most valuable leads

and this idea that like we have this,

384

:

weird subjective view of Oh, well, if you

viewed two pages and you like downloaded

385

:

an ebook, like that makes you qualify.

386

:

That's the ticket.

387

:

Right.

388

:

Maybe we're over complicating this idea

of this whole MQL in sort of a stick your

389

:

finger in the air kind of methodology.

390

:

And what we really need to do is like

optimize for a great experience on your

391

:

high intent leads, which can be basically

done through an event driven system.

392

:

Right.

393

:

In my opinion.

394

:

And then there are better ways

in which to surface the right

395

:

people to talk to sales and the

experience that you should give them.

396

:

So, in that regard, we're okay with more

latency essentially is what I'm saying.

397

:

Like you don't need this real time scoring

routing kind of thing for the people

398

:

who are not declaring their intent.

399

:

And so that's why we're okay

with essentially pushing

400

:

things to the warehouse.

401

:

And by the way, we're not perfect here.

402

:

Like we're still in this process of how

do you basically take this first party

403

:

data set that you have and provide sales

with a good subset of people in which

404

:

to prioritize and use the correct motion

with those people, because they're

405

:

not saying to you, I want to talk to

you right now, right here, right now.

406

:

And so as long as we can get the

high value leads through real quick.

407

:

We're okay with a little bit

of latency on the backside.

408

:

Track 1: So those events, it sounds like

are mainly like form fills of specific,

409

:

like what I would call hand raised forms.

410

:

And then for iterable, does it sit

on top of the warehouse or does it

411

:

sit on top of CRM from an integration

point of view or a combo of the two?

412

:

niels-fogt_1_02-20-2024_140545:

It mostly CRM, right?

413

:

So most of the data that we need for

segmentation purposes is written to CRM.

414

:

And then I built a custom sync

between, cause they don't offer an

415

:

out of the box Salesforce integration.

416

:

So I built a custom sync on tray to

basically push that data between them.

417

:

And then we have a handful of custom

events that basically act like program

418

:

member triggers So like anytime we

apply a person a campaign membership

419

:

to a person in salesforce we listen for

that through tray and then we emit an

420

:

iterable event which gives you program

membership triggers Like that's the

421

:

campaign membership triggering process.

422

:

Track 1: Let's talk about

integrations a little bit.

423

:

Cause one of the.

424

:

And I think one of the pieces that

you focused on a lot in your blog

425

:

post series was moving away from

native integrations and using Trey

426

:

as this primary integration hub.

427

:

And I was curious what the benefits

of this are from your point of view.

428

:

We all have seen some limitations to

native integrations on the plus side,

429

:

like they are a lot more out of box and

presumably there are a lot of things

430

:

like error handling and that sort of

logic kind of built in to some of these

431

:

integrations, at least ostensibly.

432

:

That, , otherwise, you have

to rule your own, which can

433

:

be daunting for some people.

434

:

What influenced that decision,

as you were building this out?

435

:

niels-fogt_1_02-20-2024_140545: It

mostly came from Necessity, right?

436

:

So we had a belief that best in

breed tooling is how we want to go.

437

:

We have a belief that we can own

our own process in a way and make

438

:

it work in a way that we want to

work by taking this approach, but

439

:

the truth is do have a connectivity

issue at that challenge, right?

440

:

Just like we were saying

with Bitterable a minute ago.

441

:

Like they don't offer a

native Salesforce integration.

442

:

So that's a problem that we have to solve.

443

:

So I'm not against native

integration by any means, right?

444

:

if it's going to do the job that it

needs to do and save me the cost of

445

:

ownership, please, I will take it.

446

:

Because we have the capacity to look at

these problems a little bit differently.

447

:

I don't have to put up with the

shortcomings of those integrations.

448

:

And so that's what generally drives it.

449

:

It's sure.

450

:

We could use that, but then we

compromise that last 10 to 15

451

:

percent where it's falling short.

452

:

Right.

453

:

And so rather than build around

those problems and, you know, try to

454

:

explain those problems to somebody

who just doesn't get it, right.

455

:

Like we just simply have decided

that we don't have to do that.

456

:

And nine times out of 10, it's not

this crazy complex integration problem.

457

:

It's usually just a few

small things that are.

458

:

Causing it to be non ideal, right?

459

:

When you have those hard skills around,

well, okay, I understand webhooks.

460

:

I understand the APIs.

461

:

I understand basic data

mapping and transformations.

462

:

You could actually close

those gaps really easy.

463

:

You just have to have those

hard skills to be able to do it.

464

:

So it's just come out of, okay,

we have those hard skills.

465

:

We know what the gaps we need to close.

466

:

Let's just close them and move on.

467

:

Track 1: One of the experiences

I've had building Kind of a native

468

:

integration equivalent process.

469

:

And I pass was with Trey.

470

:

It was a different one, but similar

sort of logic and workflows.

471

:

It's definitely achievable

was my observation.

472

:

You're a lot more experienced than me

in this domain, but you quickly realize

473

:

like some of the things that you take

for granted, for example, like preventing

474

:

infinity loops, where you have something

like this recipe or this workflow triggers

475

:

off an update in this system and makes it

up and that makes an update, but then this

476

:

workflow triggers off an update in this

system and then they start ping ponging.

477

:

And so then now I have

to solve that problem.

478

:

And you're like, oh, but what

if something is updated in

479

:

both places at the same time?

480

:

Now I have to do like field level

comparison and resolve conflicts and

481

:

just things that you don't really realize

are happening under the hood in a normal

482

:

integration, when you actually have to go

and build it out, you kind of appreciate

483

:

that, oh, it's doing a lot for me.

484

:

How have you thought about solving those

things within your architecture or have

485

:

you built it out in such a way that you

could sidestep some of those problems?

486

:

niels-fogt_1_02-20-2024_140545:

Yeah, there's not an easy answer.

487

:

So first of all, I would argue that

those problems you're articulating are

488

:

actually probably happening already

in your native integrations, and you

489

:

probably don't realize it, or at least

you only hear about it episodically.

490

:

And a lot of things are

black boxy, so to speak.

491

:

So, just because a native integration

does solve some of those problems,

492

:

doesn't mean they've solved all the

problems and it's perfect, right?

493

:

These are all highly relational

systems and the more things that

494

:

are interfacing with those systems,

be it native integrations or custom

495

:

integrations or whatever it is, there

is this ping pong effect happening.

496

:

Toe one extent or another.

497

:

So almost certainly everybody's dealing

with this problem, it's just more that

498

:

you're less aware of it when you're

not on the front lines dealing with it.

499

:

Track 1: We're all just sitting with

our head in the sand, blissfully unaware

500

:

niels-fogt_1_02-20-2024_140545: yes,

501

:

Track 1: of all these issues.

502

:

niels-fogt_1_02-20-2024_140545:

or aware, not

503

:

having much bliss at

504

:

all.

505

:

Track 1: Yeah, or the

opposite of blissfully.

506

:

Painfully unaware,

507

:

niels-fogt_1_02-20-2024_140545:

What I would argue is like when you

508

:

own some of this and you literally

have the process level visibility

509

:

when somebody goes, Hey, I see this

problem why did I get this link?

510

:

You go specifically to the metal

where you see exactly where it

511

:

happened, exactly when it happened.

512

:

And you can to that specific

situation, then you can solve it.

513

:

Otherwise you're beholden to

the level of observability

514

:

that you have on that system.

515

:

So I'd rather at least know where my

problems lie and that I can fix them.

516

:

Then not know,

517

:

Track 1: Do you believe in keeping a

kind of intermediary source of truth

518

:

between two integrated systems so that

like you kind of dump changes from one

519

:

system in here and dump the other ones

and then you kind of have this neutral

520

:

place where you can sort them out?

521

:

Or have you found that just like two

point to point integrations, you're able

522

:

to build the logic in such a way that

works an acceptable amount of the time?

523

:

I'm going to use the marketo integration

as an example, but my understanding

524

:

of how it works is it's taking all

the changes from the marketo side

525

:

during any particular sync interval,

and then taking all the changes from.

526

:

The Salesforce side and

then it's comparing them.

527

:

Cause if you just think from point

to point, it's kind of like blind.

528

:

It's I have this, I go over there and

you have this and you go over here.

529

:

And there's other systems out there

that I've seen that less pure I

530

:

pass systems, but maybe like Synchry,

for example, that maintains this

531

:

sort of independent, neutral data

store in the middle for integration

532

:

purposes, which I think makes sense.

533

:

Like it does answer a lot of those

challenges, or you could just use

534

:

a Snowflake database or a Redshift

database of your own in the middle.

535

:

niels-fogt_1_02-20-2024_140545: I'm sure

there are circumstances where the level

536

:

of complexity between two systems like

MAP and CRM and the sort of throughput.

537

:

Let's say going through those two systems

is sufficient that you need a much

538

:

more sophisticated layer of triaging

conflict and resolving some of the

539

:

issues that you've articulated, but in

our particular case, it hasn't become a

540

:

big enough of a problem and that we've

needed to resolve those conflicts.

541

:

And that's not to say that

means It's not a perfectly valid

542

:

challenge that people have, right?

543

:

I think is given that we are able to

kind of standard on Salesforce as our

544

:

source of truth and move out from there.

545

:

We've not hit some of

those traditional snags.

546

:

Track 1: That makes perfect sense.

547

:

I want to dive back into your

lead processing workflow,

548

:

and you've given a high level

overview of how it works so far.

549

:

Most people as we've talked about, handle

those functions in the map and in like

550

:

my Mariketo instance right now, I have.

551

:

A lot of those services that you

described built out, but they're

552

:

just like little brown program

icons, like enrichment, MQL, scoring,

553

:

works pretty well.

554

:

I can orchestrate them.

555

:

Our needs are not like

hugely complex at this stage.

556

:

But you've moved all

those functions into Trey.

557

:

You don't need to convince me of the

benefit of doing that because I've

558

:

seen the power that having a dedicated

workflow layer brings, but From your

559

:

point of view, what are you gaining

from going there that you couldn't

560

:

have just built into Marketo perhaps?

561

:

niels-fogt_1_02-20-2024_140545: Probably

a few things like I gained confidence.

562

:

I feel very confident using Trey, right?

563

:

And I can like.

564

:

I can absolutely tell you two

decimal places, how often any one

565

:

of those processes ever go awry.

566

:

I get notified if anything's

going wrong, instantly, basically.

567

:

So, to me, having that level of

comfort and confidence to know

568

:

exactly what happens when and where.

569

:

And where to go to fix it is

huge for me just from pure nuts

570

:

and bolts, ops perspective.

571

:

I'd say the other thing, if I just kind

of take a step back and think about

572

:

us as an organization we have a lot of

leverage in our marketing stack, right?

573

:

= Because.

574

:

I have such an ability to

evolve my process quite easily.

575

:

I don't have to have as much technology

in our stack, I have a lot of leverage

576

:

and vendor conversations, right?

577

:

Because it's a job to be done,

which is the process orchestrates.

578

:

And if I find that one vendor happens

to be better than the other, I'm not

579

:

constrained by all of these more rigid.

580

:

connections between those systems.

581

:

So that ability to have leverage

and flexibility and how we approach

582

:

our technology stack is quite nice.

583

:

And the other thing that

we gain is speed, right?

584

:

I mean, this thing is just fast, right?

585

:

And I love.

586

:

Knowing exactly how long something

takes and if I need to deal with a

587

:

huge amount of throughput, suddenly

I can do that and it's not a problem.

588

:

We can do it really fast.

589

:

So let's say those are

some of the main things.

590

:

Track 1: Make me jealous while

you're talking because I don't

591

:

have, what I would consider a really

robust workflow tool right now.

592

:

We have Zap here, but, it's

certainly not as powerful, let's say,

593

:

as some of the other options that

I've used in the past or for Trey.

594

:

And the freedom that it brings to know

when this thing happens over here,

595

:

that I can go over here and update this

data value, and there's this power and

596

:

control, as you're saying, that you have.

597

:

It's so liberating.

598

:

It's one of the reasons why I

really fell in love with that

599

:

category, for what it can do.

600

:

People that don't have that,

I think, don't know what

601

:

they're missing, number one.

602

:

But it also made me curious, as

you were describing what you can

603

:

do, You, I'm assuming, have a

fairly unmetered version of Tray.

604

:

And you mentioned at one point, I

remember when you first brought this up in

605

:

conversation, this design of your stack.

606

:

There's cost savings involved.

607

:

From a real world economic perspective,

if I was to become a Tray customer

608

:

and how did the economics shake out?

609

:

Because different vendors

price in different ways.

610

:

Some price per task,

some price per workflow.

611

:

Am I saving money at the end of the day,

do you think, or am I going to be forced

612

:

to constrain myself in a different way?

613

:

. niels-fogt_1_02-20-2024_140545:

So we're a consumption model,

614

:

meaning we build off of tasks.

615

:

We don't believe that a workflow

based model is the right mentality

616

:

because it doesn't fit with our

philosophy that you want this

617

:

service oriented architecture, right?

618

:

Like you want to be able to build

a process, whether or not that

619

:

process runs a couple of times a

day or a million times an hour,

620

:

should build.

621

:

A smart architecture that handles

your processes in the most efficient

622

:

and manageable way possible.

623

:

And we think that when you put like

billable constraints on things like

624

:

workflows, essentially people don't

solve problems, so we want to tie the

625

:

consumption of the platform to the cost.

626

:

I do think that there's true

savings that you can have,

627

:

cause I don't own a lean data.

628

:

I don't own a marketo.

629

:

I don't own a lot of tools that you

may have to pay a lot of money for.

630

:

So, what that exact number is I

don't want to pretend that I can give

631

:

everybody a really clean answer on it.

632

:

And you do have a cost of ownership

with this model, to your point, right?

633

:

Where you're building certain things.

634

:

So to me, do think there are cost

savings in there, but probably the

635

:

better mindset to have about it is the

level of flexibility and capabilities

636

:

that you're able to bring to your

organization and solve problems in

637

:

a much faster and efficient way,

638

:

so you don't have to have this

straight jacket around you where

639

:

you're trying to operate within the

constraints of that straight jacket.

640

:

Like I can build my stack in the way

I need to build it and make it work

641

:

the way I need it to work, which

allows me to help our organization

642

:

facilitate, rapid change faster,

643

:

we're all talking about AI now, how are

we going to get AI into our process?

644

:

And we're worried about governance

and we're worried about security

645

:

and we're worried about, how do we

use our first party data and these

646

:

models and all this kind of stuff.

647

:

Right.

648

:

Well, I would argue that when you have

a capability like this to build your

649

:

processes in a way, then you can take

new capabilities like AI and you can bring

650

:

them into your process much more easily.

651

:

And so to me, indexing on that agility and

the ability to do what have your stack, do

652

:

what you need to do for your organization

is just as important as saving, you know,

653

:

five figures on your vendors this quarter.

654

:

Track 1: You mentioned the humans

of Martek podcast and my friends,

655

:

Phil and John over there, they've

talked a lot in some of their

656

:

episodes about, composability

and creating a composable CDP.

657

:

And it's one of those

words that's very much.

658

:

In Vogue right now.

659

:

Were you thinking about composability

when you were designing this?

660

:

Or do you see your stack as

falling under this label?

661

:

Or so happened that you've

approached it in that way?

662

:

niels-fogt_1_02-20-2024_140545:

It's absolutely a composable stack.

663

:

If it doesn't meet the definition, then

I'm not sure what does . The whole idea.

664

:

Is that you can take these core services

or jobs to be done and orchestrate

665

:

and use them in the way that you

need to this idea of abstractions.

666

:

It's nothing new per se, we were

talking at the start of the call about.

667

:

Analytics.

668

:

js or segment, right?

669

:

Like they came in with an abstraction

layer to instrumentation so that we can

670

:

move event data to either point solutions

or your data warehouse quite easily and

671

:

not have to go through that process for

every new tool we bring into the stack,

672

:

This idea of abstraction has been.

673

:

Going on for quite a while.

674

:

To me, what we're now getting into

is kind of had this initial sort

675

:

of data layer abstraction happening.

676

:

And you have in the sort of

cloud data warehouse, right?

677

:

Consuming that and acting like its

own abstraction layer your workflow.

678

:

Version of this is just another version

of abstraction and composability right

679

:

where we're now you're creating these

capabilities that can be just like

680

:

those other tools they can be used in

a fashion that gives you The flexibility

681

:

to decide when and how they're used.

682

:

Track 1: It seems that there

is an increasing trend towards

683

:

companies designing these sorts of

point tools microservices and they

684

:

all kind of come up in that way.

685

:

And at the same time, though, there

is an increasing economic pressure

686

:

in the marketplace for companies

to consolidate functionality.

687

:

And I think we see this in lot

of the sales engagement space

688

:

where we have the gong and the.

689

:

Sales loft and, you know, various

tools like that starting to try

690

:

to eat each other's lunch from

various angles and acquiring

691

:

tools and bringing them together.

692

:

And, , there's reasons that it's

easier for budgetary purposes

693

:

for companies to do that.

694

:

Or you have the HubSpot is maybe

the perfect example where they're

695

:

like, we'll just build one of

everything, we're just going to build

696

:

it and it's all going to be one.

697

:

Huge monolithic stack.

698

:

Do you see both of

these models coexisting?

699

:

you see the future as one in where there's

just like this endless diversity of point

700

:

services and then orchestration tools that

bring them all in these wonderful ways?

701

:

What does the future look

like from your point of view?

702

:

niels-fogt_1_02-20-2024_140545:

I don't think it's a endless sort

703

:

of amalgamation of point services.

704

:

At some point, there is going to be

some benefits to taking certain more,

705

:

let's call it more broad platforms

and Leveraging whatever capabilities

706

:

those platforms have if it makes a

lot of sense for your business and

707

:

it does what it needs to do, and

there's less overhead for you, right.

708

:

And running that model, then

run that model that is okay.

709

:

There's nothing wrong with using a

really smart set of tools to do the

710

:

core jobs to be done that need to

be done, like we don't need to just.

711

:

For the sake of composability, right?

712

:

To develop a composable stack.

713

:

That's definitely not

the mindset I would take.

714

:

I think it's just more so that

having the ability within your

715

:

four walls of your organization to

cross that line when you need to.

716

:

Is a capability that we should be

prioritizing for our ops functions

717

:

. Meaning this is a critical skill set

for operations teams to have within

718

:

house, so that when that platform

doesn't do what you need it to do.

719

:

You can make the changes that you

need to make and are not beholden

720

:

to the constraints of that system.

721

:

And, That is where you use it, right?

722

:

And that's a always evolving thing.

723

:

Our stacks are constantly evolving.

724

:

The vendors of today are going to get

beat by the vendors of tomorrow, right?

725

:

And we want the ability to be

able to move with that change.

726

:

And so in order to do that, you have to

have these competencies in house, because

727

:

otherwise don't control your destiny.

728

:

Track 1: So speaking of the ever

evolving state of things, . What are

729

:

the, to do list that you're like,

yeah, I got to fix that someday.

730

:

Are there still some rough

edges here and there?

731

:

niels-fogt_1_02-20-2024_140545: One of

the harder things is what we've been

732

:

talking about is like, do we Make sure

that we can continue to run this practice.

733

:

So one of the harder things is just

teaching people the hard skills, right?

734

:

Like I've learned that there's

a certain profile of operator.

735

:

I need to have underneath our roof who

has the right sort of skill sets to

736

:

be able to run this sort of practice.

737

:

So early on.

738

:

For example I was probably not looking

at the right types of individuals

739

:

when the right types of skill sets

because is a more technical challenge.

740

:

Whereas maybe you may have brought

in more junior practitioners, for

741

:

example, as part of an ops function,

you can't execute this model with a

742

:

junior practitioner who doesn't have

a good systems architecture mindset.

743

:

So that's been a challenge that I've

learned just like, how do you find the

744

:

right skill sets to run the approach.

745

:

And then as far as areas for evolving

the system I don't have this major

746

:

thing that stands out where it's

just Oh, we absolutely have to fix.

747

:

I don't know, our lead scoring

approach or something like that.

748

:

I've been running it for

probably three and a half years

749

:

now . And so it's pretty mature.

750

:

So what we're actually more so

thinking about is, what is next in our

751

:

Inside of our house of capabilities.

752

:

And so we're doing the

trendy stuff right now.

753

:

Like, how do we actually understand

where we can apply AI in, inside of

754

:

our organization to do like the things

you guys were talking about on humans

755

:

and MarTech, like how do we take

less structured data and what are the

756

:

technical underpinnings that we need

to have in place to be able to consume

757

:

that and make it operationally useful.

758

:

For our organization, kind of skill

sets in services do we need to have in

759

:

place to do that in a way that security

is also going to be like, that's cool.

760

:

You're allowed to do that.

761

:

And it's also useful and

functional for the business.

762

:

So one thing we've been doing right now

is building a service around our all

763

:

of our sort of knowledge content of how

we consume that Put it into a vector

764

:

database, create a service that, we can

then use with our knowledge content and

765

:

then use that for both internal enablement

use cases and customer facing use cases.

766

:

Track 1: Chat GPT that's

trained on your own docs or

767

:

your own data kind of scenario.

768

:

Maybe last question I'll ask

is in terms of the evolution of

769

:

this and how you evolve it day

to day, what's your relationship

770

:

to your business stakeholders?

771

:

Is it you coming up with

ideas or presenting them?

772

:

Are they coming to you with requests?

773

:

Is it more of a product management style?

774

:

How do you triage and

roadmap these things?

775

:

niels-fogt_1_02-20-2024_140545: Pretty

much like any classic ops team, right?

776

:

So like I am a business partner to

other parts of the organization.

777

:

I report to our CMO.

778

:

And so, a lot of what we're doing

right now is just ensuring that we're

779

:

facilitating the go to market strategy

that he's laid out for the organization.

780

:

And we were in a as an organization, a

bit of a transformational period, where

781

:

we're shifting our go to market strategy

a fair amount, which requires that you

782

:

got to reevaluate all the things that were

tied to the old go to market strategy.

783

:

And so just like any other ops team,

like we'll hear the challenges that

784

:

he is putting forth for us to change,

and then we create a roadmap and we

785

:

prioritize that we work with our same

thing with our sales leaders, right.

786

:

When I go to market strategy evolves, the

sales organization evolves, you get things

787

:

like new territories and new segmentations

your customer base and all that sort

788

:

of stuff, I don't think we're doing

anything all that revolutionary there.

789

:

We just have to be, tied to what the

business is trying to do and creating a

790

:

set of priorities, determining what we

can do easy and as impactful and making

791

:

those changes as quickly as we can.

792

:

Track 1: Well, they're lucky to have you.

793

:

And I love how you think about this

stuff it sounds like in many ways

794

:

you've built something really awesome.

795

:

So I'm glad.

796

:

That we could just talk about it and

expose more people to the way that you've

797

:

thought about your stack I will include

links to your blog post series and the

798

:

show notes because you go into Really

high level of detail on what you've done

799

:

You have videos if you're listening to

all this To those of you out there and

800

:

thinking like oh, I just really should

really see and understand more What

801

:

Niels is talking about you can because

he's gone over it with screen share.

802

:

So we'll share all that But yeah, thank

you so much for coming on the show.

803

:

It's been a ton of fun learning about

804

:

niels-fogt_1_02-20-2024_140545: Awesome.

805

:

Yeah.

806

:

Thanks for having me.

Links

Chapters

Video

More from YouTube