You Ask, I Answer: Learning New Systems in MarTech?

In today's episode, Bob asks, what's the best way to quickly get your mind wrapped around how new software works and to come up with a strategy for applying it to your projects. In the end, it comes down to classification and understanding where that piece of software fits in your marketing technology stack. The easiest analogy I can make is that if I if you look around your kitchen, right, and there's all these appliances, and I put a new appliance in the kitchen, if that appliance is any good at all, its form should hint at its function, right? Uh you should broadly be able to tell that you know, that kind of looks like a coffee machine, or it kind of looks like a toaster, or it kind of looks like a frying pan. Um then from there, even if you don't know the specifics, you know broadly what it does.

So if you have this thing or you're trying to evaluate this thing, uh you can kind of get a sense of of what it's supposed to do. Uh, you know, a bread machine, for example, looks uh little bit open it up, looks like an oven inside, right? Uh if the appl, you can't tell, like you open up things that look like doors and stuff, and and you just can't tell what the thing does, it it's not a very good appliance, right? If you think about software, and you think about these lovely devices, right? You can hand this to a five-year-old, and they can open up apps, they can do stuff, uh, they can play games, and there's no manual, they don't need a manual, they don't need anything at all to get going.

It's very intuitive for them. That's the hallmark of great software is you can open it up and it's intuitive enough that you have a sense of what it should be doing. Again, you may not know the specifics, but you know broadly, this is a video editing software, this is lead management software, this is email software. If you can't tell that, it's not very good software. It's not well designed at all, and chances are it's probably not going to be uh not going to help you deliver results.

I'm trying to think if there's any exceptions to that rule. And that generally speaking, until you get to writing software, that's not that's that's generally true. Uh once you get to writing software, like in a in a development environment, then that's when things do start to get a little less user-friendly. But for the average user, the average marketer, uh the form should dictate the function, and it uh to you, it should be apparent what the function is, and if it doesn't, that's not very good software. Now, if you are trying to find new software and you're trying to evaluate new software, that's that's a different bucket of worms.

Um but just because something somebody publishes something new and says, hey, uh here's the thing, that's how you evaluate it. Say, what does it do? Uh and if they can't explain it without resorting to a bunch of buzzwords uh and uh jargon, then it also probably doesn't do anything that's helpful or new. If you think about software kind of like um the phases of a clinical trial, it's not a bad framework to adopt. So the phases of a clinical trial, broadly speaking, are phase one, does it cause harm?

Phase two, does it work at all? And phase three, does it work better than an existing solution? When you look at a piece of software, number one, it does it, does it cause harm? Is it is is it uh you know, damaging to your systems? Uh certainly you don't want to ever integrate something in your Martex stack that's gonna start like accidentally deleting data.

Uh right, that would be really bad. Step two, does the software do anything at all that's productive or useful, right? Somebody says this is lead management software and there's no lead scoring, right? Okay, that's not very helpful. Um that stage three is does it work better than an existing solution?

Right? That is the uh the ex in pharma it's called the standard of care, and in software you can call it whatever you want. But if you have a CRM and it doesn't do a better job than your existing CRM, you have a pretty clear idea that, like, yeah, this this package is not for us. And it can be tricky, particularly with more complex pieces of software. It may take there may be an evaluation window that takes a little bit longer, but at the end of the day, those three phases are not bad benchmarks to evaluate really anything on, but especially software.

Does it harm? Does it help at all? Does it help better than the existing solution? Um for new software where there is no existing category, like you know, maybe you're d deploying for your very first time uh an integrated machine learning environment. It's gonna be harder to make those determinations because you literally have no prior experience.

And that's where having a subject matter expert or domain expert to come in and uh evaluate it with you uh will be helpful. You you want to be able to buddy up with somebody and say, hey, this is you know, IBM's new development environment. Uh what do you think of it? Uh and they can they should ask you, okay, well, what would you do with this thing? What kinds of problems would you be trying to solve that would need an integrated machine learning environment?

Oh, well, we have all these leads and we want to build a better lead score. Okay. So they could take the data, put it into the system and say, well, here's what it came up with. Is this at all accurate? Um and is this uh is this better than the scores that you've got?

And you as the the subject matter expert in in marketing could go, well, no, I mean, like, there's a whole bunch of people here who are college students who are not qualified leads in any sense of the uh of the word, and yet the system has scored them, you know, A plus leads. So clearly this the system does not work. Or it would say, here's it managed to dig out all the CEOs who have signing authority, and our previous system scored them B's, this is scoring them A's. That's that's pretty good. So classify and then test are the ways that you wrap your brain around new software and figuring out how it applies to existing things.

When it comes to applying it into your existing strategy, the question you have to ask is where does it apply? Uh, and how easy it is it to drop in. One of the criteria I have for marketing technology software is how easy it is to integrate. If it doesn't have APIs, if it doesn't have built-in integrations, if other products in the stack don't support it, there's a good chance that it's gonna be more of a pain than than not, right? That kind of goes back to um you know, not causing harm.

If you've got something that is going to require a whole bunch of extra development time and a whole bunch of extra resources, that's taking away from resources that you probably don't have a whole lot of. Um, in that evaluation, look at what it's gonna take to swap this piece in uh for an existing piece or add it to your existing workflow. How well does it connect with us? How well does it play with others, if you will? So, classification, clinical trial phases, integration.

Those three steps should get you most of the way towards understanding how any piece of software works and strategically where it fits into the existing system so that it improves the system. There are cases where you'll have multiplicative effects from a piece of software that will do multiple things in your existing system, and those are the gems to keep. And those are the ones that you definitely want to keep because they offer in a lot of extra value. If you have follow up questions, leave them in the comments box below. Subscribe to the YouTube channel and the newsletter.

We'll talk to you soon. Take care.