{PODCAST} In-Ear Insights: Applying the SDLC to Marketing Operations

In this week’s In-Ear Insights, Katie and Chris walk through the software development life cycle – the SDLC – and how we can apply it to marketing operations. From Data Studio dashboards to Google Ads to SEO, the overall process behind the SDLC applies well to any kind of marketing operations that require planning. Tune in to learn more!

[podcastsponsor]

Watch the video here:

{PODCAST} In-Ear Insights: Applying the SDLC to Marketing Operations

Watch this video on YouTube

Can’t see anything? Watch it on YouTube here.

Listen to the audio here:

Download the MP3 audio here.

Machine-Generated Transcript

What follows is an AI-generated transcript. The transcript may contain errors and is not a substitute for listening to the episode.

Christopher Penn 0:17

In this week's In-Ear Insights, we're talking about the software development lifecycle, the SDLC.

And when you hear that phrase, one of the things that may spring to mind immediately is, you know, coders hacking away at at 1000s of lines of code.

And, you know, drinking Red Bull.

And in marketing, were probably like, well, how is this relevant to me, because I'm not doing development of software.

And yet, I would argue every single time that you make a dashboard saying Google Data Studio, or you make a report in your the social media marketing software of your choice, you are, in essence, creating software for somebody else use you may not be writing code.

But every time you're assembling bits and bytes of of technology for somebody else to use.

You are doing software development.

So Katie, you manage teams of developers, you've managed software development life cycles, can you walk us through the general process, and then how we should be thinking about it in terms of marketing?

Katie Robbert 1:27

Well, and that's just that the SDLC, or the software development lifecycle is just a process.

And a process is something that you can adapt to any team, any industry.

And that's the way I've always looked at things like the project lifecycle, the product lifecycle, the software development lifecycle.

At the end of the day, they're all roughly the same idea, which is you start with the why, what are you doing? Why are you doing this? Your business requirements? What's your purpose? You know, depending on what you're doing, you might need a set of data requirements or technical requirements.

And that's generally one of the differences with the software development lifecycle.

So you do your business requirements, what is the business need, then you do your data and technical requirements, what does the development team need, then you have, you might have a design phase, depending on what the thing is meant to be.

And if not, then you might move on to your development phase, which is where you start doing, you know, your proof of concept, you do your information architecture, you build your databases, you're basically setting up the foundation based on the previous set of requirements that you've been putting together of what this thing is.

And then you start actually doing the thing.

And so you start building it, you're doing your sprint planning, you're doing your Agile methodology, you're doing your two weeks and your scrums and you know, all of the different pieces, so that you can say, Okay, we did it, it worked, or we did it and it doesn't work, then you need to roll in your QA testing, quality assurance and quality control.

Someone who isn't the person building, it should be testing it based on the business requirements, the data requirements, the information architecture, the development plans, and saying, yes, you built the thing that you said you were going to build, and it works as expected.

And then you can start to roll it out and go into maintenance mode.

And so it's, you know, at the end of the day, that process is roughly planning, execution testing, starting over again, with maintenance and going through the whole thing, like what did we learned.

And so that process was critical to our engineering team when I was managing them, because it gave them a sense of predictability of like, here's what I'm doing, versus I'm going to go down a rabbit hole and just start developing and, you know, pushing things together and building databases, not really having a sense of what's going to happen.

And then you find out at the end of the week, well guess what your whole budget is blown, because nobody knew what they were doing.

And that's really the goal of the SDLC is some predictability, consistency, the planning so that you know what you're doing, you can put your resources in for places.

Now where that fits into marketing.

I would I would argue anywhere.

I would say that anything you're doing, you can follow a similar version of the SDLC.

Christopher Penn 4:30

Okay, how about then a Google ads campaign? How would you how would you shoehorn the STLC into into a Google ads campaign?

Katie Robbert 4:40

Well, you would start with your business requirements.

What? Why is it that you need to do Google ads for your business? What is it that you're hoping to achieve out of it? So what are the business goals of a Google ads campaign? And so maybe it's awareness, maybe it's conversions, but stating that purpose right up at the front is going to help you understand the rest of the cycle.

