AI Was A Waste of Time, Until It Wasn't with Megan Boshuyzen

Email development has a reputation for being a place where good design goes to die buried under client rendering, quirks, dark mode, disasters, outlook, period and code that would make a web developer weep. My guest today has not only survived that world, but she's thriving in it and she's using AI to do it smarter. Welcome to the hot seat. I'm Jacqueline Friedman, founder of monarch, and we're about to get into the real, unfiltered truth about what AI actually does and absolutely does not do for email developers right now.

But a little bit about her first Megan Bush. Howson is the development lead at Inbox Army and one of the most respected voices in email development today. A graphic designer by training, she made the pivot into code and she never looked back, overseeing email development at gmail, jet and email on acid before landing her current role. She's also a founder of a publishing house, a youth soccer coach, and a politician.

Talk about the ultimate multi-hyphenate right here. She spent years proving that email done right is not a relic. It's a competitive advantage. And at the moment, when every marketer is just being told to use AI, it will solve everything.

Megan is one of the few that's actually doing it, stress testing it, and also telling the truth about what she's finding out. So welcome, Megan. Thank you for being here. Thank you for having me on.

All right. To dive in. Let's start with a couple of rapid fire questions. What was your first martech tool?

The first tool I used was an ESP called Vertical Response back in 2010. I don't know that one. My first emails that I designed, my first email in 2008. I sent my first email designed and sent out myself in 2010.

I had no idea what I was doing. Wow. And that's what the company I worked for used. Amazing.

Okay. All right. Here's a myth I want you to bust or defend. If you can write a good prompt, you can build a good email without knowing how to code.

True, false or dangerously oversimplified? I would say it's dangerously oversimplified because it's getting better, but unless you write that prompt correctly and you're extremely prescriptive, it's not going to give you what you need. That sounds right, but also sounds applicable to pretty much any and all prompts after a couple rounds, basically. Yep.

Okay, so you started up as a graphic designer and now you're an email developer. What broke first your patience or the outlook rendering engine? Definitely my patience because of the outlook rendering engine. Touche.

I mean yeah outlook. It's a lot of a lot in this episode. Oh, well. Oh, wow.

Um, okay. Dark mode. Gift curse or just an ordinary Wednesday? Just an ordinary Wednesday.

Something we just deal with. And we keep moving. Yeah. If only everyone thought that way.

I know you didn't try to force it. You got to follow where the users at, so should be dealing with it if you're not. Exactly. So if you could magically delete one thing from email development forever, a practice tool, bad habit, you name it, what would you get rid of?

Outlooks. Word rendering engine. Fair I'm glad I hit that fixes so much. It's coming soon.

Soon, but not soon enough. Not exactly. Nothing is soon enough. Well, I want to set the stage and really just establish where we actually are.

There is so much noise right now about AI transforming every creative and technical discipline overnight. I mean, I've got horror stories for days about good, bad, ugly. And because you work in email development, it's notoriously stubborn, like table based, client dependent. It's stuck in the 90s and it's very, very unforgiving.

I mean, I've coded emails. I would never call myself an email developer, but I'm pretty capable. And it's a thankless job. So to set the stage when you started using AI tools like Cloud Code or others in your workflow, what specific problem were you hoping to solve and actually did it solve it?

Yeah. So when I first started using it, it was to actually help me with liquid. I am not using it with email code at all. I find that you have to be so prescriptive with the prompts to use it for email code, that I might as well just code it myself, because I just have things already created that I can throw together.

But I came up against a really unique situation where I needed some robust liquid to be written, and I like knew 90% of the way there what I needed to do, but I needed that extra 10% of help. So this was I started with Gemini before moving to Cloud Code, and I went back and forth with Gemini to get what I needed for it to work, because in this situation I had to dynamically display products, but the products were not being housed in a CRM, and the instruction from the client was that we could not house it in the SP or CRM.

So I had to take a lot of information and have it loaded like via liquid in the email, all the information in the email, and then match it up to a code that was in the SP and do some really intense, like if else type stuff I think we used when with liquid in the end to display certain products. That was really intense. Yeah, I would not have been able to do that without the help of AI. That makes sense.

