← MarTech Podcast ™ // Marketing + Technology = Business Growth
MarTech Podcast ™ // Marketing + Technology = Business Growth
How To Operationalize Marketing Technology Using Agile Approaches
00:18:49
Loading summary
Transcript40 lines
- [00:00]
Benjamin Shapiro
The Martech Podcast is a proud member of the I Hear Everything Podcast Network. Looking to launch or scale your podcast, I Hear Everything delivers podcast production, growth and monetization solutions that transform your words into profit. Ready to give your brand a voice? Then visit iheareverything.com.
- [00:26]
From advertising to software as a service to data across all of our programs and clients, we've seen a 55 to 65% open rate. Getting brands authentically integrated into content performs.
- [00:40]
Greg Kilstrom
Better than TV advertising.
- [00:42]
Benjamin Shapiro
Typical lifespan of an article is about 24 to 36 hours. If we're reaching out to the right person with the right message and a clear call to action, then it's just a matter of timing.
- [00:54]
Welcome to the Martech Podcast, a member of the I Hear Everything Podcast Network. In this podcast, you'll hear the stories of world class marketers that you technology to drive business results and achieve career success. Here's the host of the Martech Podcast, Benjamin shapiro.
- [01:15]
According to Salesforce's State of Marketing 2024 report, marketing teams are only utilizing 45% of their martech stack's full capabilities. The Martech landscape is exploding, new tools are launching weekly integration challenges multiply, and most marketers aren't even maximizing the tools they already own. So how can you harness technology without drowning in complexity? How can you operationalize your Martech investments to actually deliver value? I'm Benjamin Shapiro and joining me today is Greg Kilstrom, the principal of the Agile brand and the host of the Agile Brand podcast, which helps marketing leaders implement agile approaches to marketing technology. And today Greg is going to explain how you can apply Agile principles to get more value from your MarTech stack. Greg, welcome to the Martech Podcast.
- [02:04]
Greg Kilstrom
Yeah, thanks so much. Looking forward to this.
- [02:06]
Benjamin Shapiro
Super excited to have you on the show. We're doing a home and home, as they would say in college athletics. I was on your podcast. Great to have you here. You're the master of all things Agile. We'll just call you the Magile from now on. So explain to me the fundamental difference between Agile principles and just efficient Martech operations.
- [02:28]
Greg Kilstrom
Both very important. I talk with a lot of people that know a little bit about Agile and I talk with some people that know a lot about Agile, and so I'll kind of land somewhere in the middle here. And what I like about Agile is when we just talk about efficiency, there's some metrics that we can put against it, and there's some processes we can put in place. But Agile has 12 principles and not all of them apply to all Things, they were written specifically for software development. They've been applied to many things, even to marketing. But what I like about the Agile principles is that it gives us guidance and then we get to, as humans, interpret those and apply those when and where needed. And so something like the idea of. Probably many people have heard of the idea of a retrospective. So what's the thing that you never get time to do that would help more than anything is taking a step back at what you just did and figure out, well, how do we make that better? That's a principle, is like we take a look at what we do and try to improve and continuously improve. And so looking at it in terms of here's these guiding things that help us that kind of get us out of the weeds and they get us starting to think and understanding better ways to do the work, about the work, which once you implement Martech, you have to use it and if you just use it the same way over and over again, you're not going to get better and better results. You're going to get kind of more of the same. So I use the principles as guides.
- [03:48]
Benjamin Shapiro
It's pretty funny that it's a 12 step program. It's basically like the equivalent of we'll take it away from the Alcoholics Anonymous. It's a great program, helps a lot of people, but this is basically like a 12 step program to get your shit together and make sure your stuff works kind of. It's 12 steps. That's all I'm going to say.
- [04:05]
Greg Kilstrom
Right, right.
- [04:05]
Benjamin Shapiro
I feel like there is a reason where like you have a fundamental problem that you're not getting better and so you start to implement Agile. Am I thinking about it the right way? When you decide you're going to start building Agile processes, what's the fundamental problem that you're trying to solve?
- [04:22]
Greg Kilstrom
So a you're trying to solve for a problem that you don't necessarily know the exact solution for. Like you know what you want, you have goals. I think common misunderstanding is like Agile is just like anything goes and we just kind of go wherever the wind blows. Agile require to be successful. You need goals, you need KPIs that you're going to measure those goals against. But you also know that the world changes and the information that you have when you start a project is going to be different two, three, eight months into it. And so you use the best information at your disposal to make the best decisions and get towards that, that end goal and sometimes that end goal changes. I mean anybody having a plan For a digital transformation one month before the pandemic, their plan probably needed to change. And if they kept to the same plan, shame on them. The world needed to change a little bit in terms of digital experience, all that stuff. So, like, this gives us an ability to pivot. I hate using that word sometimes, but it does give us the ability to pivot when we have new information. But it also gives us a plan to increment, see what works, get to the next step and move on instead of pretending we know how the world's gonna end up in 12 months when we can't.
- [05:30]
Benjamin Shapiro
Every time you say pivot, I think of Ross from Friends. I think we're about the same age. Hopefully this metaphor isn't lost on everybody. But imagine somebody moving a couch down a New York City city hallway stairwell and yelling pivot every 30 seconds. And that's kind of actually a good metaphor for where agile can help you, where you're making small tweaks along the way to try to go towards a direction as opposed to assuming that everything is going to be linear. So we want to get from point A to point B, but we're not exactly sure whether we have to go off road or whether we could take the highway, whether we can take the back roads. And agile allows you to, well, be agile, be flexible, be moldable in what your strategy is. So, all right, I want to get from point A to point B. I want to do things more efficiently, I want to be able to adapt to market conditions. Where do I start?
- [06:22]
Greg Kilstrom
So the alternative to the agile methods would be the waterfall method, which is we plan, measure twice, cut once. That kind of mentality of we're going to plan it out to a T and we're just going to go forward no matter what happens. And that's the goal. So the alternative to that would be an agile method. Something like Scrum is a common way of doing this. So you would work in, let's say, two week sprints to say, okay, again, we know what the end goal is. We know we want to build X piece of software, let's say. But how we get there, we're going to build only what we need, one step at a time. We're going to take a step back and look at what we did, how we did it, who's working together. Well, and even to use the metaphor that you used, you're planning a trip from point A to point B. Well, what if a new bridge gets constructed six months into your trip and it's a 12 month trip, you're going to take the bridge instead of walking all around or what? I'm going to stretch this metaphor pretty thin here, but you know what I mean?
- [07:16]
Benjamin Shapiro
I feel like the metaphor is what happens if the bridge falls down and you can't go over the bridge? Do you just stop? No. You have to figure out another way. That's where agility comes in.
- [07:26]
Greg Kilstrom
Yeah, absolutely. And it's also where being intentional, it's less about being reactive. And I think, you know that that's another kind of common misconception is being agile is just simply being, okay, this didn't work yesterday, so we're going to scrap everything and do something completely different. It's also, I consider it almost like a scientific method of we're going to build a hypothesis that, okay, we think this is the best approach. We're going to take it and run with that for two weeks, not too long, but not too short. We're going to see what happens, we're going to test it and then see the results. If it works well, we're going to keep building. If it doesn't work well, if the bridge falls down, we're going to find an alternate path.
- [08:04]
Benjamin Shapiro
Yeah, I mean, I understand testing the process in small batches, but if you're at a large company and you realize that you have process problems mostly in martech, I think that the executives listening to this are like, well, is it a tooling problem, is it a talent problem, is it a process problem? And saying, well, I'm just going to carve off this little tiger team and ask them to do stuff agilely. Is that really what works? Or do you just have to say, look everybody, we're going in this big methodology change and now we're all going to implement Agile. Can you be agile with your Agile implementation? Is that the right methodology?
- [08:37]
Greg Kilstrom
Having been involved in several large martech implementations at large companies, it's rarely the software that is the problem, it's the adoption and sometimes it's individuals or people in it, but it's often the processes that they're using. So you bring up a good point. Can we switch everything on day one? Two days ago we were like waterfall and like everything. Just planned out the old school methods of things and then two days later we're all agile. Probably not what MARTECH implementations sometimes or even. There's plenty of bad things to say about siloed teams and everything like that. But the good part is you can run a proof of concept or a pilot project with a team that is a little bit siloed. And say, okay, we're going to have this team work and do like two week sprints and scrum and stuff like that. Or let's say we're adopting a new martech platform. We're going to have the adoption of this run in sprints and planned out like that. Maybe the rest of the teams are still doing things as they were, but it's actually a good excuse to try some things out and adopt. And building into the process, the fact that you are kind of forced to do the same thing for a few days at a time and see how they work because nobody likes change. Everyone's going to say on day one, I hate this, it's terrible, whatever, but maybe on day five they kind of like it or they see the benefits of it. So like giving them two weeks to do it, it's not too long, it doesn't put the company at risk and yet it's long enough that we can as humans adjust a little bit to change.
- [10:02]
Benjamin Shapiro
Yeah, I think that people are adaptable and Martech solutions, hopefully if you buy the right ones, are adaptable as well. Can you share an example of where agile methodologies delivered measurable martech results?
- [10:14]
Greg Kilstrom
Yeah, I mean there's many companies that do this really well, but there's a few well documented examples. I often go to Spotify. I have not worked with them directly, but certainly read a lot and they're a great case study in this. They use some slightly different terminology than some of the like agile purists may use, but they use this concept of teams and squads and it's a very, as opposed to an, a very like vertical hierarchical kind of approach. It's more a networked organization of you work with a diverse group of people in the sense of diverse of like practice areas and capabilities. And so a designer and a software developer and marketer might be working on the same team. You know, like product marketing gets to benefit from working as the product is being developed and so everybody kind of builds these cross training for these different capabilities and people work together, they get to know each other and sometimes they, they stay on the same squad together, sometimes they move because of various reasons, but because they do this and these teams get to working so smoothly together, they're able to move really quickly and do things really smoothly. And I think that's a great example of instead of this top down hierarchy, the social media team doesn't talk to the email team or the engineering team doesn't talk to the data team or whatever. It's like, no, these are Just small teams that work together and get stuff done.
- [11:33]
Benjamin Shapiro
There's a nomenclature question here where you said teams and squad. Using Spotify as the example. I'm assuming a team is like the marketing team and the squad is what I might call a tiger team, but a group of functional area experts that get together. So you've got an engineer, a marketer, a finance person, a stuffed golf shirt to organize the meetings and somebody to write down what everybody says. And that's your squad?
- [11:59]
Greg Kilstrom
Yeah, I mean there's still like marketing departments and engineering departments. There's that concept, but the team is more like a product team that would be a larger group for a larger part of the product. And then the squads are exactly what you said is a kind of multidisciplinary team that works on an aspect of a product or something like that.
- [12:18]
Benjamin Shapiro
What I could imagine if a CEO of a mid market company comes in and says, hey everybody, we're going to squads and we still have some teams, there's going to be some pushback. What's the most common resistance you encounter when you're implementing agile martech operations?
- [12:33]
Greg Kilstrom
Just all of it. It's basically the stages of grief that we all go through.
- [12:37]
Benjamin Shapiro
We've got a 12 step program, we've got stages of grief. Come on, you're not really selling it here.
- [12:42]
Greg Kilstrom
I know, I know. So Kubler and Ross, I assume basically map this out of like the process that people go at work. The resistance to change and just the adoption of change are the same things we go when a loved one passes away or something like that. It's this just human thing of that. Hopefully it's not maybe as extreme, but it's the same stages of. I've been doing this thing for five years. You know, I was working with a very large company a couple of years ago and somebody in their role for 10 years at this organization just doing the same thing day in, day out. And then all of a sudden we come in and say, hey, we're going to make everything better and AI it and do all the other martechy stuff. And they're like, intellectually that sounds cool, but I don't want to be part of that because I know how to do what I do very well. And now you're telling me that everything that I've been doing is wrong.
- [13:32]
Benjamin Shapiro
You're going to make me work at work.
- [13:34]
Greg Kilstrom
Right.
- [13:34]
Benjamin Shapiro
I'll pass, thank you. I just want to run an automated playbook, not be stressed, know what I'm doing and press the same buttons all the time.
- [13:41]
Greg Kilstrom
Right. And so I think it's, you get those people and there's plenty of them. Nothing against them, but they're not the people that you really want driving the change. Then you do have other people that are excited and they're like, I read about all this stuff all the time, but I never get to do it. And now I'm getting an opportunity to do it. So you need some people that are going to dig in and like understand, process and embrace it. And those may be some of those people that are reluctant to change, but eventually do. But you also need some of those people that are going to be champions because they just want to learn stuff and they want to play with the toys and all that stuff.
- [14:12]
Benjamin Shapiro
So it's not really like losing a close family member, it's kind of like losing a second cousin. But eventually you get over it because you weren't that close to them.
- [14:19]
Greg Kilstrom
Yeah, you remember nice things. But it's like if you take work that seriously, then that's a topic of another show. Right?
- [14:25]
Benjamin Shapiro
Well, look, you're there hands on, doing the implementations and telling people that they have to work a different way, which at first feels like you're doing it with your left hand, assuming you're right handed. You've got to have a playbook for teaching people how to deal with change. So when you're sitting there in an organization and Joanne from accounting is pushing back on doing things a different way because she likes her filing system, what do you do?
- [14:49]
Greg Kilstrom
The very first thing you do is to involve them in the process as early as you can. Even knowing that there's going to be some resistance, knowing that there's going to be like, well, we've been doing it this way all the tropes. If this becomes something that some leader says, everybody's doing this starting Friday and they never heard about it, it's never going to work. I don't care what incentives you give, I don't care what the threats are. So always involve the people in the process. And you know what I've seen is they have some amazing ideas. Not all of them can be implemented, but they have some amazing ide is to make it better. And so there's lots of reasons to do it, not even just from the buy in perspective, but it's like there is a nuance that me consultant coming in would never know in a million years and might miss. But working together collaboratively, it's like again, it's not going to make them thrilled about the change, but it's going to make them feel part of the process. And what probably most of us know is like when you're part of the process, you get a little more bought in just by being part of that and voting on the changes and being part of the discussions and stuff. And that's the best way to win over the skeptics. Again, I think the people that are just curious by nature, that's a whole different thing. Sometimes you have to hold those people back a little bit and be like, hey, let's just get phase one or Sprint one or whatever done. Great idea, but let's put that in the backlog for now.
- [16:05]
Benjamin Shapiro
Let's talk about the opposite end of the spectrum. The operating rank and file might push back when you're starting to implement Agile changes. On the flip side, we're talking about MARTECH tools, which are inherently complex and you do these big, hairy, ugly installations and you kind of hope everything works so you can set it and forget it and start using the tools instead of implementing the tools, working in them, not on them. When you're at the executive level, how do you evaluate the ROI of using agility in collaboration with MarTech? The combination of those two things, how do you evaluate what actually works and whether it was worth the investment?
- [16:43]
Greg Kilstrom
So this is where time to value is a metric that's often used to just measure at the large scale, but I think it should be done at the micro scale as well. It is true what you're saying. Some of these big like monolithic systems, it's like you can't kind of use it. You either use it or you don't. But there are pieces to these systems and there are processes that can get better over time. And so one of the Agile principles is like, I'm paraphrasing here, but it's working software is the measure of success. So it's not like plans, it's not ideas, it's not somebody put something on a board somewhere, aren't they smart? It's working software. And so in the case of Martech, it's like, okay, well what can we do as quickly as possible, knowing that again, in these big installations we're not going to be running multiple parallel things because that costs money. We're not going to turn on a feature of Adobe or whatever because you kind of buy it or you don't. But there are ways to pilot small features or small campaigns. So I would still think, what is the most incremental way we can do this and show that to the leaders and get their buy in on that if possible.
- [17:47]
Benjamin Shapiro
Yeah, it sounds like feature utilization also up there. Are you actually using the tools? Adoption there's all sorts of metrics of whether your Martech tools are providing value that are not necessarily just back of funnel, bottom of funnel revenue and profit. It's the leading indicators are the tools getting used and then do they have value on the back end? And that wraps up this episode of the MarTech podcast. Thanks for listening to my conversation with Greg Kelstrom, the principal at the Agile Brand and the host of the Agile Brand Podcast. If you'd like to get in touch with Greg, you could find a link to his LinkedIn profile in our show notes. Or you could visit martechpod.com of course, you can visit his company's website, which is theagile brand.com and if you haven't subscribed yet and you want a daily stream of marketing and technology knowledge in your podcast feed, hit the subscribe button in your podcast app and we'll be back in your feed or on YouTube next week. All right, that's it for today, but until next time, my advice is to just focus on keeping your customers happy.
- [19:00]
Greg Kilstrom
Foreign.
- [19:12]
Benjamin Shapiro
Thanks for listening to the Martech Podcast and I hear everything. Production Looking to launch or scale a podcast like this one for your brand? Then visit iheareverything.com.