So you start with your business requirements, then you move on to your technical requirements, which in this case are really the ad requirements.

What do you need? Well, you need the platform, you need Google Ads set up, you need Google Analytics set up so that you can measure things correctly, probably Tag Manager as well.

Then you need your ads themselves, you need your coffee, you need your call to action, you need your creative, you need your audiences.

And so that part of the requirements gathering is really just helping you get organized, have, these are all the things that I need before I even get into the system, and start putting things in different places.

Because once you start putting the ads together, that's where you can accidentally start spending money that you didn't need to spend on the ads themselves, because you weren't fully prepared to run the ads.

And so that requirements phase is universal across any project of what is the checklist of things that I need to get organized.

So then you can get into the development phase, which is putting the ads together testing something seeing, is this ad going to resonate? Is this ad even make sense? Let me do an A B test.

Once you have that development phase done, then you go into essentially QA or the measurement phase in this sense of did it work? Did we build the thing that we say we were going to build? Is it working as expected? Okay, let's roll out more of it into production.

So that's how I would approach the SDLC with something like Google ads.

And it really always starts with requirements of why are we doing this thing in the first place? And what do we need to be successful?

Christopher Penn 6:40

Okay, what about SEO? How would you apply it to SEO? Since it's it's a very different application?

Katie Robbert 6:49

Absolutely.

And so I would start with the same kind of requirements of what is the goal of SEO? And we talk a lot about SEO.

So what specifically about SEO? Is it that you're trying to do are you trying to fix up your site? Technically? Are you trying to rank for specific keywords? You know, are you looking at your competitors? Are you trying to get backlinks? And so that set of requirements is going to help focus whatever the SEO project is, because if someone came to me and said, Go do SEO? I'd be like, cool.

What does that mean? Like? It could be a wide variety of things.

And so starting with those requirements, let's say, for example, we were talking last week about backlinks.

Let's say that the purpose of the project is backlinks.

So you would do your current as well, what do you need for that? So you probably need content.

So you if you don't have content, start there.

And then you need your list of places where you would like your content to be linked.

To come back into your site, you need a way to measure it, which is probably Google Analytics.

And then you also need your measure of success.

How do you know that you did the thing.

So that comprises your requirements, then you get into the development phase, which in this sense, is really putting the project plan together to say, here's my content, here's how I'm going to get it on somebody else's site to backlink to mine.

And maybe that's through guest blogging, maybe that's through pitching, but that's when you start to do the thing.

And then in the QA, you know, you're looking at your measurement, did it work, and then you know, lather, rinse, repeat.

So you can really adapt the process to any kind of project, I think where people get hung up is what these phases within the SDLC are called, well, this is data requirements.

Well, I don't have data, this is development, well, I'm not developing anything.

Well, this is QA, I'm not testing anything.

Remove the traditional definition.

So those things and you can apply it to any project that you're doing in your marketing or in anywhere in your business.

Christopher Penn 8:54

When is the SDLC the wrong choice? When does it is it a methodology that is inappropriate for the situation?

Katie Robbert 9:06

So really good question.

And I think that if not the SDLC, it would be an inappropriate choice, I think how deep you go into a version of the SDLC is where it would be an inappropriate choice.

So you can make it you know, a just a high level, you know, planning, execution testing, you know, maintenance, and that I feel like is generally always appropriate.

But when you start to really get into the nitty gritty of business requirements, data requirements, technical requirements, design requirements, database requirements, all of those things.

Getting too deep into the weeds, when it's not really going to apply is when it could be inappropriate.

So really trying to fit your project into the traditional structured SDLC is What might not be working? And that might be why people feel like they're not finding success.

So I feel like the general process of planning, testing that's always appropriate.

Christopher Penn 10:12

What about in situations where you have sort of a pre baked playbook because I was thinking one of the situations where it might be inappropriate would be something like crisis communications, where, you know, your CEO has gotten arrested for something or whatever.