And I guess, as a slight aside, do you consider liquid harder than handlebars? So I think once you kind of know how it works, it's just looking at documentation. And each SP is a little bit different in how they implement anyway, and maddening. Can we please have some standards in general?

That'd be nice. What is your hottest take? It is the hot seat after all. My hot take is that ISPs and email builders of the drag and drop variety need to take a larger responsibility in making sure that their code itself is accessible.

When we see a lot of emails fail basic accessibility checks, a lot of times they're out of drag and drop templates. And email marketers who do not code cannot access that code. And even if they could, if they wouldn't know what to do, it has to be on the companies to implement those changes and educate their users on how to utilize those features. It's not enough for us, the users, to keep telling the companies that we want these to happen.

We've been asking for this for years, and it feels like all that feedback goes into a black box, and it feels like it feels like an abyss, right? Yes. So we really need product managers to step up, go to the engineers and say, hey, this is important. Please, let's make this happen.

And in my opinion, in a lot of cases, it's not a big lift. I agree, like some of the really basic stuff is because sometimes you think something's simple and you go to engineer it and it's actually really hard. But some of these fixes are they're so easy. They are not big engineering lifts.

So I really encourage email service providers and the email editors that they're mostly white labeling to talk and look at their product seriously and see how we can make that code more accessible so that users can have the best experience possible from building the emails and then from reading and interacting with the emails. 1,000%? Yes. And to your point, it's very similar to me not to go off topic, but to sustainability and environmental practices.

Like right now the onus is on individuals, but actually it's the corporations, the companies that are sort of the largest. So why are we shifting blame or shifting responsibility more than anything? And so yes, I agree. Yes, even the basic contrast ratios, you can do that.

It's easy. I end up having to do it elsewhere. But it is not a difficult task. And it can be chipped by chip, you know, starting with contrast ratios, then going into alt text, then going to X, Y and Z.

I really just want to see I want to see ESPs add in the ability. And I think some do this, but not all. We need to be able to add the ability to set your language attribute. Yeah.

And you need the ability to set your direction attribute, which is one that I think a lot of people don't think about, because that so much of us are working in English or a language that runs left to right. What happens if you're in in something like Arabic or Hebrew? I've been there. You have to custom code all of it.

A Japanese can be vertical, but also like and like Japanese and Chinese can both be, you know, written in several different ways. What happens when we're going up against those types of languages? The ESP needs to know if if the sentence is written in the other direction, or I should say the inboxes do for screen readers and whatnot, so that that stuff can be read in the correct direction. Um, so those are two very easy ones that I actually called out specifically at on spam when I was there back in April, asking the ISPs to start taking a more serious look at this.

I don't blame you. It's not just accessibility, but it's also inclusivity, Right. I have been that person who's coded those templates for other languages that are right to left, not left to right. And I was only able to do that because I know how to code.

Right. But other than that, there was no opportunity regardless of the email editor or Wysiwyg options. Right. Like, one really quick example is like if you're using Hebrew and the SP thinks you're doing a left to right language, it'll put the letters in the completely wrong order and the word will be written backwards.

Correct. I've seen that happen, and that's happened while I was making the email where if I'm doing something in English, I have to throw some Hebrew in there, because I worked for a nonprofit way back when. That was where it was required to do things like that for our audience. You would just see weird things like that happen.

Yep. That tracks and it's like, hey, please structure it so we can have different sections that are related so that we can have an alignment all across. It's not hard. Just modularized it.

Please. Yeah. Yeah. All right.

We're already kind of jumping ahead to getting nerdy, but before we go back in. So when you look at how AI is being positioned as a solution for email development, what's the gap between the marketing pitch and the actual workbench reality? I think I guess I will start with that. I think it's so important for designers and developers nowadays to have a little bit of cross training, or at least high level knowledge of each other disciplines, because I think what can often happen is that a designer who may or may not have experience in email design, because a lot of times it can just get added on to a designer's plate as like an extra piece of responsibility, which is the way I got into email.

I was the graphic designer and I also had to design graphics for email. Um, they can sometimes put together layouts that may not be Easy to code in email or not work how they intend an email. I see this a lot with Figma files where like a custom font is being used and the fallback isn't taken into consideration necessarily. Or there are lots of rounded corners, and people need to know that rounded corners are a progressive enhancement.

