The MAP Is a Pipe. The Industry Just Hasn't Priced That In Yet.
Peter Oleson's case for why marketing automation platforms (MAPs) should stop trying to be the brain, and what happens to an entire software category if he's right.
Every marketing automation platform sold in the last decade has promised the same three things: unify the data, personalize the moment, break down the silos. The pitch is so consistent across vendors, generations, and funding rounds that it no longer means anything. What nobody says out loud is that MAPs are, structurally, in the business of creating data silos, not eliminating them. Peter Oleson says it out loud.
Oleson is a Solutions Engineer at Hightouch*, an agentic marketing platform that reached a $2.75 billion valuation, building an AI platform for marketers based on the thesis that MAPs should stop trying to be the brain and start being a better pipe.
*The opinions and views expressed here by Peter are solely his own and do not reflect the views of his employer. Also, this episode does not reflect Hightouch’s sponsorship of MSoM; we retain full editorial freedom.
He did not arrive at this argument from a think piece. He built cross-channel journeys at Merkle as a Salesforce Marketing Cloud architect, then moved to Iterable, where he ran live product demos teaching customers how to build the automated journey builders he now calls the wrong model. That is not a career arc. It is a full reversal from inside the machine.
The data tax is real, but the counter-charge is incomplete
The central bet Oleson is making is worth stating plainly: MAPs should stop trying to understand the customer and become the system that reliably executes a decision made elsewhere. Bigger pipes, not smarter platforms. The obvious counter is that composable alternatives carry a hidden tax of their own, anywhere from half a million to a million dollars a year in data engineering headcount that never appears on any vendor invoice. Oleson does not dismiss this. He reframes it.
MAPs charge for data storage, activation, and execution. In a composable model, yes, data and engineering costs are real. But all of that work lives in your data platform, with your data, and you own it. When you switch platforms — and you will switch platforms — you take it with you. The MAP model leaves you negotiating a migration problem in every new implementation. The composable model leaves you with an asset.
"It's not a tax. It's an investment with dividends."
The other thing MAPs do not advertise is that there are zero marketing automation platforms willing to let you disable profiles and audience building because you handle it upstream, and then reduce your contract price as a result. You pay for the full bundle whether you use it or not. It is the cable television model: 800 channels, 20 you want, no discount for the 780 you will never touch.
The silo pitch has always been the tell
The "breaking down data silos" line is where the MAP category's self-description gets genuinely funny, if you have been in this industry long enough to track the gap between what vendors say and what the architecture actually does.
MAPs do not break down data silos. They create them. They take a partial copy of your warehouse data, store it in their own system, generate engagement events inside that system, and then require you to pipe that data back out to your central source of truth for analytics and decision-making. Every step of that process is a silo with extra paperwork.
"By definition, most marketing automation platforms are creating silos — not breaking them down. They're in the business of creating copies of data."
The one narrow exception Oleson grants is consolidation: if you are running Attentive and Salesforce Marketing Cloud (SFMC) separately and you collapse everything into a single MAP, you have arguably reduced a silo. But you have not broken one down. You have moved it. The data still lives in a copy, and you still have to retrieve your own engagement data to do anything meaningful with it downstream.
Accountability does not transfer to the agent
One of the more useful reframes in this conversation is on AI agents and who owns the outcome when the send decision is wrong. The instinct in the industry right now is to treat the agent as a kind of accountability buffer; if the machine decides, the machine is responsible. Oleson is not having it.
Before agents made these decisions, humans did. And humans made mistakes too, often worse ones, because building a decision tree inside a MAP UI is a multi-week sprint that still ships with errors. The difference now is that agents fail faster and at scale. The question is not whether agents make better decisions than humans. It is whether the agent had enough context to make a good decision at all. If it is operating inside a MAP, the answer is almost certainly no; it is working from a subset of the data that should be informing it.
"If you're not reviewing the outputs or the decisions of whatever agent you're employing, then the nasty Slack message absolutely has to go to you. You don't get to abdicate responsibility just because agents have gotten better in the last two years."
The self-driving car analogy holds here. The question of who is responsible — the driver, the car, the manufacturer — is still unresolved in law and in practice. Marketing has not resolved it either. The answer Oleson lands on is that human review of agent output is not optional yet, and organizations that skip it are not being efficient. They are just deferring the blame conversation.
The composable clause that never survives implementation
RFPs now routinely include language like "vendor must support composable architecture." This sounds like progress. It is mostly theater. Oleson puts the real-world hit rate of that clause surviving a six-month implementation at close to zero, and the failure comes from both sides of the table.
On the vendor side, almost every MAP market’s warehouse is connected while actually performing warehouse transfers. There is a meaningful difference between sitting on top of your data platform and connecting to it. One stores nothing. The other stores a copy and calls it native. The platforms that do genuinely avoid storing the profile run into their own problems with latency and scalability. The marketing of composability has outrun its architecture.
On the buyer side, the clause is included in RFPs because it reflects the organization's stated data posture. Two months into implementation, someone surfaces one use case that is easier to handle inside the MAP's audience builder. That is the moment the composable commitment ends. Oleson's question for those teams is direct: is this a preference or a need? Because those require different answers, and conflating them is how you end up paying for architecture you do not use while building the one you said you would not.
"The second you say, all right, I need this, but there's this one Snowflake use case over here — that's a unicorn. You're talking out of both sides of your mouth."
The early signal is not declining ARR
Oleson projects that 30 to 50% of enterprises will adopt the composable model over the next two to five years, starting with large, sophisticated organizations and filtering down. Meanwhile, Iterable, Braze, and Klaviyo are all still growing. The obvious question is whether rising ARR means he is wrong or just early. It is clear that he is early. But he is also watching for different signals than revenue.
The early movement is not about companies cancelling MAP contracts. Enterprise infrastructure does not get replaced overnight, and auto-renewals bury the dissatisfaction for years at a time. The signal is shorter commitment terms, more one-year deals, whereas three-year deals used to be standard.
The signal is API-driven execution, where customers use trigger endpoints rather than the journey builder that was the MAP's core value proposition. The signal is customer success teams inside MAPs hearing, two or three years in, that the journeys the platform was sold on are no longer what customers actually use.
"I don't think it's a question as to whether or not ESPs or MAPs have value. Where does the value come from? Does it come from owning the customer model, or does it come from being a totally awesome and bad*ss execution layer in the stack that you never have to worry about?"
His answer is the latter. And the MAP that figures that out first, that becomes the most reliable, scalable execution pipe in the stack and stops fighting for ownership of the customer model, is the one Oleson thinks reshapes the category.
Who that is, and which modern players are actually adapting versus waiting it out, is the subject of Part 2.
Three Takeaways
If your MAP contract does not allow you to disable profile storage and audience building in exchange for a lower price, you are paying for the full bundle regardless of what your data team built upstream. Price that into the composable-versus-bundled comparison before the next renewal conversation.
Agent accountability does not transfer. If you are deploying AI agents without a human review layer for the output, the Slack message comes to you — not to the vendor or the model. Build the review process before you build the automation.
The early signal that MAPs are losing ground is not a decline in revenue. It is API-only usage patterns and shorter contract terms. If your team is bypassing journey builders to hit trigger endpoints directly, you already know something your vendor is not ready to hear.
Peter Oleson is a Solutions Engineer at Hightouch. Find him on LinkedIn, where the essay that started this conversation is still generating replies from people who work at the platforms he is describing.
Full Episode Transcript
00:00:01 — 00:04:06
Welcome to the Making Sense of Martech, where the rabbit hole goes deeper than the headlines. This is a show that pressure tests ideas, not just platforms. Peter Oleson spent years using Salesforce Marketing Cloud and at Iterable. Teaching customers how to build the exact journey. Builders, he now says, are architecturally broken.
Today we find out if that's a conviction or a business model. By the end of this conversation, we'll know if Peter is a plumber telling the truth about the pipes or a guy selling wrenches. A little bit about him first. Peter is a solutions engineer at Hightouch, the composable CDP and authentic marketing platform who's betting on the future.
The idea that the map category he came from is running out of reasons to exist. He didn't arrive at this argument from the outside. He built cross-channel journeys at Merkle as a marketing cloud architect, then moved to iterable, where he ran live product tours, specifically teaching customers how to build the automated journey builders he now calls the wrong model.
And that's not a career pivot by any stretch of the imagination. That's complete reversal. And from an insider. Welcome, Peter. Thank you for being here. Thank you so much for having me. I'm a big fan of this podcast. So this is a this is an energy your energy. And I'm a long time viewer. I am the YouTube viewer.
Yes, I'm grateful for that. And also we need you to go ahead and out of the way. Put a disclaimer, at least for my end, I have all editorial independence, and so this has absolutely nothing to do with the fact that Peter works at Hightouch. And I think, Peter, you probably have your own equivalent. Oh yeah, I have my own martech hatch act to say here, which is that everything that we talk about, all the opinions that I have, these are my opinions.
They're not the opinions of Hightouch or any former employer that I've had for that matter. I arrived at these all on my own. So these are mine? Yes. and I have receipts. If people really get upset, this conversation Peter and I've been having for at least 4 or 5 months. And so please note, this is just truly a philosophical conversation, and I'm so grateful that you even came up with it, because it has rocked my world for the better part of this year.
I'm excited to have the conversation. Me too. At least in a formal capacity. That's right. Let's start off with some rapid fire. What was your first martech tool? So technically. And I had to reach out to a former colleague. This was Dreamweaver and an in-house built tool called the cinematic 5000. Um, I think it was like a Saturday Saturday Night Live bass reference that's dating me.
Um, but, uh, it was really plain. You could basically do some minor audience building. It didn't even have scheduling, so I was like waking up at seven in the morning to hit send so that on the East Coast they would get it. Um, but in terms of enterprise grade, that was Marketo. And at the time it totally blew my mind.
I was like, oh, you mean that you can capture events directly on site and do follow ups? This is amazing. Sign me up. Understood. Also, I feel like it's it's no longer cool to say, but I love Dreamweaver. Oh, yeah. It's great. Like anyone who's been in the game long enough knows that. Like, if you want properly rendered emails, it's got to be HTML code.
Oh, yeah. And also just Dreamweaver was the first of its kind to make it easy to do both visual and code at the same time and see what you're doing in real time. Change the code over here. See it over there. It was great. Exactly. All right. Real talk. Garbage disposal. Water heater or dumb pipe? Which kitchen appliance are you?
Do I have to choose one of the three, or can I choose my own? You can choose your own.
00:04:08 — 00:09:21
Uh, if I'm a kitchen appliance, I'm probably something more like, um, like a French press, which is not like a sophisticated, like, mechanical appliance. Uh, but the reason I say that is that, like the users of a French press, like, pretty opinionated. I'm pretty hands on. Um, and I'm also a firm believer in, like, better inputs and thoughtful processes produce a much better output.
So, like, good beans, good grinder and ten minutes, as opposed to you flip a switch. Um, it's going to produce a better output, better cup of coffee in this case. I like that. And also you work well under pressure. You've held three distinct seats in this industry ESP map vendor agency selling the platforms and now a warehouse.
Native company arguing maps are broken. Which version of Peter in your whole career was most wrong? So I choose to say that like, I learned new information and changed my mind rather than being wrong. Um, but if I have to choose, it's probably either agency. Peter or. I spent a very, very brief time, um, as an account executive at a map.
Um, and it was just not the right role for me. But agencies are great. They make a ton of sense for specific types of companies. However, like, in my experience, they're kind of always after the almighty billable hour and increasing those. Right? Um, so there can be at times a little bit of a conflict of interest there, right?
Because if I'm in the business of selling you more hours of my time than potentially, I can get into this dangerous territory of being self-serving rather than serving the customer. Right? Yep. It's as if that's Deloitte and Accenture's home model. But. Right. And I'm sure that there's there's some people who are going to listen to this who employ agencies for a specific part of either their marketing ops or their strategy.
And I'm sure that there's a subset of those people who are like, oh, yeah, that one campaign that's super complicated. I actually don't know how the sausage is made. Like, I don't know what it actually takes to execute this. Um, and I think that that's pretty normal. And so what I would say there's like, I've always been invested in, if you're going to go the agency route, if you're going to bring on consulting, make sure that, yes, they fish for you, but they also teach you how to fish, because that's the critical part, because that relationship will end at some point, and you need to know what to do from that point forward.
Yes, nothing is worse than all of your company's institutional knowledge not being in-house, right? And that's not just a blueprint like that can't just be a blueprint. You have to get hands on. You have to understand what's going on there. Exactly. Okay, so if a brand came to you tomorrow and said they can't afford to have 3 to 5 dedicated engineers, would you tell them to buy an ESP marketing automation platform?
Sep. Whichever name we're going off of the alphabet soup. This industry did not make it easy on anyone. Um, so. All right. Would I tell someone to buy a marketing automation platform if they had? Let's call it limited resource on the data and engineering side. Um, as someone in solutions like my skin kind of crawls answering this question without, like, asking five follow up questions, but I guess I'll do my best here.
I think you can get away with fewer data engineers than you think if they're fully dedicated to the marketing team, and I say the marketing team and not just the platform, because oftentimes there's other platforms that are involved here, right? So I think you could probably get away with fewer than five.
But what I would say in addition to that is the most important thing that I've seen is that regardless of the number of data engineers that you have, right, is that you do have to have one or maybe two people that are the ultimate decision makers, because this isn't a democracy. That's something that actually a former boss of mine used to say a lot is like, this isn't a democracy.
We need to make decisions. Democracies take too long to make decisions. So you do need to have some 1 or 2 people that give a go, no go at the end of the day, and they have to be accountable for that decision. Um, another thing that I would say is I don't actually think in the future that data engineers should be in charge of building the pipes between your data platform and then the tools that your marketing team uses.
So like could you could like snap accordingly. Like. Yes.
00:09:22 — 00:09:56
Yeah. I just like that's not a good use of time. And I think it's also important to note that the more time that your data engineers are spending in the data platform, that's actually a net benefit to marketing, because then you get to benefit from all the amazing data engineering work that they do, as opposed to, hey, can we get this one additional attribute over here in Salesforce Marketing Cloud?
Like that's just when you consider this an even dumber pipe.
00:09:57 — 00:11:40
Uh, what do you mean, there? I mean, having a data engineer set up these pipelines with likely minimal observability, minimal understanding of what they're building. They're just doing point A to point B, as they were told. Definitely a dumber pipe than the the execution layer inside of the map that we've talked about.
That makes sense. Okay. Are you still friendly with your former employers? Of course. Yeah. Um, this is a small industry. Like, despite being, you know, 10 to $25 billion, uh, market, depending on how you look at it. Like, it's a small group of people. And so you run across the same people a lot. Um, and so, yeah, I'm friends with folks from from my agency days, from my marketing automation platform days we interact in public on things like LinkedIn.
We interact in private. Like, I still have text threads with former colleagues of mine in the space, um, a few of whom reached out after I published the essay on LinkedIn. Um, oh, I met. Yeah. It's I mean, it's all love. Like, it all comes from a place of I want to see this industry as a whole succeed. And in order for us to do that, we have to really have a close ear and understanding of what the customers who use these products want and need.
And so that's really what this was about. Um, but it's also worth noting, like at the end of the day, I'm such a product nerd that
00:11:41 — 00:14:43
I vote with my feet on that front. So, like, if I have an opportunity to go and chase what I think is going to be the next thing. I'm going to go vote with my feet and go do that. Understood. Okay, so when an agent is making the send decision and it's wrong, who gets angry? Slack messages the marketing automation platform, the warehouse or the agents vendor?
I mean, short answer is probably wherever the agent lives. Like, maybe that's in the warehouse, maybe that's in the marketing automation platform, maybe that's somewhere else. Um, so it's probably wherever the agent lives. But I think we need to be clear that before agents made these decisions, humans did.
Right. Yes. Um, and to a certain extent, it was a lot worse when humans made the error. Because oftentimes, if we're making decisions inside of a marketing automation platform, this is like a multi week sprint situation where we're trying to uncover every possible thing that could go wrong And mistakes still occurred, right?
Um. Oh, yeah. So, um, I also think that there's another thing to think about here, which is did the agent have enough context and understanding to make the right decision? Right. Um, and this can be does it have just enough raw material to work with? Um, so if it's inside of the marketing automation platform, you can probably tell my thought processes, no, it does not have enough context to work off of.
That is a subset of the overall context that it could and should be using. Um, on top of that. Does it have an actual like the term that's kind of an eye roll. It's like semantic understanding of the data, basically. Like can it read the data based upon what you tell it that data means? Or is it having to infer all of that?
And I guess what I would say as by way of advice is like, if you're employing agents that don't have all the proper context and the understanding, then you probably need to take a little bit of a look inward and like maybe you're sending yourself the nasty slack. Right. Yeah. I think a lot of it is kind of like self-driving cars.
Is it the driver? Is it the car? Is it the car company? Is it you? There's just too many nuanced question marks that we haven't quite figured out. And I think it's the same concept. Totally. What laws or what regulations can we internally impose to maybe avoid these types of things and circumvent. Right.
And that's why for a long time like you, you're still going to have to require that human behind the wheel of the car. It's no different in marketing. And so
00:14:44 — 00:14:53
if you're not reviewing the outputs or the decisions of whatever agent you're employing. Then I would say, like
00:14:55 — 00:15:11
the nasty slack message absolutely has to go to you. Like you don't get to abdicate responsibility just because agents have gotten better in the last two years. Yeah I agree. All right. Last but not least, what is your hottest take? You're gonna hate this one. Oh,
00:15:13 — 00:15:29
um, if we're talking traditional marketing automation platforms, I don't think anyone beats the original exact target Salesforce Marketing Cloud. I don't hate it. I just dislike the fact that it's true.
00:15:30 — 00:17:22
And here's my reasoning. Like, they're probably going to be people that's like, this is the guy who's talking about the dumb pipe and he's talking about exact target. Can't get data in fast. And, uh, you know, the contact model still exists. Like, yes, all of that's true. But if we're if we're having to choose on traditional maps, um, I don't think it gets beat.
Um, I never worked in Salesforce Marketing Cloud next. I'm not a big fan of like, all right, we have to have CRM or data 360. Um, but the reason why I think that Marketing cloud, the original exact target version is the best is because while it takes a really technical person to make it run the way that it needs to, if you have that person, it's infinitely flexible.
You can do things that modern platforms can't do. Um, things like, oh, every modern platform has some kind of eventing in it, right? But if you want to say, all right, I want to take the most recent three events that were attributed to Peter. So like, maybe that's recipes. I'm a huge cook. So like, I want to take the last three recipes that Peter looked at on this site.
And I want to surface that in a blast email. Like if that's in your data extensions, you can do that in Marketing Cloud, whereas a lot of the modern platforms are going to be like, oh, you want to do that? Huh? Okay. Well, our recommendation would be to aggregate that outside of our platform and then just send it into us.
So it shifts all of the work to say, all right, you have to do this. You still kind of have to do it inside of Marketing Cloud two, but you can do it with AMP script. If you have someone who knows what it is that they're trying to achieve. So that's why I say that, no, I agree, I still stand by in marketing. Cloud is the most powerful tool, but
00:17:23 — 00:19:59
the hardest at the same time. You really have to have an architect overseeing it 24 over seven. Yep, a lot of things can break there. It's really expensive. But if like cost is no object, it's a pretty good tool. Um, I'd also probably say, I don't think this is a hot take really. But I'd go one step further, and I'd say that a lot of the next generation of marketers are going to be worse off, having not been forced to learn a platform like a marketing cloud, like a pardot, etc..
I agree, I think, um, in terms of the technicality, you can still be a great marketer, but in terms of problem solver and solution of okay, how can I do this in a different way? There's just a lack of flexibility. If you haven't had to build something that it was not prepared to do. Right. And then also like we talked about in your last question about about agents is like you have to be able to evaluate the output, understand what it's doing and know where it has gotten things wrong.
And I think if you've been in one of these platforms that was kind of your full time job for a while. And so the diagnosis and identifying, uh oh, this is maybe where something went wrong, but let's flag a couple more places and then do the deep dive. Yep. Totally. Um, okay, let's set the stage. So your central bet has been.
And it's worth stating very, very plainly before we test it. Map should stop trying to understand the customer and become the system that reliably executes a decision made elsewhere. Bigger pipes, not smarter platforms. And the stakes are really present and real. Because if you're right, an entire category of enterprise software loses its core value proposition, and that's been a mainstay for a long time.
And if you're wrong, you're selling a solution that requires seven figure engineering teams that most companies don't have. And so you argue that maps charge customers to store the data that already resides in the warehouse. And it's a data tax. But the counter charge is that the composable alternative sometimes costs, you know, anywhere from half 1 million to 1 million a year in data engineering headcount that never appears on any vendor invoice.
Is that just a different tax with better PR?
00:20:01 — 00:22:10
I don't think it's a complete equivalent here, and I'll try to explain why. So like the data tax is just the dumb part of it. Um, you also pay for activation and execution, right? Like every platform out there has a CPM. Or if you're marketing cloud, you have super messages, which I'm still not sure exactly what they are.
They still don't know either. Also, like if you want to get a laugh out of anyone that has used marketing Cloud, just ask them what a super message is. You pay for the data storage, you pay for the activation and execution. Um, you're also still in the case of maps, like you still have data and engineering headcount today.
Um, and so there's maybe a question of like, are we talking about going and building in-house? Like, that's certainly not free if we want to go that route. Um, it's also not free if you want to go. Well, in the case of an in-house build, you're probably going directly to an MTA. Um, but maps charged you to store a sliver of the data, right?
Like, it's just a portion of the data that already resides in the warehouse, but with a more composable approach like the date, as the data model changes, as, um, it grows or contracts or changes in its nature. Like, I'd argue that in a composable approach, having access to that data is worth some kind of tax, right?
The other thing that I would say is like you're able to execute off of more of the marketing surface, right? This is something that I'm hearing a lot in conversation now is like, how do we align our life cycle and our performance marketing teams together, which is not really a strong suit of the traditional map right there, mostly focused on own channels, email, SMS, push.
Um, you know, in app. I guess what I would say is like nothing's free.
00:22:11 — 00:22:42
Even in-house platforms cost time and money to build campaigns and cost even more money to build. And yeah, that's a sad reality. I mean, I think we're gonna see in, you know, a couple of years, all of the people who vibe coded their way into a marketing automation platform are going to come back. Um. Oh, yeah, it's it's going to be a mass exodus.
Yeah. Right. Um, but I would say, like, the composable approach gets you a clearer picture of your customer
00:22:43 — 00:24:03
with the ability to do more things with that information, and you buy what you need, not a bunch of things that you don't, right? So, like if you're buying a map, like you're automatically usually getting the audience builder, the campaign builder, the journey builder. Um, other, uh, insights tools that you may or may not use, like all of that goes into your cost.
Um, but with a composable approach, like you can kind of pick and choose what parts you need and what parts you don't. Yeah, I kind of think of it as the the old, like, cable bundles. It's like, I actually don't want all 800 channels. I want these 20. I only want to pay for these 20. And if you don't want to pay for the remaining amount that you will never use, That is the difference.
And that is what you need to be able to laser focus on. And so yeah, hopefully we kind of expanded and blew out with the um, with the streaming platforms as well. Right. Like I it's coming back. We're bringing back bundles essentially. Yeah. We're going to consolidate. There's going to be consolidation there.
But I guess like yes, there is
00:24:04 — 00:24:40
a tax in terms of data and engineering headcount. I guess a major difference there is all of the work that data and engineering does is in your data platform with your data and you own it. Like that's a that's a benefit. And so when you actually go to switch platforms or something like that, you take that with you.
It's not stuck in a marketing automation platform. And you now have to have that as part of a problem during your implementation and your switching. Yeah. Truthfully, I would say it's not a tax. It's an investment with dividends. That's a good way to put it. Are you in marketing?
00:24:42 — 00:24:44
Maybe I don't know.
00:24:45 — 00:25:08
Yeah, that was good. Um, okay. In your essay, the RFP language you reference vendor must support composable architecture is a bit anonymized and a little generic. How often does that clause actually survive a six month implementation? When the team realizes they need to stand up and maintain the pipeline themselves?
00:25:09 — 00:25:57
I would say it's like a borderline zero hit rate when you're looking at a traditional map, right? Um, and there's a lot of reasons for that. Like, and not all of them are related to the marketing automation platform. A lot of them are related internally to the teams who are asking that question. Um, but why I say 0% hit rate?
And by the way, like it's worth noting that like, this isn't really thought leadership. This is like, these are things that customers come to me with and say, like, this is important to me. And so this is very reactionary. And and what I'm seeing in this space, not necessarily where I think it's going. It's already here, but why this is a 0% hit rate on
00:25:58 — 00:27:39
all of the, um, the implementation side of things. Part of the reason is because the data foundations for the marketing automation platforms that these customers are asking the question to don't truly support it, even when they market themselves as such, like every platform, to my knowledge, has some concept of the user profile.
There is maybe one platform that I can think of off the top of my head that does a true warehouse native version of this where they're not storing it. But then there's all sorts of other problems with latency and scalability there. Um, I'm not going to name names there. It's not particularly important. Um, you can name it.
We can cut it because I just want to know. Yeah. That makes that that is a warehouse native platform that data and engineering teams love. And marketing teams tend not to love as much. Correct. Okay. That tracks so like they have this profile and they're forcing you into that. Um, and they say things like we can connect directly to your warehouse, but that's warehouse connectivity that's not sitting on top of your warehouse.
You're still transferring that stuff in. Um, so part is on the marketing automation platform side. The other part is actually on the organizations who are asking that question, because they often put that in an RFP because that's been like the data posture for their organization. But
00:27:40 — 00:28:58
two months down the line, they're ultimately going to say, well, I have this one specific use case. I actually want to build the audience inside of the marketing automation platform and not outside of it, just because it's easier for some reason today, right? Maybe long term that's not the case. But the second you say, all right, I need this, but there's this one snowflake use case over here.
That's a unicorn. You're talking out of both sides of your mouth. So I think like it's important and it's incumbent upon the the organizations asking that question to be really honest with themselves. Is this a preference or is this a need brought to you by our sponsors? If there's one theme that's followed me at every stop in my martech career, it's trying to get good data into the hands of marketers.
That's why I'm so excited to tell you about our sponsor, Hightouch, the leading composable CDP and AI decisioning platform companies like Domino's, Chime and Ritzy and PetSmart trust Hightouch to power their data. And here's the kicker 90% of customers have a real use case live in production within their first week.
That means you can implement a world class CDP in months rather than the usual years long headache. That's why top brands choose Hightouch to personalize every customer interaction at scale. See what Hightouch can do for you at Hightouch.
00:29:00 — 00:30:02
And now back to the hot seat. Very valid. I mean, I'm always gonna say I think segments should exist in a map, but they're based on what's in the data warehouse. Exactly. Because you want that easy accessibility. But if you're doing omnichannel, multichannel, if you're thinking of decisioning, there's a lot more that goes into play.
And you have to really kind of take a step back and figure out, do you need to go upstream? Do you need to stay where you're at? What works? What are the capabilities? Pros. Cons Name it. Totally. I'd throw out there as well that, to my knowledge, there are zero marketing automation platforms that will allow you to disable things like profiles and audience building because it happens elsewhere, and then also receive a contractual benefit in a reduction of your total platform cost as a result of not having those.
Right. It's like number one, they don't do it. Number two, you're not going to save money by requesting that they not do it. So
00:30:03 — 00:30:13
I can see if I can try. That sounds like a challenge. You're probably a better negotiator than I am. Uh, for better and for worse,
00:30:14 — 00:32:55
either your best friend or your worst nightmare. Right? In your piece, you're projecting 30 to 50% of enterprise adoption of this new model in the next 2 to 5 years, starting with elite companies and filtering down yet iterable. Bray's Clavijo customer I know they're all still growing today. At what point does rising RR stop being evidence you're wrong and start being evidence.
You're just really, really early. Well, I definitely think I'm just really, really early, as you well know. And probably everyone watching this knows enterprises don't replace core marketing infrastructure overnight. Like this is a slow burn. Um, and they renew contracts even when it doesn't serve them.
Um, or if they don't remember, it just auto renews, right? Yeah. Crazy to me. There's the whole auto renew. Make sure that, um, you know, that's written into your contracts around, like, there needs to be a notification on both ends, right? Um, but, uh, they renew contracts. Sometimes they auto renew.
Um, but there's been a really gradual movement of data decisioning, orchestration upstream for a while. Right. Um, some really large customers that I've worked with have taken the approach that like, hey, these features inside of the marketing automation platforms. Um, and this is agnostic of platform.
Uh, I don't need these anymore. They actually hurt me more than they help me. Um, and what I've seen a lot of is, okay, we're just going to use your trigger API endpoints, and every platform has them. We're going to use those because that gives me more flexibility and functionality and upstream orchestration.
Then do sending in an event to a braise or sending an event to an iterable or a marketing cloud. So the early signal I don't think is declining IRR. It's more shorter Commitments like the one year commitments. Um, it's more API driven execution or, you know, MCP using an AI harness. Execution. Right. It's it's when you start to see inside of these marketing automation platforms that they're not using the core functionalities that these platforms were built on, things like journeys.
And
00:32:56 — 00:33:03
when you start to hear more questioning of your customers as to what they're actually paying the ESP to own,
00:33:05 — 00:35:29
and I feel really deeply for my customer success compatriots out there because they're the ones that get faced with this. All right. We've been on this platform for 2 to 3 years. Um, when we evaluated it, we were really interested in journeys. But now, for reasons kind of outside of the marketing team's control or Intentionally.
On the data side, we've just shifted our internal position and we actually get better results by going direct to warehouse. Yeah, that's kind of where my head's at there. Yeah. It's a we're at a tricky kind of impasse of it's all a philosophical choice and what each company is considering. And the same goes with like build versus buy, which one is the cultural backbone and which one actually aligns with the methodology.
Totally. And I don't I don't think it's like it's not really a question as to whether or not ESPs or Maps have value. It's like, where does the value come from? Like, does it come from owning the customer model or does it come from being a totally awesome and execution layer in the stack that like, you never have to worry about?
Yeah, exactly. I think it's going to be the latter. But yeah, at the end of the day, I mean maps, esp, EPs, they're all just UI and UX versions of sending on an MTA and standard email protocol. Yep. But it's also needed because not everyone is technical enough, nor really should they have to be. And that's where a Wysiwyg and or a code, you know, a coder to be able to HTML code your email.
Like there's pros and cons to all the things. It might be cheaper to go to a different route, but it doesn't always mean it's the right choice for the technicality of your team. Yeah, it's completely team dependent. Um, and on the map side, one other thing that I would call out, I think it was Luke and Bassetti that called this out in my comments.
Uh, love Luke. A really smart, smart man. Um, but he was actually also saying that becoming the most badass execution layer or like the biggest pipe. Sometimes it's not even
00:35:30 — 00:39:29
a question or a problem that maps get to solve because they don't own the pipe like they're ultimately connecting to that MTA. They are not their own MTA in the way that Salesforce Marketing Cloud and Adobe can be their own. Right? Um, and so they're able to just throw money in compute at a, at a, and queuing at a problem because they're, they own the MTA, whereas, um, other marketing automation platforms that are built on top of an MTA and an aggregator, which for the record is almost every other, it's most of its people.
Yeah, the Adobe and Marketing Cloud are kind of the two separate examples. They they build it from the ground up. But that's also because at that time, probably one of the better options and only options. Yeah. I'll be really curious to see of the more modern players who makes the first decision to become the actual pipe?
Yeah, it's definitely going to be interesting. And also how it's going to shift for like the male guns, the in synch and bird spark posts. Like, what does that mean for their business model? Okay, we've been getting extra nerdy, but now we're going to really dive into talking tech. And I want to pressure test some things because, I mean, it's a pipe after all.
So let's get specific about what is actually running in production, because there's a significant gap between the plain language example of what's actually deployed at scale, and a marketing strategy based solely on a rules engine that can't support modern marketing teams anymore. Conditions change faster than anyone can write.
If then logic love me some handlebars or liquid. So when you thought of this dumb pipe model and kind of just approach. Were you actually talking about rules or about agents making judgment calls that rules can't anticipate? And if it's the latter. Has anyone actually built that yet? Or is the whole category still promising?
It rules inside of a marketing automation platform. They take a few different forms, and you kind of alluded to to a few of them, like nested segments, journey branches, filters, delays, suppression logic, um, template logic, um, each new condition adds another configuration layer. So like we're talking about inside of an application, uh, inside of a user interface, like these are all things that you have to configure.
And they're often all in different places. And they also don't always neatly work against each other. Right. Um, we've all definitely run into that one layer where it's like, oh, I had send time optimization on, while I also had quiet hours and like the two just fought it out. Um, so I think inside of the traditional layer, that's a decision tree and it grows and grows and grows and it ultimately becomes harder to understand, harder to test and maintain.
Um, so I guess kind of the question that you were asking is like, are these agents, are we talking about rules that humans are creating? I think it has to be both. Um, I think there are a few platforms that are starting to get it right, but we're still in a really nascent space here where like agents, I think partially because they didn't always have all the context that was needed historically don't make that great of decisions right now.
I think that's going to change. But the core issue is like, it's not that rules are useless. Um, it's that
00:39:30 — 00:40:27
encoding changing business context and rules through a visual journey. Builder doesn't scale super well. Because this has gotten more and more complex like it used to be. As simple as are they opted in or not, but now people have. Once you get that, you have the appetite for the next thing. It's like, all right, how are we doing?
Like frequency management and making sure that we're not annoying Peter with these messages. And it's the right amount of messages for Peter, right? So I believe that the logic becomes a lot more maintainable when it's defined upstream. And ultimately we're going to use agents for that. Um, because I don't think that anyone actually likes setting up all of these rules inside of a user interface.
Um, so I'm the nerd that likes to.
00:40:29 — 00:40:35
You are a unicorn. You are completely solitary. Uh, I'm aware
00:40:36 — 00:41:03
every generation of martech platforms, whether it's a map or composable, launches with almost identical language, unify the data, personalize the moment. Break down the silos. That's my best radio voice I could ever attempt. And that's not very good. Is that convergence because the pitch is actually true, or because it's what you say to close enterprise deals, regardless of the architecture underneath it?
00:41:04 — 00:41:13
It's probably a little bit of column, a little bit of column B, and I'd also say like some of that marketing was
00:41:14 — 00:42:45
used because that was our best understanding at the time. Right. So I don't think it's necessarily a matter of like, is this true or is it untrue? But I guess the question I would ask is like relative to what is this true? So like unifying data is a good example. Are we talking about identity resolution? Are we talking about simple merging of records.
Are we talking about like deterministic versus probabilistic? Um, and then I also asked the question like how manual is this or how automated is this? And if it's automated and it makes a wrong decision, how do we fix that? Right. Um, so marketing automation platforms, in my experience, are actually the worst at unifying data.
Um, they're not good at this. Um, especially not if you're talking about identity resolution. So like for the most part, you're going to see deterministic matching and a really rough process for merging profiles. If you failed to do that on the way in. Right. Um, so that's probably the unifying of data side of things.
I guess the one other thing that I would say, and this relates back to the dumb pipe and the whole data tax is like, how many of these platforms actually have useful sunsetting policies that help you right size your contract. If only people really thought about it.
00:42:46 — 00:45:26
They don't. Right. And and, um, I also think they shouldn't have to like that shouldn't be a part of it as like, oh, when when they're no longer contactable and when they no longer engage with my app or my site or my products, like, they should just naturally fall off. And then when they're due to come back, they come back in.
But I think the reality is, I don't know if this is a business decision, I don't necessarily think this is like a nefarious thing that marketing automation platforms do, but they don't make it easy. Um, so you know who does pardot. Oh, the recycle bin. Oh, I love that. How much does Pardot pay you? Because you are there.
Zero, man. Literally $0. But it's similar to Exacttarget in that because they were the first two real platforms, both for the B2C and the B2B side of the businesses. They were figuring things out. And there's things Pardot offers that no other platform offers still, and it makes zero sense to me. Yeah, but yeah, I love a recycle bin because it doesn't count against your contact, your marketable contacts, and it's great.