And at that point, you don't want to be planning a testing, you want to have a pre baked playbook that you just roll with.

And you just press go and you don't look back.

Katie Robbert 10:32

Well, you know, with that, I could argue that in getting to that playbook, you probably followed some kind of a process in order to get to the playbook.

So once you have the playbook that's really considered maintenance.

And so you're basically just grabbing the thing, it's in production.

But to get to the point of having the playbook for your crisis.

Comms already, you probably had to follow some kind of a process which includes requirements gathering, okay, let's say the CEO went outside mooned everybody.

Yeah, we need to play out.

What do we need for that? Well, we probably need a big black tarp, we probably need a lot of whiskey.

And we probably need a lot of money for bribing people.

Okay, so that's my set of requirements.

What do we do from there? Okay, and then you like, so the process at that sense has already played out.

And you're really in that production slash maintenance phase, when you grab the playbook off the shelf, and like flip to page 56? And go, Okay, we're executing plan Q.

Got it.

Christopher Penn 11:37

As a whiskey black tarp and bribery sounds like a mafia hit?

Katie Robbert 11:43

Well, I mean, it depends on the on the situation and who it was the mood,

Christopher Penn 11:48

I suppose.

When I was, I suppose more appropriate, when you're looking at past implementations and things, whether in marketing or software development stuff? Where do things go most wrong?

Katie Robbert 12:04

Lack of requirements, lack of planning.

This is the 10 times out of 10 problem when software goes sideways is someone just wanted to get in and start messing around with the with the tool, shiny new object, press the buttons, what is this thing do? Like someone just wanted to do the thing? And there wasn't enough time spent on the planning? So the planning involves? What are we doing? What's the measure of success? How are we going to test it? How are we going to roll it out? How are we going to communicate this thing? So it's the most to a lot of people, it's the most boring and laborious part of the project.

The reason why it's necessary is because it saves you so much time and energy and headache and money, when you actually get into the development thing.

Software development, and then trying to roll it back is really expensive, especially the types of projects where it could affect your website.

You know, let's say you don't have a rollback plan for your website.

Well, that's something you probably would have determined in your requirements.

What happens if we let Katie, you know, play with the buttons on the website? And oops, there's no more website? Is there a rollback plan to say undo everything that Katie just did? Well, let's say there's no plan at all.

And nobody knows that Katie is touching all the buttons on the website that's even more problematic.

So I would say the lack of planning and lack of testing is where software goes wrong.

Everybody wants to just get in there and do the thing.

Nobody wants to build all the documentation around it.

Christopher Penn 13:45

Yeah, why do we need documentation? It's just a lot of extra paperwork.

Okay.

That's why I play devil's advocate.

Katie Robbert 13:54

I know.

Well, you know, and I think that that's the other misconception is it doesn't need to be months and months and months of sitting in a room and writing things down.

And you know, detail.

Like, you need to have a general sense.

So let's say, Chris, you came to me and said, I want to develop a new piece of software that is going to give me a predictive forecast and make my coffee.

I would say that fantastic.

Why are we doing this? So let's have a goal.

Let's understand the basics.

So why are we doing this? Who's going to use it? How are we going to sell it? How are we going to maintain it? What do you need to be successful? And if we can answer some basic questions around the thing, then we've done our job in terms of requirements.

And so as we're getting into those questions, it naturally is going to have you as the person developing the thing think, Hmm, how do I connect my our scripts to my coffee maker to get the coffee to be made as it's running and predicting my marketing And so those are questions that you want to be able to answer before you get into doing the thing, because it could take you six months to figure that out.

Or it could take you two days to figure out, it's never going to happen.

Christopher Penn 15:15

Okay? How soon? Do you know that a project is headed for failure? Like, if you do determine that, do you see that shape up in requirements gathering, when you go wow, this is really just not gonna, not gonna work?

Katie Robbert 15:29

You know, there is, it's, it's especially in software development, it's nearly impossible, not completely impossible, but nearly impossible to know every single gotcha in the requirements.