Therefore, it's not going to be rounded in outlook. And yeah, it's just knowing those little things I think is so important when designing for email. And you only know that if you've studied both disciplines. All right.

So here is a tension I really want to name. We've got on one side, marketers who are terrified of code and hoping AI is finally the escape hatch. The the the answer to all the things. And then on the other hand, you have developers who are worried about getting cut out and being replaced.

Where do you land in this matrix? Is AI democratizing email development, or is it creating a false sense of confidence in people who don't know yet what they don't know? In a way, emails are democratized, right? Like, people don't need to know how to code to create an email.

And there are pros and cons to that. And I think what we are going to see is people who only code, email and don't know how to do anything else. They might be the ones who get pushed out. Hmm.

That makes sense. What I think people or developers are going to need to do is broaden their knowledge a bit more. Maybe start learning some JavaScript. Start learning systems thinking the push is really going to be towards, I think, email design systems in enabling people to rapidly create emails and to be able to make those systems as robust as possible using other programing languages.

I think that email developers won't be needed for those smaller companies that mostly are already not needed for smaller, like small businesses, they can get away with drag and drop. Even medium sized businesses can get away with drag and drop. And I think the more technical folks are going to really show their strength at a larger enterprise level, where we have Salesforce and Marketing Cloud and Braze and customer IO and how powerful all those systems are, you're going to need someone technical to be able to connect all the pieces in a way that makes sense, and I just think that's where things are heading.

But I always also say that we all can take a picture with our phones, but you still hire the professional photographer for the things that matter. So for the things that matter, email developers will still be needed without a doubt, and their technical knowledge will be so important. Now that makes total sense and I'm in full agreement. Yeah.

It's interesting. I think this also kind of delves into this new. It's an interesting narrative that's happening where folks are hesitant with all the different and rightfully for some engineer title getting added to everything. However, marketing engineer in my eyes, is actually a real thing, and it has been for a very long time.

And it's it's a perfect medium. To your point, it's either the engineers or the the developer. Excuse me, gets to learn a little bit more about the marketing side to be more helpful and more cross referential and collaborative. And also it's an opportunity on the marketing side where it's a little bit more creative or strategic to start learning a little bit more.

And so it's almost like martech and maps are the future of everything. Just kind of say I'm bullish on that, clearly, but that's how I think about it. Yeah, I think email developers need to look at becoming a strategic partner instead of just, oh, I'm the email developer I just missed in the code, right? I truly believe understanding the strategy behind things and the design and the why allows you to strategically help make a better email and a better product.

Like it's important to have a holistic view of whatever you're doing. Totally 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, High Touch, the leading composable CDP and AI decisioning platform companies like Domino's, chime, Erica, and PetSmart trust High touch 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 high touch to personalize every customer interaction at scale. See what high touch can do for you at high touch.

And now back to the hot seat. Okay, we've already been getting nerdy, but let's get extra nerdy. Walk me through a real use case. Specific, not hypothetical.

I'm sick of hearing everyone's. I'm doing things, and I want to know where Claud or Gemini genuinely made your development process faster or better. We've talked about the liquid example. I want another one.

What were you building? What was the prompt and what came back that actually worked? Yeah. So I've been using, uh.

Well, first of all, I've been using Claude code, just released routines, and they just change it so that you don't have to hook it up to a repository, a GitHub repository to use it, which is helpful. I actually started using that to kind of start turning Claude code into a sort of pseudo executive assistant to me. So like I have it. So like because I'm at an agency, I have to track all my time.

So like I have to do things like track my meetings, which means a task has to go into my project management system to track that time. But like, I don't want to spend the time to look at every single meeting that I have and create a task to put it in there. So now Claude checks my calendar a couple of times a day, sees if any new meetings have shown up, and if they have, it creates the task for me in my project management system. I also have it giving me daily debriefs to tell me everything that's going on that day.

That is something I've been dreaming about having in my life. It's something that can just tell me everything that's going on at the beginning of the day. What's going on with my entire day? Work, personal, everything.

