The MarTech Developer - Sanford Whiteman

Justin Norris:
00:00:15
Now this may seem totally wacky to anyone born after 1990 or so, but One of the main benefits of marketing automation in the early days was to liberate marketers from a dependence on IT. So the vision there was that marketers could create their own emails and landing pages, make complex campaigns, do all the cool stuff they wanted to do. And they didn't need to know any code to do it. Did that actually happen? I think sure it did to some extent, but we also saw a few other things in trying to do that. We saw forms that were breaking, we saw systems that weren't scaling, integrations that failed, and just a lot of different requirements that couldn't be met by the way platforms worked out of the box. So that brought us back to step one, which is that we still needed developers, but we needed a special kind. Someone who had the technical skills, but also a deep knowledge of the marketing domain. So effectively a martech developer and for my money. Today's guest is the best martech developer there is. He's a legend in the Marketo community, one of the smartest folks I know, and a good friend. Sanford Whiteman, welcome to the show.

Sanford Whiteman:
00:01:17
Thank you, Justin. I was afraid that had something to do with me.

Justin Norris:
00:01:20
So, Sandy, we've known each other eight, nine years, getting dangerously close to ten years at any event. And it's weird that I've never really asked you too much before about your background. Could you just walk us through how you got from point A to point B?

Sanford Whiteman:
00:01:34
Yeah, sure. I used to be an IT person. I mean, I was a security and firewall person. I was the hard ass Cisco guy who wouldn't let... Any, ports through the firewall, even if, supposedly some, some mission critical app demanded it, I was paranoid about, I still am, of course, I bring all of this experience to the table, but I try to not be like that anymore. Nevertheless, I did have that background first, that got boring and stressful simultaneously, as a lot of people will tell you about working in security, you know, you're always thinking that your phone, let's call it or. Pager or whatever, or whatever you have at the time is, is, uh, you know, you're, you're basically, you're thinking I missed something and any call you get, you know, you know how it is in our world now. But anyway, that was like a nerve wracking thing. And I started working with a friend on web app stuff. And we built this ridiculous app that still exists. I hope nobody hears me say ridiculous, but it's great. It's still runs. It's still used by people in the textbook publishing industry of all the weird. Niche industries a Notoriously slow to digitize world where our app built. I cannot tell you how many years ago it would be embarrassing. Like my, my lips can't form the number of years ago that it was built, nor the number of years ago that it last had a version upgrade. But it's still the best one out there. But that got a little bit weird because we couldn't find any more clients for it. We had like conquered the few enterprises, I don't want you to think it makes a lot of money, but it's just like we had covered every large publisher because there's so much consolidation. And yeah, somewhere in there, my partner started working for a financial services company. And after a few years there, he brought me in to look at their MarTech stack because he knew that I knew web stuff. So my first experience with Marketo, my first experience was troubleshooting munchkin. Like I had never used, I had used Salesforce or other sales, you know, CRM type stuff, but I had never used a marketing platform before, but their munchkin wasn't working. It wasn't associating leads from clicked emails, you know, the classic thing it's supposed to do. So I took this weird route in where I was brought in not as the reluctant, you know, you get the web team and they hate to work with marketing and there's all that kind of resistance to doing, but it was like, you have to solve this. This is your job undistracted. So I kind of, you know, I want to say reverse engineered, but but figured out a lot of things about the tech side. of Marketo first before doing anything else. And the form side, like you said, you know, seeing that there's this open, adaptable, customizable thing. This was still like forms 1. 0 days, but I could tell, like, this is a thing where there's nobody, there's no Martech developer, there was no such thing. You know, I, I might've been one of the few people in the world at that time that just was. Allowed to only do MarTech development, but it was only because, you know, big shout out to my friend, Brian, if you ever, here's this, he brought me in and he said, give this person this project and this project only. And from there, of course, you know, I got Marketo admin access and, you know, and then, and then there was a while that people assumed that I knew how to use the Marketo UI, you know, smart lists and smart campaigns and flows. And I kind of didn't, I knew how to use the API and I was answering any question anybody had about that I could answer, right. But it took me a few years to then become the person that most of us are, you know, with the fluency on the backend. And yeah, so since then I've been trying to be the master of, to retain the mastery, you know, of the tech side and the backend campaign side, which is hard because you can go down a rabbit hole of troubleshooting some tech thing. And that takes hours or days that other people are using in the UI itself. But anyway, so that's kind of the arc. And now, luckily there's enough little problems to solve all over the place that that's what I do.

Justin Norris:
00:05:13
So to zoom in on that first experience where you were essentially, you know, it sounds like locked in a room and said, don't come out until you fix Munchkin. I mean, the fact that you were given that opportunity is one unique thing, but then I think a lot of developers would maybe get it done and move on and somehow you, you sort of like to take something apart, understand all the component pieces, appreciate it and know how to put it back together again. And you didn't dismiss it as like, it's just this crummy little marketing script.

Sanford Whiteman:
00:05:39
Right,

Justin Norris:
00:05:40
I'm kind of above that. Somehow you, you really saw something to make you go deep into that and got interested in it. And I'm just curious, where does that come from? Is that a you thing? Or did you perceive actually I could really get good at this and then nobody else is doing it. Like, did you think of it that way or was it just, this is interesting. I'm here. Let's figure it out.

Sanford Whiteman:
00:05:56
I don't deny that there's a motivation. An unconscious motivation of probably no one else knows how to do this. I don't think of that like, you know, from a career standpoint, more of a I want to be the one who knows it. But I'm not even thinking that, I'm just like, I'm feeling it. Before I did the Marketo stuff, there was one other thing that I was like super expert weirdo in. And it was the Microsoft SMTP server that came with IIS five and six and seven, I guess, but I had stopped by the time is IIS six and I was on the MSDN communities and got so deep inside figuring out how this closed source thing worked. I mean, you want like a hard reverse engineering. It's like, you don't get to see the Munchkin JS library and sort of try to unminimize it and figure out what's going on inside it. Like you have nothing else to go on except timing things and like the way it interacts with the file system and windows registry and all kinds of little things like that, but I became obsessed. Like I wanted to be the one who really understood it. Cause I kind of, I could. Kind of get the feeling like to your point that there were people providing generally correct answers, but trying to gloss over the fact that they really didn't understand why something worked or not. So that was kind of an automatic thing. That was probably the most immediate precedent for my Marketo and Munchkin thing was like, I need to know how this works because it feels like there's a missing store of knowledge, even within Adobe then Marketo. You know, like that's, that's the tragedy to me is like, I felt like no one, and this has grown over the years, no one within the company that owns this product currently, at least knows how it works. And that is the kind of thing that just irks me at some core level, I guess. So that's, what's kind of kept me going. If I felt like, and I think this is kind of why I could never do the same thing for Salesforce because. Over at Salesforce, you're like, okay, the engineers know how it works. You know, we're just playing around in the community and trying to show off expertise or whatever, but it's like, you're never really going to get, you don't get that feeling like you're, you're going to reveal something to the people that work there. But I think with Marketo, there's that sense of like, I can actually show the people who built it, how it works. And not just because of institutional memory and. Stuff like that, or, or, you know, people departing, but because sometimes they don't really, uh, and I say this with as much kindness as I can muster, they don't really understand how JavaScript and how browser stuff works. So they're not really front end people. So you really kind of do have to say the way your forms library is built, struggles, or does interesting things under these conditions. And it's not like you're have anyone inside has been like, well, of course I knew that it's more like, yeah, well, we kind of wanted to get it out the door. It is like a drive. It is that feeling of like, no one knows this. I'm not interested in, in doing it. If I feel like someone knows it.