And at some point, you need to start doing the proof of concepts.

And so that should be built into your project plan of let me just try out this little thing and see if it works.

So you are, you can be doing the software development in parallel with the requirements, building the data requirements, but it's done in a very small controlled phase.

That's how agile methodology came about.

It's those two week sprints, and the sprint is basically two weeks worth of work.

The goal at the end of the two weeks is to have something tangible, something that you can demo to other people to say, this is what worked.

And so at the beginning of sprint planning, you say, this is the goal of this two week development phase, our goal is to determine whether or not this button right here is ever going to work.

Or this script is ever going to connect to my coffeemaker.

So you build that into part of the planning, you can do that proof of concept testing before you get into the full thing.

But because it's concentrated into those two weeks, you need to be super focused, you can't say, will the whole project work? I don't know.

But there's elements of it that you can start to test.

Christopher Penn 16:57

How do you deal with that when you have a a, a on on known large, third party dependencies.

So let's say we're doing that Google ads campaign, we've done a requirements gathering, we've built our ads built our landing pages, we've done our best to check our quality score.

But one of the gotchas with Google ads is that at different spending levels ads perform differently, once you get over certain hump see, within the ad system, it becomes almost a different product.

And we know that the production campaign should have will have to function like a budget of $1,000 a day.

Whereas a test budget, you might say, Okay, let's test $10 a day and see what happens.

But we know from just the way the system works, that you will get different results.

So there's a you know that the result and and criteria you care about is at that $1,000 level.

But that's a big risk to take how do you use this SDLC to mitigate that risk? Or is it one of those things where you just do the best you can up to that point, just hit go and hope it works out.

Katie Robbert 18:05

So honestly, it's a little bit of both.

And so you can do some testing, but you would need to scale the testing down to be appropriate to that $10 a day.

So, you know, if you're saying with $1,000 a day, you can reach a million people, you have to reset your expectations to what can $10 a day, right? You can't get the exact same results with a smaller, you know, bucket of money.

And so you have to sort of rethink like, what is it that I'm testing? Am I testing? You know, do does this headline work, before I put it in at $1,000 a day is anyone responding to it.

And so rescaling resetting your expectations down to what's appropriate for a testing pool is going to help you be successful.

Now, there's going to be some cases where people say we don't have time to test, we just need to get that out there.

Okay, resetting expectations, again, saying, We don't know what we don't know yet about what $1,000 A day is going to do.

And if we as a company are okay with that sunk cost, then we can go ahead and do it.

Again.

It's it's all about just being transparent, and saying, This is what we can and can't do.

So in that scenario, you know, there's not a whole lot outside of just going for it, you can do all the preparation, but until you actually push the button go, you may not really know what's gonna work and $1,000 a day might have to be that level that you're testing out.

Christopher Penn 19:36

Okay, one thing I noticed is kind of missing in the SDLC.

As we're talking about it, it's obviously very process driven.

And that's a processes at the heart of that.

We see a lot in requirements particularly business requirements and data requirements about platform you know what you're going to choose what language you code and stuff.

I don't see people mentioned anywhere so the trifecta, you know, people process platform Are the people in the SDLC? Is it assume that at beforehand that you've already got the right people and that people aren't a concern?

Katie Robbert 20:08

The SDLC is definitely flawed, as are a lot of processes.

People is what's left out of most of these things.

So it factors in process and platform to your point, Chris.

And so that's something that we, you know, you and I have become more aware of as we've been doing it.

And so if you're following the traditional SDLC, no, people are not factored in.

But that might be a section that you build into the SOP of based on the requirements that we've put together, do we have a database architect? Do we have a QA engineer? Do we have, you know, an Information Architect? Do we have, you know, a creative designer? Or do we just have one person who magically has all of those skill sets? And if you do, please introduce me, I would like to meet them.

You know, so you can build that into your business requirements process of, okay, here's what the business needs.

And here are the people that we need to execute it.

But you're absolutely right, the SPLC, the PLC, you know, all these other processes.

They tend to not think about who's actually doing the work there.

