Martech Is Becoming Data-first w/ The Chiefmartec
The lines between marketing and data technologies are getting a little more blurred every day.
Scott Brinker, the editor of chiefmartec.com and the VP of platform ecosystem at HubSpot, is the leading authority on marketing technology.
Scott has spent almost 15 years dissecting the martech industry and in this episode, he explains how martech is becoming data-first and what's causing this shift.
He also answers some questions about data integration technologies — ETL/ELT, Reverse ETL, iPaaS, and CDP — and shares his thoughts on warehouse-native apps.
This episode is packed with insights that'll certainly help you make more informed decisions in regard to buying data and marketing tools.
P.S. If you can’t spare 15 minutes, 9:05 - 9:40 is my favorite part. If you’re reading, here you go.
Let’s dive right in:
Q. How is Martech becoming data first and what is causing this shift?
Obviously, data is embedded in all Martech. All Martech is essentially digital and everything digital is driven by data.
But I think for the first 10 years or so, a lot of companies were thinking less about the data component of it and more of just the actual functionality — how do we learn these new channels? How do we run these new programs? How do we run these new campaigns and there was all this data involved in that?
But now that the services we're using are becoming more mature, we're understanding the opportunity to get more leverage out of those services by getting better with the kind of data that we are feeding into them.
There’s an infinite amount of data inside our companies and available through partners in the second-party data world. We don't even have to go to third-party data; we have more data than we could possibly use at this moment. And so I think it's a really exciting time for Martech professionals to be upleveling how they think about what data they can use and how they can use it effectively.
Q. Do you think Martech tools will soon become data tools and the ones that don't will become irrelevant?
Yeah at some level every Martech tool has to be a data tool.
But I think it's fair to say that some have had relatively basic data capabilities. A lot of Martech tools were very siloed when they were first created.
They had their own little database of — here's what's happening inside this tool. But they weren't necessarily as aware of — oh well what are the other signals that are happening outside of our tool that we should be aware of? As we have engagements and activities within our tool, are we making sure we're passing those signals and information further downstream to others?
I think you've seen now that the innovation happening in Martech is really happening around having better data-in and data-out capabilities.
And then of course, as you get more data in, how do you have better abilities to apply the data inside the tool?
So I think you're right — if a Martech tool doesn't keep up with this movement, they do seriously risk falling into irrelevancy.
As the VP of platform ecosystem at HubSpot, you have an insider view of the most pressing needs of GTM teams.
Q. Do you think GTM teams generally care about the technologies that are used to solve their problems?
One of the things we've seen across marketing, sales, customer success, partner management, and partner ecosystems, is all of these teams have Ops professionals — some of whom are now being aggregated into these Revenue Ops or RevOps teams.
And since leveraging digital capabilities and data has become so fundamental to everything our go-to-market teams want to do, these Ops teams have really taken on the massive responsibility of delivering on what GTM teams need.
Now, inside the Ops team, I think you'll have people who are very savvy about the tools they're using — a big part of their job is to manage the existing toolset, understand how it's evolving, as well as evaluate new capabilities that they can bring into the stack.
As you get further away from the inner workings of the Ops team, the rest of the organization is less concerned about the specific technology and more about, “hey can you deliver the actual program, capability, campaign, that I need to deliver my results (and improve the outcomes of my efforts)”.
Q. Since you talked about Ops teams, what are your thoughts on the gap between data teams and non-data teams? Are Ops teams suited to beat this gap?
Yeah, and this is one of the things where there's a wide spectrum inside the Ops profession right now.
I would say all of them are relatively data-savvy — that's a core part of what Ops is about.
But the truth is, when you're talking about how you're harnessing this data, it's not just about being savvy about data. There's increasingly these capabilities that involve data engineering — how are we piping these things and how are we managing data not just within these specific application silos but across the enterprise more broadly?
And as you get deeper and deeper into that, I mean this is some highly sophisticated work. Speaking of the Ops profession, there's a whole universe of what we would call Data Ops — people who are specializing in this (data pipelining).
So I would say most Marketing Ops and Revenue Ops people probably aren't that savvy — they're not Data Ops people, they're not data engineers but they know enough about what they need to do with the data and they can wrangle it from the business side to service the bridge between data specialists and the rest of the business users (non-data people) who just want see data applied (put in action).
Agree totally! So the rise of data warehousing has completely changed the Martech landscape by introducing new technologies like Reverse ETL and Warehouse-native apps.
Q. Do you think these have the potential to completely replace the way Martech tools are being built and sold?
I've been writing a bit about this here over the past couple of years where, in many ways, the Martech stack grew up in its isolation, and the reason was very logical — digital marketing was moving faster than the rest of digital transformation inside an organization.
So marketers — this is part of why they built Marketing Tech and Ops teams — had to implement more capabilities ahead of what the rest of the organization was willing to do. Well, fast forward here a decade, and now every organization is going through — it's become cliché to even call it — digital transformation.
These digital capabilities are now being baked into the entire organization. As a result, the mission is changing where it's no longer about, “this nice, isolated tower of the Martech stack.” It's about how our marketing activities and capabilities interface with the broader technology infrastructure that the company now has specifically around data.
So this has been an exciting space as you see the Data Warehouse layer is increasingly becoming like a foundation which every department inside an organization is both able to contribute to and derive value from.
So yeah, integrating the Martech stack with the enterprise-wide data layer is probably the most exciting thing happening in Martech right now.
Got it, yeah. Now let's talk about Data Integration technologies. We've got ETL/ELT, Reverse ETL, iPaaS, and CDP.
Q. Do you see a future where companies keep paying for multiple Data Integration tools and technologies?
We've got this challenge throughout the Martech stack where there is significant overlap across different products and categories, and given the nature of how companies expand, I expect the overlap to grow further.
In some theoretical world, you would say, “Oh I don't want to pay for any overlap. I want, this one thing to do this and there's a very nice neat boundary, and then this other thing that'll do the other thing.”
That is an aspirational goal that we can head towards but today, inside most organizations, you have overlap. And that overlap is actually useful because depending on the particular way you're wanting to do something it might be easier, faster, and cheaper, to do it through one product versus the other. Having a little bit of optionality and flexibility can be beneficial.
That said, kind of like Occam's Razor of the Martech Stack — you want your stack to be as simple as it possibly can be, but no simpler.
So do you really need an ETL, a Reverse ETL, an iPaaS, and a CDP? Probably not. But again, it really does depend on the specific structure of what's happening inside your organization.
🤔 Have questions for Scott?
Many organizations today continue to use iPaaS tool for ETL and Reverse ETL workflows.
Q. Few people understand iPaaS better than you do — can iPaaS fully be replaced by warehouse-centric data integration technologies like ETL/ELT and Reverse ETL?
No, and I think that's a good example because leading iPaaS players cater to a range of use cases and supporting data pipelining — ETL and Reverse ETL — is one of those use cases.
Another place where they promote more of their functionality is the ability to create business workflows at the application layer crossing different apps and departmental boundaries, which is something that ETL and Reverse ETL really don’t even have in the picture? I think that's an example where you typically see some people using an all-in-one iPaaS for both their ETL work and their business workflow management.
Then I think more often now, you're probably seeing cases where the data pipelining starts to be a fairly specialist capability where a lot of innovation and change is happening.
And the workflow side is still a massive opportunity — we have barely scratched all the possibilities there. I wouldn't at all be surprised for a lot of companies to have both ETL and that iPaaS workflowish capability in their stack.
I think so too. Now, you've made a ton of predictions over the last few years.
Q. If you had to make a prediction about Reverse ETL or Warehouse-native apps, what would that be?
I'm always cautious in predictions just because — was that the Yogi Berra — predictions are hard, especially about the future.
That said, I think the sophistication of the Data Warehouse layer is advancing incredibly rapidly. There was a time when the Data Warehouse was really nothing but dumb storage. It was basically like, “Yep, we just put it there and then if we actually wanna do anything with it, oh, okay well then we have to like pipe it out into different apps.” And the process of piping was slow and expensive and you ended up duplicating data all over the universe.
As this new generation of cloud warehouses continue to advance, it's more and more about saying, “Well hey, there's probably a whole bunch of activities of things you wanna do with your data that you don't actually have to pipe the data out of the warehouse to do.”
That we can keep the data in place but now we're able to actually conduct activities on it — do manipulations to it almost in a kind of virtualization of things that we had to shove elsewhere previously — which is an incredibly powerful direction.
There's a ton of innovation but it also raises a ton of questions regarding complexity. Some of the hardest work associated with data isn't the mechanics of the data — it's the agreement on the models and on the governance.
So in some ways, having all that stuff inside the one core warehouse probably makes the tech mechanics a little bit cleaner but also raises the bar on, “Well, what are the operational processes we need to put in place to, effectively do that without it just turning into chaos.”
Q. Last question — do you have any tips for companies evaluating data integration technologies that we just discussed?
Yes, if at all possible, actually get a free trial pilot program — plug it in and make it work.
The canned demo is nice, but so much of this comes down to like how easy is it for a particular technology to work in your environment?
And so I think just being really insistent on proving that out as part of the procurement process is generally sound advice.
Prefer watching the interview?
🎶Playlist of the week: Mark Knopfler wants to remind us to be here now!⌛
Thanks for reading/listening/watching — let’s beat the gap! 🤝