Justin Norris:
00:08:29
It's a mountain to be climbed that no one has climbed before. I want to describe to you, from an outsider's point of view, my perception when you came onto the scene. Because at the time it felt like there were very few technical people, hardly anyone that I remember in the community. And it was really a lot of demand gen marketers or former demand gen marketers. Some people maybe that self identified as marketing ops and so people would come up with solutions and things or maybe Speculate and it was always sort of impressive people who seem to have more knowledge of the inner workings But they maybe didn't really know or didn't have the expertise and then all of a sudden he emerged and it was like Oh, you're someone actually technical and it was kind of like, you know a bunch of gophers trying to drive a car or something and all of a sudden a formula one racer comes out and is Like actually here's how you do it. So to your point, I think It was a really valuable service and you alluded about your security leanings and trying to purge yourself of that. But I think that's part of the recipe from my point of view is that nobody else really even understood the principles of what a DDoS vulnerability would be, or, or, you know, like those things, like people just didn't think about that stuff. And then you, at least for me, as an enterprise marketing operations consultant really helped give me that vocabulary to then sort of absorb into my lexicon and take to clients and be like, well, actually. To me, all those components became part of the recipe of what you did that is unique.

Sanford Whiteman:
00:09:43
Yeah. I think you're right that one thing I wanted to do is say, let's not guess also. That's another like painful thing when you see like a really well intentioned person who nevertheless is just putting up a best guess and it's like, I don't think it's that. Let's know as much as we can and like have a good faith effort to really, you know, bring together knowledge of databases and networks and just general enterprise architecture. I, I, you know, I give full credit to the people who didn't have that background though, because they didn't have the, I mean, frankly, like years of experience, which you can't make that up out of nowhere, but they also had, they, they, you know, still most of the people in mobs are technically minded, or I guess maybe I can say like logically expert, but they don't have a hands on experience because they didn't really come from that world. It's hard to extract yourself from the world where you're, uh, You know, the jerk in the IT bullpen who doesn't want to do any work for marketing or sales. That was the thing that I was alluding to at the beginning is like, I come from the original cohort of people who, when you said you were going to move to a cloud CRM said, well, so much for getting any help from us. You, you know, you do that. You'd say to the sales team, you go to Salesforce, don't call us. Like I was that guy. Now it's silly because I'm dealing with the IT people. And I'm the person saying, you need to take this seriously. This is still part of the company. This is not. You can't actually ignore it. And a lot of that is coming not from pure cost, I think, which sometimes is valid, but it's coming from that still lingering, almost decades old resentment from the IT team. Why are we paying for a thing I believe we could build in house, that I believe we had a better version of before, you know, when I was. Young and strong and, you know, had the energy to do stuff. That's a funny interaction sometimes. Cause people will say like, we could build this. What, what does this thing do? We could build it in house. Like I've had people say that about Marketo, which is just so insane to me. I'm like, how many developers are you going to put on this full time? But again, the flip side is I remember being that person being looking, especially the earliest cloud solutions and thinking as a web developer, we could totally do this. Why are we paying for it? And, you know, those questions still swirl. Well, you're paying for it because you don't have enough time to have a full dev and QA staff working on it, and you wouldn't save any money on that anyway.

Justin Norris:
00:11:59
build a workflow every time marketing wants one. And,

Sanford Whiteman:
00:12:02
right, right,

Justin Norris:
00:12:03
a campaign. I mean, so speaking of these developers, whether it's sort of your classic IT developer at like a big company, or whether it's your cool, you know, Silicon Valley software engineer type, these are smart people. And yet they, many of them, let's say, have produced a ton of really bad work when it comes to MarTech, whether that's Applications with horrible or unusable Marketo integrations that they've built in house or, you know, people doing, people doing unspeakable things. But these, these are people who had the same opportunity as you, let's say, to take apart Munchkin. They haven't stepped up to it, and it's not, as, as you've said to me in the past, that they're, it's not that they're like bad developers or something, but, like, what is it? Is it a lack of intellectual curiosity? Is it a feeling that it's beneath them? Why, why do traditional developers struggle when it comes to the Martech stack?

Sanford Whiteman:
00:12:51
I mean I think there is a disparagement of marketing. They don't think it's doing anything really. If you somehow have told yourself that SMTP, which they don't understand and landing pages, which unless they're real front end people, they don't understand. And all the database and workflow stuff and queuing stuff that a sophisticated MA has, you know. If you've told yourself that that's not real technology or it's unsophisticated technology, then you're going to keep sticking with it. Even if somebody shows you like I've had this moment, maybe you have two where someone has been skeptical. They've taken that same view. Oh, what does this platform do? What, you know, it just looks like it's a landing page builder or something like that. And you show them on a good day, you show them some features and you can actually blow somebody's mind. Like I've, I've had to give like some props to people who have evolved some people, like Didn't realize how sophisticated the Marketo to Salesforce sync is, for example, although that's still, you know, firmly within the realm of sales and marketing. It's still it's clearly a piece of engineering that's well done. And, um, and I've seen people like realize that they thought they knew how email works. And they don't. And that's one of those things where they talk to the IT team and say, can, can't we just send this all ourselves? And the IT team will be like, well, not really, because, uh, you can't really do that with, you know, Outlook, um, and like, start to realize that there is a sophistication to the Marketo And, or, you know, or, or HubSpot or anything, you know, queuing and resource balancing and even the multi tenant architecture itself. Like I've talked to people who don't really, cause they're, they're still like in house developers, so they, they've never built a cloud app. So they don't think about what it would be like. Now, Marketo struggles at multi tenancy as we know, but nevertheless, the idea that, no, it's not just, they don't give you a machine, you know, like that resource balancing across the different customers is something that. In house developers usually Don't care about, they actually will have an app that could be overwhelmed by one business unit, but they don't really think about that as a concern because they're like, well, it's a fireball offense. If you try to overwhelm the internal line of business apps, we're not going to worry about that. But the fact is like doing that and having a public facing site, all the reputation management, email, reputation management, the last internal it people or developers in general understood anti spam tactics and things like that was probably 15. Years ago or more, I guess there's a long way of saying. To be optimistic about it, when those complexities are revealed to people, many of them have an epiphany and they realize that it actually is sophisticated technology. But to your original point, I think you're right that there's just the thought, immediate thought is this is nothing. It's simple. Why do we even need it? Just gets like caught up in