It's just assumed like, Okay, if we're doing development, we have developers, if we're doing QA, we have QA engineers.

Christopher Penn 21:22

Why are the people missing from a lot of these processes?

Katie Robbert 21:28

I honestly don't know the answer to that question.

I don't have a you know, back in 1932, when, you know, Simon Huzi whatsit developed the process, you know, he was thinking, you know, I don't I honestly don't know the answer to that question.

I can tell you from my experience, that, especially when you get into more technical projects, people are the last thing you're thinking about, you're thinking about making sure you're getting the data set up correctly, you're making sure you're getting, you know, the code functioning in an in an efficient way, so that when you run a SQL script, it doesn't break and send you 100 errors.

The people has always been somebody else's problem, let somebody else worry about who we need to do the work, I just need to make sure I've outlined the project correctly.

And so I think, in general, companies tend to just forget about, okay, this is great, you've dreamed up this wonderful thing, you don't have anybody to do the work.

So it's, it's a common problem.

It's, it should be a solvable problem.

But we tend to forget that behind all of this technology, and marketing and data are people who actually have to do the work

Christopher Penn 22:42

is that because of the relative in elasticity of people, like with a process, you can change process at your whim.

With technology platforms, you can select a new vendor relatively quickly, but with people you're kind of stuck with who you're hired,

Katie Robbert 22:55

that could that could definitely be part of it.

It could also just be a blind spot in terms of thinking through, is this even appropriate for the team that I have? Is this something that they can execute? I think there's this in the companies that I've worked at, there's always been this mindset of, it doesn't matter what skill sets the team has, they'll figure it out.

And so maybe that speaks to your inelasticity comment.

But yeah, there's always been this like, well, let's just give them this project.

And they'll figure out how to do it the way that I exactly want it done, even though they don't have the skill set for it.

So then I can go get mad at them when they don't do the thing.

Exactly.

Christopher Penn 23:37

Do you experience do those folks? Figure it out?

Katie Robbert 23:39

It depends.

Sometimes, yes.

Sometimes no.

And then that then becomes the responsibility of the team to speak up early and often to say, hey, you just gave me.

You know, we're a technology team.

And you've asked me to bake a souffle.

So yeah, I'm gonna try.

But I'm going to tell you right now that that's not my skill set.

And you should probably get someone in here who actually knows how to bake a souffle.

Um, my time is better spent on building code.

And so it has to be a conversation as well.

And so that is also where things fall down as people don't want to have those difficult conversations.

Because maybe the culture is such that, you know, if you speak up, you know, you're likely going to get fired, or it's just, you know, I just need you to do the thing.

We'll worry about how it gets done later.

Christopher Penn 24:26

Okay, cuz I'm thinking like, we look at people's Google Analytics, installs, for example, very often, someone is in charge of it, who is not a marketing data scientist or a marketing analyst or somebody who has a strong background? First, for one reason or another, they can't figure out why there's this assumption because Google Analytics is free.

It must be easy to use, and therefore everybody should know it.

And you know, you and I both know that is that's ridiculous.

You know, Python is a free programming language, and it's not easy to learn and it's It's not something everybody can do.

You know, technically surgery is free to learn.

And you know, it's just a bunch of knives.

So how hard can it be? There's, there's obviously, clearly some nuance there.

Why do we have such a blind spot about? People, particularly when it comes to like marketing technology is because marketers already are not very technical people to begin with?

Katie Robbert 25:25

It's a great question.

Um, I think that there are still some older assumptions about what marketing actually is, I think that there's this, you know, Mad Men era, let's all sit in a room be super creative and come up with great ad.

But then now, as I'm saying, Now, it's, you know, been a couple of decades now, as we move towards the internet.

You know, digital marketing is very different from traditional marketing, in the sense of how you are executing these campaigns and how you're measuring these things.

And so, you know, before, if you just needed to get a placement in, you know, a newspaper or on a TV, you know, a commercial, you know, the process is going to look very different.

And the way in which you're measuring is going to look very different from putting together an email newsletter, or a set of Google ads.