Just tell me so it tells me literally everything I do. A shutdown at the end of the day that tells me what's coming up, which is nice. And then I've been using it a lot for JavaScript help. So I know enough JavaScript to be dangerous, and I can usually get myself 90% of the way there, but then like miss something really small and critical to make the whole thing work.

So Claude Code's been helpful as kind of like a second quote unquote developer to be like, look at this file or look at this code snippet. It's not working for me. Why? And then it'll explain to me why it's not working.

And a lot of times it's like, oh, you're referencing the wrong object or oh, you forgot you need curly brackets here or something like that. Yeah. Something so minute. But right.

That's easy to miss. Um, because I've been working on this really big email design system that's just getting more complex by the day. I want to know more. Oh, man.

Yeah, it's it's getting by. Yeah, by the day. It's getting more complex. It's cool.

It's a it's. I thought I was just going to be kind of taking things I've built in the past and knew what how to do and just implementing it at a new job. So I guess for background, for anyone who doesn't know, I'm new to the agency world. I started in Inbox Army in September 2025.

My goal being to make my first big project goal was to make an email design system that makes us faster. So I was like, oh, this is easy. I've already done an email design system that supports three brands off the off, a singular code base. Like we should be able to knock this out, like not that slowly.

Like should be quick, should be quick. And then the more I look at the different layouts that we have and it's a lot of e-com where before my email design system wasn't, SaaS was a SaaS company. So very different approach, very different from a different approach. Highly templated, mostly text.

Now I'm dealing with all these different layouts and images and whatnot. It just keeps getting more and more robust. So right now I'm in the stages that I have the I have a lot of the structure for the body, so I'm just going into client files and building emails to see where it fails. And I'm like, oh, I think I need a variant for this, or oh, I need a trigger for that.

So it's just. And a lot of it needs JavaScript for it to work, so I can keep it all on the same code base. Makes sense. Oh, you keep all the clients on the same code base and everything's QAd ahead of time.

Then it just speeds you up that much more once it's in production. Claude Code's been helping me with making all that work for the all the dynamic stuff. Yeah. That's awesome.

Cool. Yeah. For sure. It reminds me I was catching up with an industry friend who hired a designer developer that built out their modular email design and system for their entire company.

I asked, like, how is it working like it is? Is it looking good? Is it working well? And it was the most interesting response.

He's like, yeah, it's great, but we don't use it. I was like, what do you mean? And he's like, we use it as the reference. We use it as the what good looks like and then let our team play try things out, but they have to QA it with AI based on the source.

Oh, interesting I know. I was like, I get it. I hadn't thought of being able to do it that way. And so it's an interesting way of like, okay, you can still get the expertise from a developer, but there are more parameters.

There's ways to play around with it. Um, but yeah, it's also an interesting one. But of course you have to keep your primary source code up to date. We've been talking about all these different systems.

Now, I'm curious if we get more granular within anthropic skill set. Literally. Are you using skills, artifacts, coworker or only cloud code? I was using some skills, but now with routines out, a lot of those skills can actually be routines.

Mostly been using cloud code in my IDE, so I've been in Visual Studio Code, and I have Claude in there, so I can just hit a button for it. It opens it up and I tell it what I'm trying to do and just write in there and it can make the edits for me. So like, if I need to make a change in one component I'm working on, but like I need to make the same exact change in another component, I can tell it to go do that for me so I don't have to spend the time doing it. So that's what I've been mostly using it for.

Yeah, yeah, I'm a big artifacts user, which because I just have all these custom one off things, I'm like, I need you to get me to the 70% and I'll do the rest. All right. Now let's go to the error file or failure file. What is I categorically bad at right now?

An email development. And I want your granular answer and not it just doesn't understand context. You know the prompt wasn't great is it. Dark mode logic, conditional CSS, MSO code for outlook like preferences for divs over tables.

Like, give me one thing that makes you say nope, doing it myself. I mean, for me it's really it does come down to the prompting where I'm like, if I wanted to hit all the accessibility stuff properly, if I want it to code the way I want it to code, it's just you have to be so prescriptive with it that I'm like, why am I wasting the time being this prescriptive when I can do it myself? But it is getting better. Like when I first started testing email development with AI, it would give me JavaScript to do hover state.