Justin Norris:
00:15:32
The lightbulb that just went off to me with what you were saying is that through, like what I mentioned in the beginning, like, we're going to free you from dependence on IT and you can do your own thing. And then we did our own thing for a while, and then all of a sudden IT forgot a lot of that knowledge that they used to have

Sanford Whiteman:
00:15:47
Yeah. Yeah. Uh huh. Uh huh.

Justin Norris:
00:15:49
And also, like, like you said, that there is a kind of primacy of back end developers over front end developers. Like,

Sanford Whiteman:
00:15:54
Mm hmm. Mm hmm. Sure.

Justin Norris:
00:15:57
requires more skill and expertise. And yet, you can, you know, write really crazy things in Python, but maybe you don't know how to debug a web script or figure out why a form isn't submitting properly.

Sanford Whiteman:
00:16:11
I mean, you spend your time disparaging JavaScript and saying it's a joke language. That's, I mean, that's the most ubiquitous language. It is the language of the web. You know, there are confusing things about JS, but it sure as heck is not easy to learn. And I think a lot of those people are just running away from how hard it is. They just assume, especially now to get, you were going to ask about like AI stuff. They always think, Oh, well, I can just run it through chat GPT to translate my Python, but you can't because there's no client Python that you could write that would trend, you know, like there's no, I think it's great. It's almost like. It's brilliant because it's a little bit of job security too, because you, if you don't have some JS skills to start with, there's like nothing you can translate, you know, automatically to that world. You have to understand all of these arcane and honestly, if you read like the, the ECMAScript standard, where I'm always going to like prove why things don't work, whatever, the ECMAScript. slash JavaScript standard or like, you know, HTML five, like official W3C standards, they're really hard to read. Like you have to, you might wave your hands and be like, Oh, I don't need to know that it's dumb, but I mean, it just doesn't quite work. Like it's not, it's not dumb. It's actually. Arcane and hard and not as satisfying as Python. If you're doing like, you know, quant stuff in Python or, you know, any kind of backend work, you're probably going to get more immediate satisfaction out of that. But for me, coding is never about immediate gratification. For me, I think that that's one of the things that makes people scared, scared, like you said about, you know, scared of troubleshooting a form. Like, you know, somebody opens a thread on Marketo Nation and I'm always like, okay, I know I'm going to figure out how this works. I'm not going to let this just sit there or, you know, why, why, why the form is breaking. But I'm also like. This could take two to three hours and sometimes it does just running it through a proxy server, figuring out, simulating the conditions that might have led to a form sometimes not submitting and sometimes submitting, you know, that those, those anomalous or seemingly random behaviors are some of the hardest things you just don't really get that if you're a backend developer, you don't have, I don't want to generalize there. I mean, you could introduce bugs that create what seems to be anomalous behavior, but there's nothing To compare to the weirdness of web development, like to the whole, like, I think it's randomly failing to submit the form, but then I'm always like, there's no such thing as randomness. It has something to do with network conditions,

Justin Norris:
00:18:30
truth is out

Sanford Whiteman:
00:18:31
figure out what it is, you know, but I talked to people who are intrigued by my seeming specialty as a MarTech developer, and some of them are currently developers. And I will say, well, one of the first things you need to do is get. your feet wet again in that thing you probably ran away from a few years ago or five years ago or in school or whatever that thing you think is elementary you can't skip the knowing how web browsers work part of web development and that's another thing i mean doing this stuff for a long time i was there i wasn't good at it i i mean i sucked at it but i was there and in fact i was scared because it was like early javascript it was like too impenetrable to me when i was you doing security stuff people that were also like web developers out there. There were, I know this guy, um, he'll never hear this, Vince Allen, one of the greatest JavaScript developers of early JavaScript that I've ever met. Like, like insane. I can't even, the things that he could do, he was, we worked for a startup together. I was the back end database guy or chief technology guy, whatever it was. Short lived startup. He was the front end guy. He was, he was way overqualified because the, the app didn't really need the skills he had in what we used to call, you know, DHTML or, you know, dynamic interactions and things like that. So good. And they were, and I was like horrified at the idea of how far he was from me or how far he was even from most people building webpages at the time. I think he went on to work for Google internally. He might've even retired by now or something like that. But yeah, there was that. Period where you really had to know what you're doing to push early JS to its limits. But knowing there were people who were masters is really important. And then you had the whole period of frameworks and people not, that's another thing. People not really learning JS happened 10, 15 years ago, they would learn jQuery or Whatever. And, uh, so because they never really learned it and then you plop them into something where it's like, well, Marketo forms do somewhat unfortunately use jQuery under the hood, but you're not going to get away with just understanding the core idea of like, you know, building a jQuery and bootstrap powered site. Like you have to get real jazz. Like I said, again, The idea of, you know, uh, those race conditions, the timing issues, weird cross origin security things. You just knowing jQuery doesn't help you figure them out. And that's a lot of what I do because it's this form, you know, we're not getting leads because this form doesn't submit, it doesn't matter how good you are at jQuery, it's unlikely that you're going to be troubleshooting that at a code level, you know, you're troubleshooting at a network level and getting deep into browser internals.

Justin Norris:
00:21:04
Reflecting back on your comment about being the person who will take... Three hours to answer some obscure question on the one level. You're like, you have a good billable rate. Why would you invest that amount of time, which represents money into something obscure and maybe who else will ever have that exact question. And yet to me, it's because you have figured out those things that no one else has figured out. That you're my phone, a friend, or even to this day, I shared in some community that we're both in, I was having some trouble with an accented character, not rendering properly. And I'm like, I just, something in my brain, I had my Sanford sense go off. And I'm like, I think he's talked about this. I do my little site search of your site. And there it is, was the answer. And so it's like, it doesn't matter until it matters, but then it really does matter. And if no one

Sanford Whiteman:
00:21:49
Mm hmm.

Justin Norris:
00:21:49
figured that out before, then like, you're screwed. You have like