And a lot of companies haven't made that transition into what you really need to do to set yourself up for success with digital marketing.

You know, we've done episodes, just specifically around email, and the amount of technical setup and maintenance that goes into email marketing still blows my mind of what I don't know about how to properly use email marketing, because I think there's, there's a lot of services like a substack, or, you know, something else, where all you have to do is write the content, and they deal with all the stuff.

But if you want to do it yourself, you, you know, have to do the servers and the deliverability.

And you know, all the other maintenance pieces that just aren't taught anywhere, you don't go to school, you don't go to grad school and go, Okay, teach me digital marketing.

They don't necessarily get into those weeds, they might now, but when I was in grad school for marketing, I learned none of this.

I learned Porter's Five Forces, and, you know, some other process, but I'm never going to use

Christopher Penn 27:25

it.

But you mentioned that example, with email marketing, you know, that you don't know, when you look at something like the SDLC? How if can you account for a thing for not knowing what you don't know, for example, let's say we're using the SDLC with Google ads.

And we do our requirements, we deploy the thing, whatever.

And we don't know that we don't know that we should have had, like a sensitivity reader or a cultural checklist in the requirements phase to say, Hey, don't make sexist ads, right? That there's that massive blind spot there.

How do you accommodate for that? Particularly? You know, it's, it is a problem in in software development, certainly.

But it's a much bigger problem in content marketing, where people are creating content, not realizing they're doing things like cultural appropriation, or just outright sexism or racism or something like that.

And the people who are assembling the requirements, don't know, but they don't know that's a problem.

Katie Robbert 28:30

And that's okay.

Not the sexism and misogyny and all that stuff.

That's not okay.

But the not knowing what you don't know, is okay, that's part of why I always encourage an agile methodology, because it's shorter amounts of time, and then testing.

And so as soon as you finish that two weeks or one week, you immediately start testing and, you know, seeing the results.

And so if you've set up your measurement plan correctly, you should be able to find these things out pretty quickly, before doing too much damage to your brand reputation.

And so you may not know what your ads could get flagged for.

But you should know that the possibility of your ads getting flagged in general could exist.

And so, in that scenario, let's say our ads get flagged, we don't know what flagged for what do we do, how do we adjust? How do we pull them down? What is that process? So you may not know everything, but you should know enough to play out the scenario of when something happens that you weren't aware of.

Christopher Penn 29:39

So if I'm a marketer or a marketing executive, how do I get started using the same what's my next steps?

Katie Robbert 29:45

How do you get started using the SDLC? Well, I guess the first the first thing you would want to do is you know, pick a project to test it on.

So you With any process with any kind of change management, I've never seen a company or team be successful, when they just introduce a new process and say, we're all going to do this thing.

Now we're all going to use it.

We've never tested it, but it's going to be the thing that, you know, fixes our company, I would say start small.

So, you know, Chris, I don't know, I don't remember if we were talking about it, before this podcast, but we were talking about Data Studio dashboards.

That's a great place to test out a process like the SDLC.

To see what does that look like what won't work for our organization, if we try to follow a process like the SDLC, with a lower risk development project, like a Data Studio dashboard, where rolling back changes is fairly straightforward.

It's literally probably just, you know, removing a widget, you know, and tested internally on your own stuff before rolling it out to clients and other vendors and other customers.

And so I would say start with a proof of concept of something that you have a lot of control over so that you can really explore the phases of the SDLC to see what's going to work, what's going to hang up, and what is never gonna be adopted by our organization.

Christopher Penn 31:15

Alright, well, if you've got comments or questions about how you use processes like the SDLC in your marketing, or you've got some experiences you want to share, pop on over to our free slack group go to trust insights.ai/analytics For markers where you and over 2200 other marketers are asking and answering each other's questions every single day.

And wherever it is you watch or listen to the show if there's a challenge you'd rather have.

Most of them are available at TrustInsights.ai dot AI slash T AI podcast.

Thanks for tuning in.

We'll talk to you soon

Need help with your marketing AI and analytics?