Oh no, it would do everything in divs. But now it's not doing that anymore. So people say, well, it's like clearly it's learning from other people doing the work and it is calling out when something is not universally supported. Hmm.

It makes sense though, which I find interesting. Yeah. There have been a couple of times where I'm like, I was going back and forth with Claude because I was trying to see how the inline are. That's part of my system work.

So I'm using Masal to develop my email design system, which is an open source, nice like tailwind framework thing that I can use to make components. And then so once you're done building with your components, then you essentially build the email in it. Um, outsources all your HTML and I some people don't like using in liners. There are some email developers out there who are very good friends of mine who hate using in liners.

I love it in liners because I don't like looking at the giant blocks of it's so unlike CSS. I like it all in the head when I'm developing because it's easier, but I was trying to see how advanced I could get using the CSS if I could get it to inline the way I wrote the CSS and get to inline as I intend. I just started playing with that, so it answers out on whether I can do it or not because like, I would love to be able to use modern CSS in my email design system with like just to do like child selectors to be like on the last paragraph, make your margin bottom margin zero so that we don't have extra space.

It's like those sorts of things. Or like if you have a header and an image adjacent to each other, we need some extra margin between the two, like those sorts of things. Um, so I'm seeing how I can make that work, but like I asked if it can make it happen, it's like, nope, the inline or can't do that, it's too advanced. So it's been interesting to see where it succeeds and where it fails.

I mean, it is getting better bit by bit. When was the time frame or what is the time frame you first started using AI to help. And yeah, how quickly do you think it's evolved for the better? I mean, if you do a Google search of webinars I've done, there's a webinar from me maybe two years ago saying AI is useless.

Like, I was very much like, nope. This is really bad. Um, and in the last two ish years, it's come a really long way. Um, and I've been one I've been slower on the uptake than some other people.

I do not believe AI is a magic bullet. But I have gotten more curious to see, like, okay, where is this helpful? Where is this not helpful? Like it's here.

Let's take an honest look at it. I mean, to be fair, you're definitely ahead of most curves. If we look at the industry at large. And that's why I wanted to have this conversation.

Just because it's hard. It's super hard. Email clients are a fragmented mess, as we all know. R.

I.P. litmus. R.

I.P. all of the things we're in full mayhem descendants at the moment, whether it's Gmail clipping The Apple male privacy changes that happened a few years ago. Outlook.

Just fucking outlook. How much does the AI actually know about client specific rendering? You've kind of mentioned it, but how do you know when to trust it versus know when it's very confidently incorrect? Kind of like a mediocre white man, I love that.

That's a good question. I haven't like I actually haven't pushed it in that way so much yet. I think just just because I already have all my snippets. So like my thing with trying to code with AI is that when I've been testing it, I'm like, use my code, do not write it yourself.

So that's kind of like the direction I've been going in is that my end game is that I have all these components, and I've tested this out a little bit already and it works pretty well. So once everything's done, I think it's going to be really cool is you feed it a figma link to a design. You say, use my components, create this email. That's awesome.

And it does it. So that's my name. So like, I wouldn't expect it to know all the nuances of outlook because there are like a lot of outlook related CSS that like we can use to do things that like that, you won't know unless you're an experienced email developer. And they're kind of also it's like just like trade secrets in some respects, like you either know or you don't know right in there.

And a lot of times they're just creative solutions to try to accomplish something. So I wouldn't expect I wouldn't expect the AI to know about, you know, really obscure things like that or like if you're trying to control, uh, text color and Gmail dark mode to some level, which you can do sometimes and times not, there are ways to do it using blending modes. I wouldn't expect the AI to necessarily know how to do that. The AI would probably tell you it's not safe to use for email.

Yeah, and I guess to that point it's the eye because it's trained on so much. It knows the rules, but it doesn't know the accommodations, right? AI doesn't know nuance. AI knows patterns.

It's a exactly pattern recognition. So it does not know the nuance of what you are trying to do. Speaking of nuance, we're talking about all these different components and we're like, you got to put it in the prompt no matter what. Are you using anything stored to memory?

Is that actually being helpful or you just got to do it fresh every single time? I haven't been doing anything like that. Okay. Not yet.