Sanford Whiteman:
00:21:53
I mean, yeah, it's like. I will go maybe forever, but sometimes for years before using one of my discoveries for billable work. Like you said, in the meantime, I can help other people out like you with it. What I don't want to be, I don't want to be in the situation where there's an emergency and I need to spend those three hours on my own client's work. So it's almost like a, and perhaps unwise for my time management, but I'm like, I'd rather spend three hours now on the chance that I have something to have in my pocket for two years from now or. When a client has that question, okay, I can only bill for an hour because I'm not going to lie and say it took me the three hours then, but at least I don't have the panic that I would have when I know that my client's boss is breathing down their neck. I know that the form doesn't work. I know about the consequences. It may be unwise. Frankly, I'm not a very practical, I'm not a practical person. I mean, if you only knew, I mean, I, the amount of time that I spent like for things that. Have no meaning at all. But yeah, it's, if I have any defense at all, which is rare, if I have any defense, it's that someday someone will ask me to do it, you know, and they are my client and I get to give them the immediate answer, what I really want. I would love to be in an advisory position. Knowing this stuff is key to product development. But this is a frustrating thing about the role that a MarTech developer plays for a client. I'm taking the load off the internal product team, right? Like sometimes if someone was contacting me yesterday, it's a flourishing, you know, well funded startup, whatever. The head of product said we can't ask their web devs to do anything for marketing anymore. So I'm going to ask you because I know you know how to do it. I was like, great. But I also had that kind of sinking feeling of like, okay, now I'll never that's yet another isolation point. You know, I will never know what the product team is doing and whether the product team could make use of deep knowledge that is relevant to any web app. And I feel like I do have a lot of that knowledge, whether it be encoding knowledge or, you know, that deep browser timing knowledge and so on, that a lot of commercial web apps suffer from not having a person like that on the team. But it's just, that's the way it is. Like I'm, I'm, I'm there to take the load off that team, not to Confer with that team about issues of the same type that their main site might have, but it is what it is. I guess that's that's another. Sometimes it's like, you know, doing a marketing thing on the never mind the app part of it, but, you know, the corporate site, the brochure site, if you will. I have to kind of hold my tongue a lot. I'm like, you know, it probably would be good if you didn't have a race condition for your. Other stuff, or you didn't have, you know, it would be good if you weren't loading a hundred different remote services on this page, but that's not my business, my business is make sure the embedded Marketo form works and that's

Justin Norris:
00:24:38
tough, the tough part of any consulting, you know, where you got me like, I'm just, don't look over there. Don't look

Sanford Whiteman:
00:24:44
Right. Exactly. Yeah, it's the don't. Yeah,

Justin Norris:
00:24:46
ahead.

Sanford Whiteman:
00:24:47
Well, well, you know, you've been in this situation, you know, when you're, you're building out a campaign and you look at the email content and you go, Oh God, that's so ugly, but you can't say it because it's not, or even like a new logo, you're like, Oh, say nothing, say nothing,

Justin Norris:
00:25:01
So, so this, this touches on a question that I wanted to ask and, and to some degree it was a motivator for me to leave consulting, at least leave it for now and go back in house, which was in the role of being a technologist that supports marketers, you're, you're always coming in downstream of strategy. Like there's always a strategy and a goal and a campaign goal. And sometimes, I guess I, I believe in marketing, and you mentioned earlier, you believe in, in marketing and its value, it's not that we're saying marketing is not good, but there is a lot of bad marketing, or there's campaign ideas that don't work, or there's things that don't matter, and so you can architect very elegant technical solutions, but you're building, uh, you're building a cannon, but it's being aimed at the wrong

Sanford Whiteman:
00:25:41
yeah,

Justin Norris:
00:25:41
it's never gonna hit, and how do you feel about that, just in general? I

Sanford Whiteman:
00:25:45
I mean, you try to sometimes nudge people. It depends on the relationship with the client. You know, sometimes you can say, well, I've worked in this area or I've actually done marketing myself and kind of bring that in. But yeah, it's. It's painful because it's, it's not what you're being retained to do. And here's another thing the outside world doesn't understand the difference between marketers and marketing operations people. I mean, you could dab 10, 000 people off the street and one of them might understand the difference just based on their experience, right? So. But I think, again, it's almost a curse of being an ops person with a good design eye or at least, you know, non zero design eye or campaign planning or just audience understanding persona. But I, I feel we're, we're just going to have to shut up. You know, I can, I can think of countless times where I've talked to a client and I'm like, well, I don't know the industry well. Or as well as they do, but I'm still like this offer for these people. This is non identifiable information offering like a 10 Amazon gift card. It's one example, just one of a million examples, but it's another idea where I'm like thinking about the persona purse. Why is it that who needs the 10 car? I know your B2B every one of your decision makers is make mid, you know, six figures. What? Maybe they know better than I do, but there's, but that would just be, again, that was a very superficial example, but it's the kind of thing where I have to go, Oh, so how, Oh, today we're working on the 10 Amazon gift card for CEOs campaign. All right.

Justin Norris:
00:27:17
the thing that's going

Sanford Whiteman:
00:27:18
not going to say anything. Right. Exactly. It's like review. It's also like review our, it's the 10 Amazon gift card for CEOs. If they provide a review on, you know, one of the, I'm like, okay. Let's figure out how we can get the campaign timing to work because I can't do anything. And, but what, what do you think about that? I mean, like, is there any room for, for expansion into that world or are we just doomed to shut up and.

Justin Norris:
00:27:41
I mean, I guess for me that was a motivation to like return to an in house role where ostensibly you have some input on strategy and you're having that discussion about what should we do versus just how do we do it? Like should we build this bridge over there versus how do we cross this span?

Sanford Whiteman:
00:28:00
right, right,

Justin Norris:
00:28:01
it's important to have both and yeah, this is one of the things I wrestle with because You know, there's sometimes there's people that are like, we need to get over there. And then there's the people that say, let's do it. And there's a division of labor there. And it works for a reason, because if you have, you know, the person that's hitting rocks with a pick hammer every five seconds being like, wait a second, is this the right thing? Like

Sanford Whiteman:
00:28:18
right.

Justin Norris:
00:28:19
So there's roles and responsibilities for some reason. At the same time, maybe I just felt I needed to go outside that for a bit, which results in being less technically oriented. Like I'm more distant from some of the technical things. Then I was not irreparably so, but yeah, it's, it's, it's tough

Sanford Whiteman:
00:28:36
Yeah. I mean, often it's also like you can feel the political, even if you could say something you don't want to, because you want, you don't want to be blamed for making a suggestion when it's not your role too. Like sometimes I found that. Uh, I have found that a client might be genuinely receptive to your suggestion and even skeptical in their own right about things, you know, that have been handed down to them from marketing. But the moment you enter into that relationship with them, you, you might get the feeling that they're going to say, well, Sandy agreed about this and all of a sudden you're implicated in making the suggestion that everybody else from a strategy standpoint rejected or something like that.

Justin Norris:
00:29:13
To me the best form of marketing is demonstrating expertise in public and building trust. If I need a MarTech developer, you're the only person I'm going to reach out to because you care a hundred times more than any other person. And you demonstrate it on a weekly, if not daily basis, like more than anybody else.

Sanford Whiteman:
00:29:31
I had a, an interesting situation like this with a client recently that is not directly related to marketing. I was working with a party who was working for their client. You might have seen me post about this on Mops Pro's Slack channel. I did a little vent, a tiny one line vent about it because I thought it was so silly, but yet disturbing and silly. The client had said that the Marketo lead ID is PII and that It can't be included in, it wasn't actually in URLs. It was actually for internal purposes that they couldn't key things off the Marketo lead ID. I found myself in one of those situations where I couldn't hold my tongue because it wasn't really a marketing question. It was a, you know, privacy strategy thing. I'm not a specialist in privacy, but something when it just sounds completely preposterous and wrong, and you just, you can't say nothing, you know? So, and I still haven't gotten a satisfactory answer. I, I said they, they needed some. Massive, yet insufficient workaround because their client had told them that the Marquette Elite ID is PII. And I was like, okay, we can do this. Maybe do this. It's never going to be as, it doesn't make any sense. And I kept saying like, again, to repeat, I really have never heard anybody say anything like that in my entire career. That

Justin Norris:
00:30:40
Cause it's a system

Sanford Whiteman:
00:30:41
Generate. Right. A randomly generated, well, they said, okay, to be clear, they said the same thing about the Marketo unique code. So it's not, you might be able to, I don't, wouldn't buy it, but you might be able to make the argument that the auto incrementing numeric lead ID has some sort of predictability to it. In fact, one of my clients once made a good point about that, that you can predict the sequence of lead IDs. So whatever, it's still the same as PII, but it's like a security thing more than a privacy thing by any means. The client applied the same fractured logic, in my opinion, to the Marketo unique code, a guaranteed unique alphanumeric sequence that has no meaning outside of Marketo. And it's just hard to, once you hear things like that, actually expand it to a whole realm of like what other poor decisions is somebody making? So it actually, maybe it shut me up more because I was like, okay. If they're that wrong, I'm not talking about other things, but I thought it was a good example of like something crossing the line where I couldn't be quiet about it, even though it's very far from the direct responsibility that I had in the project. I think that you, in your current role, I would, I would imagine you're in the room where people are saying things like that, and Justin can. Raise his hand and say, that sounds nonsensical you guys, but you can't do that as a consultant because it's like you kind of just, okay.

Justin Norris:
00:31:58
there's a flip side to that because sometimes I noticed this, not a commentary on my current job, but when I first left my in house role to go to consulting, there is a prestige on the flip side that comes with like, well, they're a consultant. So there's this like halo, you know, that surrounds the consultant

Sanford Whiteman:
00:32:13
Uh, yeah, true, true.

Justin Norris:
00:32:15
That you don't have when you're in house. But I think, at a company of my stage, the questions are a lot more go to market strategy than the thorniness of PI. Not that we don't care about PII, but it's... I think it's maybe only in a massive enterprise sometimes where you have the luxury. Sometimes it can become

Sanford Whiteman:
00:32:31
things like that. Yeah,

Justin Norris:
00:32:32
a naval gazing exercise for lack of a better word. I want to ask you, I mean we both have a long history with Marketo and have based our careers in various ways on that platform. What's baked into the question is that there's obviously a lot to like about Marketo, we appreciate it and all of that, but what's your perspective on the platform? Are the glory days behind it? We talk about the things that are the best about it and it's still like... The smart campaign, the Salesforce integration, like things that are really from the early days when it had a lot of vigor and energy as a product company. And it's hard to think of innovations that come close to that in recent time. So I don't want to go down too far the path of just venting against Marketo,

Sanford Whiteman:
00:33:12
No, no,

Justin Norris:
00:33:13
what's your product outlook and what do you think they need to do to remain relevant as a platform?

Sanford Whiteman:
00:33:18
we were speaking about these add ons like integration with Adobe Connect webinars and the seeming struggle of getting live chat as a replacement for Drift and so on. If I were in charge, I would shut down anything that seems like it's trying to be a look alike for a pale imitation of something. I think in both of those cases is a customer retention concept, right? Like they're not charging more for those, which is both to their credit and also makes it seem. Even more bizarre, because the idea is we're going to use this instead of drift, and so we're going to save all the money on drift, except it's also nowhere near as good as drift, so that's never going to happen. Like, it doesn't

Justin Norris:
00:33:55
do live chat. It doesn't do... Yeah, I agree. So actually, let's rebuild Marketo. Like, we'll build their roadmap on paper for free. They can just take it and use

Sanford Whiteman:
00:34:02
right, right.

Justin Norris:
00:34:03
So we kill the chat, we kill the Adobe Connect thing, whatever that is, so

Sanford Whiteman:
00:34:07
What, you know, what would we build, what would we build in its stead? What is the thing that isn't trying to keep up with the Joneses in a feeble way, but is actually, you know, long desired?

Justin Norris:
00:34:16
that, to me is like the critical thing, right? You know, it's the whole idea of getting ahead of the market and where it's going and understanding the needs, you know, the Steve Jobs esque quality of understanding the thing that people could want before it even existed. I don't know if there's anybody there that is thinking about the customer that hard and it comes back to the question of building technical solutions for things that don't actually... Work that well. A lot of it's like, does anyone care about what is effective marketing and what actually is revenue producing and then trying to build solutions that make that easier and more effective. I think there are tools out there that really work well, like the meeting booking link things where you can. Book a meeting on a website. To me, that's a real customer convenience. It's beneficial. It takes less time. It's removing friction from the sales process. It's a tool that solves a legitimate customer problem. And I wonder, is there any new features coming out that actually solve new customer problems? There's all the, Oh, this thing is inefficient. Can we like clone flow steps or save smart campaign templates? You know, just little, little things that all the convenience features that people ask for that they never make it to production because there's like, well, what incremental revenue is associated with that feature aside from customer happiness. There's like all that category of stuff. And then there's like the big innovations, which are really hard to think of. And it seems that it's usually smaller companies with dynamic founders who care about the problem and obsess about it, come up with those solutions. Like, I don't necessarily know what they are, but I haven't seen those things coming out from any of the big players in marketing automation. This isn't just a Marketo thing.

Sanford Whiteman:
00:35:39
Here's a thing that we know from AWS. I mean, Amazon's obviously been around for a long time, but that idea that at Amazon internally they use their own APIs so they can't go around the APIs and avoid discovering the bugs in the APIs. I think that You know, Marketo and now Adobe has never made that commitment. They've never decided we're going to have a flexible full featured API that we are going to dog food for our own interface, which would of course allow them to allow you to create, Oh, here's a thing. Okay. I'm going to interrupt myself because I do think this is something that is, it is absurd that they have not put this in the pipeline. And it's related directly to the idea of having a public Marketo UI API or an SDK for building visual add on to the Marketo UI.

Justin Norris:
00:36:28
right.

Sanford Whiteman:
00:36:28
That is, I've gone from defending it and saying it's not their business, they never wanted to do that, to kind of thinking it's shocking after all these years. And to get back to our whole discussion of front end developers, that an interested front end developer, one who is motivated, Can't even do it if they want to. They cannot say I am going to spend time customizing my organization's UI. You can do it in Salesforce. You can't do it in Marketo. That's a silly