I was just curious because I commit to memory a number of things, and it still doesn't always work the way I want it to. All right, I want to. We've been talking super nerdy in the best possible way. Language energizes me so much.

I want to take a little bit of a step back to the broader industry. And so you in particular have just such a unique experience, having worked on at Mill Gun Mill, Jen, email and asset. So you've seen the infrastructure side which few have seen the creative side being a designer and also, of course, the QA side of the industry. And so where you sit is actually is AI accelerating what you see as email's evolution, or is it just giving faster ways to make the same old mistakes?

For those who are not perhaps developers, designers and have the multi-hyphenate you have? Yeah, I think I do think it's a I think it could, at least at first, accelerate the creation of mediocre code, for sure. Lowest common denominator. Um, I think I think engineers are likely running into this issue too, with code, um, where I bet somebody could send me code that they wrote using AI, and I'd take a look at it and I'd be like, what are we doing here?

Like, there are so many other efficient ways to code this. Um, so I definitely there's more than one way to do almost anything, and I think I forget that. Right? It's like.

I mean, it's like if you look at the way I code and you look at the way my friend Anne Tomlin codes, like we actually we did a whole talk about this, actually, um, about the fact that we code in two totally different ways and they're both valid, but then they're I'm assuming you're the CSS forward and she is the HTML forward. Uh, we actually we disagree. This is a I guess you could call this a different hot take. And I went do it.

Yeah. Me and her talked about this at UN spam because in Cyril Gross's, uh, accessibility talk, he was using, uh, ghost tables and divs to code emails, which, when I work on an email design system, that's how I code. So, like, I usually will flip between two different ways of coding that I'll if it's going to be in a component, I'll do it with divs and ghost tables. If I'm doing a bespoke email where I'm looking at all the HTML.

Use a table because it's I'll use only tables because I find it easier to read where Anne's school of thought is. Well, I'm just going to use tables because of outlook. And some people think that when you're using ghost tables and divs, you're essentially coding the email twice. My rebuttal to that is you see both sides.

Yeah. No for sure. Like there's a there's definitely like a pros and cons. And I think I'm gonna write like a more robust future newsletter about this too.

My argument for the ghost tables and divs is that it's more one, it's more forward looking because outlook is going to be phasing out the word rendering engine. Now that doesn't mean companies are going to update at the rate we would like them to. So we're still going to be dealing with it for a while. But when that time finally comes.

Instead of having to recode all of our emails to new modern standards. We can just take out the ghost tables and we're done with it. It also allows us to more easily code mobile first, because outlook not supporting media queries makes that harder. So that's why with an email design system, I often will do it mobile first with the ghost tables and the divs, because it also allows me to do that.

And then the tables literally are only read by outlook and that's it. I set it up so that the tables are only read by outlook. They don't read the divs. Sometimes you can use CSS just to target it all anyway, so you're not rewriting so much twice.

That's kind of like my hot take about that. Very fair. It kind of sounds like I need to to bring an in yourself back on and do a debate about them. And like all of the pros and cons because while I recognize this is super niche, it's also super important because I know when I was learning to develop code, I was fortunate I had a boss who one was amazing but also was an incredible email developer, not to mention designer.

And so I got, hey, let's pull up Dreamweaver and let me show you what you're doing wrong. And then we would go to litmus. And so I got to learn the principles. It's funny because I had to train my direct reports and I was like, I don't know the reasons for anything, but I know how to do it.

So and there aren't particularly in email development, but also, just like in general within martech, there are no good resources. And it's hard. I'll just say there's a lot of resources out there that are not great. And maybe a little, uh, Shopify bro.

And they don't know what they're talking about. It's not a good look. It's not a good look. So no, I increasingly hate being on LinkedIn because of all the AI hype.

And honestly, I think in this day and age I love the community I have. Community has been amazing, but if I could get rid of everyone else, that'd be nice. I see all the spam DMs and like I report every single one. All right, I want you to take a swing at this myth.

Yes, AI is going to make email developers completely obsolete, defend it, dismantle it, or make it more complicated. But I want the version you actually say out loud for the audience is a junior developer who's scared we're in a weird market for hiring. What are your recommendations based off of your answer? Yeah, I feel like I talked about this a little bit already.