Justin Norris:
00:36:55
step, but really like, like, like skinning and, uh, and even like layout and stuff like that.

Sanford Whiteman:
00:37:00
Well, I, I, yeah, I think SSFS is actually a way of avoiding these better technologies. I mean, like SSFS is creating an API that others can consume, but it's low effort for Marketo themselves actually rewriting and we know how hard this

Justin Norris:
00:37:14
Like a visual force page, the equivalent of a

Sanford Whiteman:
00:37:16
Exactly. Exactly. With a move from classic to, you know, the aura lightning components in salesforce was a major, major, major undertaking for salesforce. I cannot imagine how many, you know, hours pure expenses they had to get to that point. And it's not the greatest thing I've ever seen. But, but it does seem like adobe is uninterested in that level of customizability and extensibility. It's not just custom. It's extensibility. It's the ability for someone to say, okay, Okay. I want to create a new reporting all with my code, but consuming the same back end data. And I want it to appear as a tab within the Marketo UI,

Justin Norris:
00:37:53
It makes Marketo more of a platform, right? And less of like, well, that's just a point tool of execution and it generates some first party data, which I'm going to take out and do that work somewhere else.

Sanford Whiteman:
00:38:02
but I just want to, I want to caution. So I don't sound crazy as a front end person, and I know the reputation of projects like that. Rewriting from scratch, which is what this would entail, even if it's only the front end, it's one of the things that the greatest, you know, The legendary programmers dedicate chapters of their horror, you know, books of horror to decisions, rewrite things from scratch, which is fascinating because it means that this notion rewrite from scratch is like dismissed by the greatest developers in the world. It implies that a given product and its current, like general iteration cannot be rewritten in place. It has to be rewritten and, or there has to be. A substantive evolution to what constitutes a new app in order to make such an effort. And to not get slapped by the reality and the disasters that always follow that seemingly always follow such a decision. So I, I get it, but it's, it's such a funny thing to know that it's like, if you say rewrite from scratch, you'll get made fun of by. You know, experienced gray beard devs, as they say,

Justin Norris:
00:39:11
So you have to rebuild the car like one piece at a time until you get a new car. You can't

Sanford Whiteman:
00:39:16
you can, yeah,

Justin Norris:
00:39:16
car.

Sanford Whiteman:
00:39:17
modular or you can say it's a new app, but the idea is you don't try to rewrite the current functionality in another language or with another framework or in another, another scenario. And you might say dot, you know, dot next can be. And that's, you know, Mark and I tried that with Sky and

Justin Norris:
00:39:35
so I was just

Sanford Whiteman:
00:39:35
the whole idea is like rip it. Right, right. But they never really ripped it all out. So, um, they weren't, they were

Justin Norris:
00:39:42
a lot of people wonder why Sky failed, like, why did they back away and leave us with this, like, Franken UI that seems like it will never be fully transitioned, it's the weirdest thing, like, maybe

Sanford Whiteman:
00:39:54
it is really weird.

Justin Norris:
00:39:55
it had issues, but there was a significant investment, there was, like, it was going somewhere, it seemed, and I don't think the reactions were terrible to it in the community, And yet they backed away somehow, maybe for adoption reasons, and they're like, let's do this in between, and you can toggle, but we're gonna update, like, parts of the UI at a time, and now, I've gotten used to it, but if you back away, it's a horrifying thought to have a UI like that, like, for an

Sanford Whiteman:
00:40:23
It was a,

Justin Norris:
00:40:24
I can't think of another app that looks that way.

Sanford Whiteman:
00:40:26
I think that I mean, look, I don't have any inside information, so that's that, but they decided to get away from the XJS framework they're currently using and try to use another framework at the same time against the same API. I think that's part of it. They didn't, they didn't want to like completely rewrite. And again, that sounds like a bad thing. I'm saying it's bad to like completely rewrite, but they didn't want to do a v next, right? They wanted to do the sky on the current, when I say like, it's like the API for the front end, that is to say the public API that isn't documented, but allows for fetching things like, you know, smart lists and flow steps and all the stuff that happens. I think they wanted to keep that same API, but consume it using a different front end framework. And that falls into the category of never do that. That's, I think the most experienced developers and product people would say, no, you're going to have to, you're, you're doing Marketo V2. That's, you cannot do UI V2 on top of Marketo V1. You have to do a full evolution. I don't know why they didn't do that. Like I've seen, I've seen that succeed. I mean, MailerLite, small consumer player, mostly, they've got V2, and there are substantive differences, but they obviously have a team that I think it's, you know. Privately held small team of probably more loyal people and less distraction and whatever. And yeah, but that was, that was, uh, that's super weird. I feel like if I had to put something on the roadmap, it would be the customizable UI. It would be the ability to say you can now build directly into the UI. That's the kind of thing where you could get your Salesforce lightning developer interested. That's where you get a front end person to go, Hey, this is actually cool. I can plug into the menus. I can, you know, bring this data in and visualize it in different ways. Another thing I would do if I were in charge of product is start looking at whole database metrics. And you and I worked on this together for when we did that time with the time series thing, right? That the fact that we did do that together for the listeners. This was a way of pulling a database into an external time series database through which we could do. Things that seem simple, like sorting the people in the database by their level of, let's call it, web engagement. So we could say that they were in the four quartiles. You could say this person is in the top quartile of web engagement, or you could say this person is in, you know, the third quartile of email clicks, or whatever. It's not that Difficult to do in a modern database, even one that is not specifically designed for time series data, the one that that you and I use, Justin, is obviously a time series database, but you can now do it in Postgres and in, I think, to some degree in MariaDB, which It's like MySQL, which Marketo uses, but for whatever reason, they never thought, hey, maybe somebody wants to see the database, see the relationships between people within the Marketo database. To me, it's like the lowest hanging fruit. If I had all the Marketo data in a modern Postgres 11 plus or whatever version it would have to be, if I had all that stuff and I wanted to write a cool query that would blow somebody's mind for a new evolution of Marketo. I mean, that's what I would do. I would do split by quintile, you know, basically letting the leads in your database interrogate each other as to which ones are higher or lower value. There's some degree I think that they do that with like the heat ratings and, and relative scoring. Yeah. But,

Justin Norris:
00:43:54
and

Sanford Whiteman:
00:43:54
but it's not, but it's, but it's like, it's opaque. It doesn't need to be opaque. You should. I mean, that's kind of needlessly, it doesn't need to be magic, kind of fake AI, right? You should be able to run those queries, I think directly split the database by any number of time based, you know, contributions to the value of a person. But I don't know what stops them from doing that because here I am quite sure their backend supports it. They just never kind of think, well, like we don't want to give another dashboard. We'll say you can pull the data out yourself. And they do actually, you know. You know about the activity stream feature? I haven't used it.