If I was talking to a junior developer, I would tell them to learn all the sides of email marketing. You don't have to be an expert in all of it, but having that knowledge from all sides positions you better positions you to be the strategist from the technical side. I mean, I would tell them to get really good at the coding bit and understand why things are done certain ways, and then they can layer AI on top of it. Like, I don't think AI should be the way to do it, because at least is right now, because we see these llms randomly bright all the time.

What happens when your entire workflow hinges on the AI and it's not working? Or new models really, or new models released? And in a standstill. If you want to use AI, you should be layering it on top of what you're already doing to make you more efficient.

It should not be doing like the bulk of the work should just be making you faster. I agree, I think AI is like the accouterments. It's the accessories that make it quicker, better, faster, but the fundamentals stay the same. And to that point, I think it's just it's true for everything, even beyond email development.

Like be dangerous enough to be able to have the conversation. Like, I will never be. And I don't want to be a Salesforce SFD CRM admin, but I can talk you through what is not working and tell you how and recommend how to do it because it to your point earlier, it's systems thinking it's design and architectural thinking, and as long as you are dangerous enough in a lot of not just fields, but really niches within an industry you're interested in, you can be unstoppable. Yeah, yeah.

And so you need to, you know, it's like once you know how to do the code, how can you learn systems to then make the emails dynamic? And what do you need to know to be able to do that. And that's where your knowledge really comes into play as opposed to just tinkering with code. Your approach to email, as we've mentioned, is multifaceted, being not just that designer, that politician, but also a founder of a publishing house which, like what?

I need to know more. Those are very much not a typical resume stop for a technical developer, and I feel very similarly. I come from a liberal arts background. There's no direct translation except for critical thinking and reading and writing.

And so how has working across such different disciplines and contexts shaped the way you think about what email is actually for, and how does AI change that answer at all? Yeah. So it's learning how to communicate with people in all sorts of contexts. It's really what it is.

And I actually was I mean, be a marketer, figure out your audience. Right. So I actually this is really funny because today I had to quickly draft up an email today to send out to parents at soccer because not only do I coach soccer and vice president of the board, and I am the one responsible for running our spring evaluations, which are next week. And I learned that parents were really confused about them.

And when I took over these evaluations, I had shortened. I had added more emails to send out leading up to it because I came to it with an email marketer brain, and I shortened up the emails a lot, knowing that people would don't read, and I linked to FAQs on our website. I have learned that was a mistake. I should not have done that.

All the information needs, all the information needs to be in an email. I'm asking parents to do too much. Wow. I love a perspective shift.

Yeah, so I wrote up an email and I actually I've been using AI to help me write a little bit for a lot of my volunteer work just because I'm doing so much. So I took an email I wrote, and then I put it into Claude and I was like, hey, like, this is going to parents help me make this more clear so that parents can get the information that they need. So it did that for me. And I also I had to get it sent out today because like we were getting a lot of questions.

That was like a mindset shift for me to be like, okay, like this, going out to parents, I need all the information in the email. I cannot expect them to click and go to a website to find out more information, if they're confused or need more information about what even evaluations are. That was a mind shift change. The other thing I've been going through is on the political side, I'm now involved with our local Democratic Town Committee, and I kind of took over their emails, and I'm trying to figure out how to grow that really nationally.

I'm trying to figure out how to grow that list. It's a very, very small list. It'll always be like on the smaller side. But right now there's a lot of room for growth.

But it's how do I get people to agree to sign up for an email about local politics from a particular party. So that's that's been really interesting to play around with different strategies to see what I can do there. That's super fun. Good reminder.

Always a B test or always be learning about your specific audience, right? Right. Because that goes against every best practice, right? It's like I can't in these lists are all way too small to do any testing.

Like we're talking about like these particular groups, these emails are going out to a couple of hundred people at most. I'm never going to have thousands of people. Like, that's just not what these lists are going to be. So yeah, so it's kind of just looking at what works and what doesn't work and kind of just making the change.