Justin Norris:
00:44:30
no, what is it?

Sanford Whiteman:
00:44:31
The activity stream feature, which is supposedly free, lets you syndicate the rows of the activity log in near real time to a web service of your choosing.

Justin Norris:
00:44:42
So this is like an API feature?

Sanford Whiteman:
00:44:44
Yeah. But the cool thing is it's outbounds. It's like a streaming API where you give it an endpoint and it will send. The activity log lines to that end point. I mean, it's asynchronous surely, but it's like roughly as they come in, they get relayed to an external endpoint. This is the kind of thing that

Justin Norris:
00:45:00
got the notes up here, the developer

Sanford Whiteman:
00:45:02
you can kind of see as a database architect. I know that those features like change data capture and row based replication and that kind of thing are all part of modern databases. So it seems like it was something that makes sense for them to have introduced. The thing is it still requires that you have in house people and you build a service that can receive, you know, it's, it's. It's the furthest thing you can get from a new dashboard. It gives you the building blocks to build real time dashboards in outside, you know, in third party utilities by streaming the data to them, but it contains nothing else except the raw log lines. So it's like,

Justin Norris:
00:45:38
is a good feature. I'm just looking through the notes. This is a good feature. I clearly haven't been following closely

Sanford Whiteman:
00:45:43
Oh no, I mean, look, I haven't had it enabled in any of my instances. So I'm

Justin Norris:
00:45:48
this just come

Sanford Whiteman:
00:45:48
know, um, six months ago, maybe.

Justin Norris:
00:45:51
Okay, well I

Sanford Whiteman:
00:45:52
Yeah, I'm going to, I'm going to try it. Yeah. So, I mean, that, that, that,

Justin Norris:
00:45:55
really, because like it says, it solves a lot of problems where you're constantly auditing and, you know, or polling rather for changes and the backlog that that creates and, you know, the challenge with real time triggering. So my top two, for me at least. There's always the limitations that you encounter in the raw workflow capabilities. Like, oh, you can't quite manipulate data that way. If I think of Workato, which to me is like Marketo, but split apart into 12 dimensions. 'cause you can work across multiple systems and also the data pill capability and recipes, the ability to hold in data from a previous step, interrogate it, use formulas to manipulate it in various ways. Kinda like what mu munchin or munch. Whatever

Sanford Whiteman:
00:46:37
Yeah, yeah,

Justin Norris:
00:46:38
munches, that very short lived and obscure thing where you could, I guess kind of what Flowboost tries to do, but inside of Marketo, to me again, is like a very obvious thing to do. The ability to better manage race conditions, I think you know, like a lot of the gray hair you get in Marketo, if you care about doing your job well, is how do I make sure that I'm not tripping over myself? There's a lot of different ways to do that and a lot of different hacks and things but the kind of feeling that you can never fully have the system under control and maybe this is an impossibility you tell me as a developer to like that you always have this multiple layers of the database and things committing at various times so you can never fully have perfect control but then the ability to handle that in some more elegant way than like doing your best but always feeling that there's an outside chance that something might trip over itself.

Sanford Whiteman:
00:47:25
hmm. I mean, I do think it's kind of an unsolvable, even though it's it's not like a distributed system where distributed systems have even, you know, increased impossibility of getting of having a predictable settled state at any one point in time. But I think. The Marketo design philosophy seems to be to dumb things down and not expose the reality of what's happening under the hood to the end user. And I think that just knowing that, I mean, maybe this is crazy. I don't know if any commercial platform has ever done this, but. Having visibility in database changes have yet to be committed. You know, imagine a super awesome spy view where you could see as, leaving aside the overhead of providing this view that, but like where you could see in real time as things are written to the database. Or or or databases as databases. Don't pretend they're not databases, right? And I caution people about like I say, don't call the custom objects, a custom object table. So I'm kind of a hypocrite here. Like I'm saying, like, don't call it a table. We don't know how it's implemented. It could be four tables. It could be, you know, joined together relationally, whatever it could be. But Surely there is a happy medium between this dumb, down, I don't really know what's happening under the hood, I just have to guess, based on the fact that it's got a database with, like, there's gonna be a row level lock, right, like, that's the kind of thing you and I know about for, for years now, it's like, it's a SQL database, so we know Only one row is being updated at one time. We know that if two low steps try to update the same row, one of them has to go first and the other one has to go second, even if they're updating the same, or especially if they're updating the same field. cannot specify the order of those updates. I don't know what kind of visualization you could have of that, but it just seems like there's been a concerted effort to like conceal these essential database realities. I think you put it really well when you said you never really feel like you know what's going on with the market and it's like, you don't, you don't. I feel, and less of a Salesforce person, but I feel more secure about what's happening, the state of a Salesforce org at point N in time. Than I do about Marketo. Like, what's really happening? What's, what's in a wait step? What's waiting to commit? What's about to be overwritten? Right? Like, what, what looks the way, certain way right now? But when I refresh, it's gonna look different. There's, there's, there's, there is that uncertainty.

Justin Norris:
00:49:42
no debug log, right? So you give marketers these developer tools, but it's not like a MailChimp where it's just like, here's a glossy interface and you have these little boxes that you can play with, but you're kind of, everything else is locked down. It does actually give you a tool set. And I think that's why. I love Marketo, why lots of people love Marketo, it's like, whoa, like I can, I'm not a developer, but I can do developer esque

Sanford Whiteman:
00:50:03
Yeah. Yeah.

Justin Norris:
00:50:04
this platform, but then you're like, whoa, actually developer esque things are hard, because I have enough rope to hang myself with, and I can screw things up, and it's like, okay, I'm going to get better, and then I'm going to learn from folks like you who really understand developer principles, so things like dry, you know, not repeating yourself, centralizing things, or word of operations concerns, or You Whatever, all those kinds of things that I've picked up, but then at the end of the day, it, it only goes so far so that you don't have like the full control that maybe I presume one does in the code application where you're really writing things yourself. And so I guess that's it. It's like, maybe it's unrealistic to think that you really could ever do that. Like have your cake and eat it too. It's like, I can go so far, but no further within this interface.

Sanford Whiteman:
00:50:43
I think that. The design principle of make it seem like it's a technical person's platform, which it is to do it. Well, you have to have technical gifts. There's no doubt. I think that a person who can build a great instance like you, you know, other others of your caliber could also be great developers. If you. Want it to be bored out of your skulls.

Justin Norris:
00:51:01
In a separate timeline,

Sanford Whiteman:
00:51:02
Yeah. And I think there's a sense that it doesn't satisfy anybody completely. If you're a not very skilled or don't have those gifts, you're going to be overwhelmed and basically have a continuous anxiety. I mean, it's a brilliant platform because it kind of sells itself based on its technical flexibility. If you don't disclose how much consulting help you might need after you buy it, it seems like the solution to really any B2B marketing needs.