Government has a different threshold. I mean, like I hold like I our list, we use MailChimp and like I hold us mostly because it is in MailChimp and I just know how quickly they can beat a block list people. I hold us to really strict standards of who can get added and when they can get added, because I just because I know MailChimp and I just don't want us to get blacklisted. Yeah.

You know the risk as well. But yeah. No, I, I feel similarly anytime, anytime I'm in charge, I'm like double verification. I don't care what I want it because I refuse to abuse unlike everyone else.

Yeah. Yeah. Okay. Very last question before I let you go.

Who is someone we have on the podcast, particularly someone whose perspective on email martech or the intersection of technology and creativity is not getting nearly enough airtime. I think you should have an on and Tomlin at some point. See what she has. Sadly she's really she's a dear friend of mine and is so fun to talk to.

Her answer to these to similar questions like this are probably going to be totally different from mine, and it'll be such a good conversation. Yeah, it's a good thing. We need diversity of thought, because at some point you're going to need both sides of the approach to figure things out. Absolutely.

Thank you so much for coming on. Where can folks find you? Follow along. Yeah.

So you can find me on. I'm on LinkedIn a little bit so you can find me there. I have my newsletter that's based around email development. It's called Med Codes email.

So my website is literally med code dot email. Hit me up there and you can always subscribe. And if you want more thoughts about email development and AI and philosophical things about those topics. Awesome.

Well, thank you so much. Yeah, thank you for having me. Some listener takeaways. AI is clearly earning its place in the hardest of problems, whether it's complex, liquid templating, intensive if else logic.

It means it's a precision tool, but not a generalist. I'm biased and like being a jack of all trades, but it does require fresh context every single time, and it really does fall apart on anything prescriptive as it relates to email coding, which means that the prompt is literally the skill. And like, that's not news, but it's still a little frustrating. So be sure to treat every output as a starting point that still needs your expertise.

And make sure you are investing in that and not just an AI subscription. Capture your brand's edge cases your known rendering fixes your client specific or customer specific workarounds, and feed that institutional knowledge into your prompts because otherwise into your prompts, you need the outputs to be calibrated to your reality, not a generic average approximation of it. Okay. Listener takeaway number two enterprise email.

Like marketing cloud Bray's iterable level, it still demands systems thinking and strategic technical partnership, which means that the AI and drag and drop editors alone won't cut it. Especially where it counts. So developers who master coding fundamentals first and then layer on AI on top. Well, outlast those who build AI dependent workflows, because you need your foundation to be built on something you know and can protect.

So as a result, you need to learn all sides of email before you let AI do any heavy lifting. Otherwise, you don't know how to troubleshoot when it goes wrong and take away. Number three ISPs are shipping all of these drag and drop templates that fail basic accessibility checks, which means for non-technical users or folks who are not particularly familiar with not only the laws and regulations, but how it works, they're unknowingly sending inaccessible email at scale. I don't think anyone is trying to be exclusive of anyone who could be a customer, client, you name it.

So these fixes aren't just Something customers should be in charge of. They should be engineering shifts, product manager shifts. They're not huge engineering lifts. They really aren't.

Contrast ratios, language attributes, alt text. All this just needs prioritization and it keeps getting put to the back burner. And it's not a capability gap. It's just a prioritization problem.

So if you're managing an email program audit those templates. And if you're a PM at an ISP, this one's on you. And as customers of all the different ISPs submit that feedback, get it prioritized. Especially now because all the aforementioned things we've discussed, cloud code could probably get a solid V1 beta version out to certain users.

Just to get started with such a great conversation with Megan, this is exactly the one our industry is in need of right now. Nothing about hype, not about panicking. Staying calm and actually understanding from someone who's doing the work. Telling the truth about what tools can and cannot do just yet.

And I'm really appreciative for being so specific and honest and really generous. And I hope every email developer email marketer person in martech who is quietly terrified of code walks away from this being a little bit more grounded, a lot less alone. And amidst this chaos, and for everything that we talked about today, the real use case is the failure files, the practical starting points. This is the stuff you're not going to get from a LinkedIn carousel.

So share this one. And once again, thank you so much for tuning in to the Making Sense of MarTech podcast. A special thank you to Christine Murtaugh, who edited this episode, and an extra special thank you to Jenna Carter for believing in this passion project meets business. Stay curious.