Justin Norris:
00:51:28
let's close with the buzzy question, which is around AI, and of all the people that I personally have a chance of interacting with on a semi regular basis, you're probably the person that maybe best would understand what actually might be happening with AI, which has become just horribly hyped, and everything has those two letters attached to it. Marketo's tried to use what was formerly called machine learning. A number of times, I think, mostly it seemed unsuccessfully, like predict your audience or deliver the right content to the right time. Maybe those capabilities are more achievable now in a meaningful way with the tools we have today, the technology we have today. But I guess even beyond Marketo, just in the broader realm of MarTech, is this hype to you? Is this a real thing that is going to have an impact on our discipline? What do you think?

Sanford Whiteman:
00:52:13
Well, I mean, I'm not one of these, you know, scoffers who's like, Oh, it's just one big database. It's just the most powerful database ever created. Speaking of LLMs and you know, in general, I'm intimidated by and impressed by a lot of it. But from a, again, from a marketing that's much marketing ops standpoint, my first, the first dread I got wasn't about what I do for a living or what you do, but the idea that people are like, I'm just going to feed. I'm going to ask at GPT to write my, uh, you know, taglines to write my content for my, for my page based on, and I'm like, and people are obviously doing that by the thousands, taking a critical eye on the output of, you know, chat, GPT and, and, and others from a marketing copy standpoint, it's like, I have not seen evidence that it's. Better, faster, or, I don't know, impressive than a copywriter would be, but the idea is to put copywriters out of business. It's the same thing that's happened in many industries. It's not that the technology is actually better than the people. That, I think we need to get past the fallacy that it's better than people. But what it could in theory be is way cheaper than people. And from a, you know, business standpoint, that's, that's all that matters to me. It's like, don't try to sell me on AI written documentation being better than handwritten documentation. You can sell me on it being faster and almost right in certain cases. But what concerns me, even, even from the standpoint of documentation, where you kind of do think that more is better, you know, that's like with documentation, the less is more. Concept is completely false. Absolutely not true. I am firmly opposed to that. I'm, you know, that I hate when things are dumbed down. The idea of expanding product documentation via AI is fascinating to me because it sounds like super awesome, great net. When something's wrong in the docs, the load on people for doing that thing wrong might actually on net, you know, be negative. So it's hard to say like the Marketo product docs have errors in them that an AI. Based doc generator couldn't make so that that's actually, that's something where I have to, I have to concede, you know what, if those docs were written by chat GPT, it couldn't make certain, I'm not saying it couldn't make new errors, but it couldn't make the errors. Like there's a, I don't know if you've noticed this in the product docs, like they're curly, uh, curly quotes in the code samples that have to be straight quotes, or it's going to be a fatal error. They're like errors in the MIME type structure for the Marketo that could never happen, but with a, an AI, you know, documentation library. But would it make other mistakes and assumptions that would then become the stuff of support tickets and confusion and the need to have it gone over by someone and, you know, you know how technical documentation is, there's maybe one person in the world who knows whether something is true or not. From my perspective, like. You know, Martech development, like front end stuff. I would love to know that some of the stuff that I've written on my blog and put out there in the world ends up being digested by chat TPT and becomes part of the corpus of things that other people are learning from because it's open source anyway. And, you know, I hope that people are able to use other people's work and get good code out of it. That's kind of the advantage of all the time that I spend diving into the underpinnings, the internals of Marketo stuff or just browser stuff in general. If you publish that and it becomes part of Chat TPT's learning, I think that's great because it has more of a payoff. That sounds to me a little bit too rosy, but in a way it has more payoff to spend three hours on something and know that people will be able to learn from that in their own code bases as opposed to having to search for you and find it on your blog. That's, that's a positive. How about you? I mean, what's what's

Justin Norris:
00:55:49
I'm, broadly aligned with your point of view. The way I've started to think about AI a little bit is like, I'm a Star Trek fan, probably not familiar with the computer on a Star Trek ship. You know, where you're like, computer, create for me a model of X, Y, Z, and then do this. So it's just like, you're giving it props, it's performing computation and it's producing an output, which is very convenient. And so I think with things like that, where it's providing convenience and allowing you to interact with information and do things with it and model things in a, some kind of virtual space that would otherwise be hard to do, or summarizing things for you, or like, you know, providing, distilling action items from a call, whatever. Totally. The idea that it will ever produce marketing copy or content

Sanford Whiteman:
00:56:34
Mm hmm.

Justin Norris:
00:56:35
that is useful seems really hard to imagine. A, because all the stuff I've seen it do is just like really basic and uninteresting. And B, because it's guaranteed to be average. It's always taking the average of the average of the average of a

Sanford Whiteman:
00:56:49
Mm hmm.

Justin Norris:
00:56:50
points. And so, does evolution just stop there? Because it's not going to... It doesn't have that spark of intuition or understanding of human nature that's going to say, like, here's like a really funny video. Is AI going to be capable of that sort of creativity? I just doubt it. So the idea of using it to generate content to me is, seems contradictory on the surface. Who knows

Sanford Whiteman:
00:57:12
No, I, I, I, no, I, I, I, I tend to agree. I mean, I'm, I'm, uh, I do follow a couple of very funny comedians. Um, they're really more like written comedians. Like, You know, punchline Twitter comedians who, who show the futility of chat GPT at understanding jokes sometimes. And it's very like, it definitely supports your concept. They're like, they'll feed it an ancient vaudeville joke and ask it to explain the joke. And it just hallucinates a completely wrong reason that it's supposed to be funny.

Justin Norris:
00:57:45
But I think to cap that point, I think humor is the perfect example of like something so basic that a child of two or three can understand a joke and laugh. And yet that the most sophisticated computer models

Sanford Whiteman:
00:57:58
right,

Justin Norris:
00:57:59
properly explain, which to some extent is a reassuring notion that there are some things that always will remain sort of beyond that reach. I think we do have to wrap, but this conversation is everything I hoped it would be, in the sense of just the,

Sanford Whiteman:
00:58:11
it was great. I could do this all The time.

Justin Norris:
00:58:13
lateral thinking, the, various topics that we covered, and I'm glad to be able to share that with the world first and foremost. Second, I appreciate you and all, all that you give to the community and that you help me with personally being my phone a friend, more times than I can count. And, uh, and sharing your knowledge so freely. So, thank you,

Sanford Whiteman:
00:58:30
Well, you know, I mean, you taught me originally the stuff that made me able to pretend to understand Marketo from the back end. So I think you did, um,

Justin Norris:
00:58:39
we're a fraction

Sanford Whiteman:
00:58:39
uh, way, way, way, way back. Um, but no, it's really to be on, I think it's my first official podcast. So that's something if I ever start one of my own, I will ask about your tech stack once you get it figured out here.