Reimagine Marketing: A podcast from SAS

BRIAN ALFOND: Hello, folks. Welcome to this episode of the Reimagine Marketing podcast. I'm your host, Brian Alfond. And I'm part of SAS's Global Customer Intelligence Group where I work with customers to find elegant and creative solutions to their marketing problem. As we move from the first half of this podcast season to the second half, I'm hoping to do more interview/conversational type of episodes. And as part of this transition, I was looking for someone I could talk to, to recap the main themes from the first half of the season where we focused on the importance of things, like good processes, change management, and doing and buying the things that will work best for your organization. And my guest today is just such a person.

Marisa Scorsone is a marketing operations and management consultant with over 18 years experience helping marketing organizations improve their marketing operation's efficiency and effectiveness. She combined skills and strategic positioning, business process re-engineering, software implementation, and training, design, and delivery. Marisa has worked with software from all the leading vendors and with a variety of clients such as tech giants, multinational financial institutions, telcos, and retail brands that you would know by heart.

In one of my past lives, I had the pleasure of working with Marisa on a couple of projects and found her approach and perspective refreshing, powerful, and most importantly, effective. Welcome, Marisa, and thank you for taking the time to speak with me. As I noted in your bio, you've helped customers implement new marketing processes and technologies for a variety of customers. And you've certainly been in the trenches far more recently than I have than I have, rather. I'm interested in what if anything you think I got right, what I missed, where I'm wrong, and any comments you may have had about what you've listened to so far.

MARISA SCORSONE: Well, hello, and thank you, Brian, for that great intro and for welcoming me on the show. So let's kick it off with your first question. We're asking me to judge your performance.

BRIAN ALFOND: [LAUGHS] I'm scared now.

MARISA SCORSONE: No, no. You did a lot right. In fact, I picked up a lot of my early tips and life hacks from you. One of the things that I remember is the fact that you held firmly to the methodology. When we were at a client site, it taught me it was OK to push back if it's good for the work, right? As far as what you did wrong, a lot of dad jokes. Just way too many dad jokes.

BRIAN ALFOND: Yes, but true to brand, right? Yes, OK.

MARISA SCORSONE: Very much so. But I mean, in all reality, there is really no one-size-fits-all approach. There are guidelines to help right size for an organization's needs. For example, the importance of understanding what the client wants to solve for, their objectives and goals. And even more importantly, is the client ready? Is the leadership support there? Are the resources available? Do they have the bandwidth, the timeline, the budget, and things like that? So those are a few of the guidelines that I hold to when entering a client site and starting a project.

BRIAN ALFOND: I feel like we might be on a client side again, especially the objectives and goals. How can you hit a target if you don't know what you're aiming for? And then I think you definitely-- thank you for reiterating leadership support, right? If you don't have that, then really, you're sunk if you're looking to make some sort of change in your organization. So hopefully, you have that. I appreciate it that you would reiterate those. So what are you seeing out there in the world in terms of your customers that are seeking your assistance? So there any specific trends or themes that you're encountering again and again?

MARISA SCORSONE: Yeah, but just quickly to get back to the leadership support. And we hear that term thrown around a lot. And I just want to articulate what we mean by leadership support. A lot of leaders are excited when they bring somebody on. Obviously, they're funding this. They're excited about it.

But what I'm referring to is more of that ongoing leadership support and the enablement within the organization and the SMEs that we're working with to offer up their time and their resources and to support that initiative. And so there's leadership support from, OK, we have the green light to move forward. And then there's that ongoing support throughout the lifecycle of the implementation. So just wanted to go back and clarify that.

BRIAN ALFOND: Now, that's a really good point. I think because I'm still thinking with the consultant brand, I just want to get the heck out of there, right? But did they-- which is a-- it's the truth. You want to get the project done. You want them to be successful and then move on. But the support you're talking about to continue to encourage the growth and the adoption of the solution is key. So thank you for that. I do appreciate it.

MARISA SCORSONE: Yeah, as far as common themes that I'm seeing on client sites that I've personally come across on client sites, it's usually the same four or five, right? Folks are using to looking to increase cross-functional collaboration, perhaps, standardize processes so they can reuse them. A lot of times, they're looking to provide additional clarity around who does what within the organizations-- within the organization as it applies to the work that they're doing.

And then some peripheral bells and whistles that like to add is that they want better operational metrics so that they can more effectively inform future work and assess past work. And when it all comes down to it, why are they looking to solve for this? And it's basically to increase the bottom line an overall optimization of the work that they're doing.

BRIAN ALFOND: Doesn't sound like these common themes have changed much in the years since I've left the consulting side of things. And it's both reassuring in the fact that things don't change, but also a little alarming in the fact that no matter what, you're going to find silos, right? You're going to find those silos. And you need that collaboration in order to get things done as efficiently as possible. So I guess I'm not that far out of the loop as I maybe thought I was. So that's cool from my perspective.

But I noticed-- I'm recalling, rather. And I've noticed in speaking on the sales side now that very often, you're talking about software. And you're talking to that client about the software. And it can do this and could do that. We can help do all of these things. And I wonder if the organization doesn't think, Oh, well, if we just buy this software, it's going to solve all of our problems. And whether you're doing a CRM package or whether we're in your specialty of marketing ops, I'm hoping you'll agree with me that it's not the software alone.

MARISA SCORSONE: In marketing ops, I don't think software alone ever solves a problem. Using software with broken or weak frameworks and processes basically enables you to be inefficient and ineffective much faster.

BRIAN ALFOND: [LAUGHS] OK.

MARISA SCORSONE: So we should look at software as more of a tool to implement or support solutions rather than the solution in and of itself.

BRIAN ALFOND: I agree, and I think it's almost every type of software. It's almost any type of problem that you have in your life. You have to put in that work and figure out the process and figure out what that framework should be like. How do you work to bring that about or to overcome maybe any resistance that the organization has? Oh, no, just take what we're doing and put it in there?

MARISA SCORSONE: Well, first of all, we ask what's not working and why it isn't working. And that oftentimes is probably less to do with this technology that they're currently using or lack thereof and more the processes that are in place. And let me add it also, there's another component that we don't really consider a lot. And it's the people. And it's the organizational structure. Do we have the functionality in place in the organ-- and then we have the resources and the people to support those functions that we need to get the work done.

BRIAN ALFOND: That's a very good point. Yes, the operating model might need to change, as well, especially if you're bringing in efficient capabilities that might touch a skill set that isn't in the organization. I agree with that 100%. And that's one of the many things that could potentially get in the way of an organization's success when trying to implement changes. I'm sure you've seen probably 1,000 other ones. Any high points there or any things to tell organizations what to watch out for?

MARISA SCORSONE: Watch out for as far as implementing software or just--

BRIAN ALFOND: Yeah, when they're going through an initiative such of this. And they're bringing you in. And they're bringing in some software. Essentially, I'm asking, what gets in the way of an organization's success when they're trying to implement change and change-involve software, people, and process?

MARISA SCORSONE: Yeah, so like as I referenced before, understanding the software and the processes that are involved in understanding that they will need to be tweaked as the company continues to evolve. And then secondly, not choosing a software based on its popularity or a fancy bell and whistle that it has but doesn't really fit the need. Or does it help you solve what you're looking to solve or support what you're looking to support?

Another area that's often forgotten or neglected is recognizing the importance of change management and starting that process early on. In my ideal world, change management starts the day that the implementation starts even at the point of discovery, understanding what can potentially change the potential impacts to the organization and the people working within it and then getting people involved in the change management activities and planning.

And then finally, also, clients sometimes insist on choosing the methodology in which to do this work, meaning-- and I'm talking about methodology. Let's just talk about project management methodology that we employ to implement a piece of software, for example. And so if a company is using Agile to do their day-to-day work and marketing, get a campaign out there doing Agile marketing, there's this, I guess, notion or assumption that Agile is the way to implement the software as well. And that might not necessarily be the right approach to get this implementation off its feet or even completed.

BRIAN ALFOND: I'm not sure we have enough time, nor do we have the noncursing vocabulary to go down some of the paths on the implementation discussion or as we shortened it all those years ago to implementology, right? The implementation methodology.

MARISA SCORSONE: Love a good portmanteau.

BRIAN ALFOND: Yes, a very good portmanteau. But I agree with you obviously. One of these days, I'll find somebody who disagrees with something I had to say. But it's very, very important that you go about this in a way. So would you mind describing for the listeners a little bit to the framework that you use?

MARISA SCORSONE: Well, the framework-- so there is a framework here. Correct. So before I even go into the implementology, it's really important. And this is part of the methodology. But it lies outside as part of a pre-planning or determining factors in the methodology. And one of them is making sure that we define the requirements. And that usually entails knowing what we're solving for. And that sounds like a really simple question and answer to give. But a lot of times, we know what we want to fix in our day-to-day work or maybe even on a larger more strategic view. But does it ladder up to your higher-level goals and objectives both within the department that you're solving for or within the organization?

So there's that consideration when determining the requirements. And then also, are we considering the impacts that these changes or this implementation will have either further upstream or downstream or even laterally across the organization? And we're fixing a problem within, for example, the marketing department. But how will that impact the finance department, HR, other departments that are tangential partners? And oftentimes, that's really not front of mind when we're considering our requirements.

BRIAN ALFOND: And I think that it's not front of mind because people are trying to solve that problem, right? It hurts figuratively, and you want to solve that pain. But knowing that you're going to be dropping a pebble into a pond, and there's going to be all these ripples. I think maybe that's why some customers don't want to-- they think it's going to be too hard, right?

MARISA SCORSONE: Right, yeah. And they're just, like you said, they're just trying to stop the bleeding. But it's not enough to stop the bleeding. How we prevent infection, right? How do we do these-- how do we do these other things that can have long-term downstream effects? So I think those are important things to consider when defining our requirements. They're not necessarily just the immediate business requirements.

And then secondly is establishing a baseline. So we need to accurately assess and document our current state processes and our tech stack. It's not enough to say, Oh, we're using this project management tool. It's not working. We want to replace this with a tool that does this, this and this. Well, is this project management tool operating in a vacuum? Is it hooked into other systems that we're utilizing or that we're feeding information back and forth from?

So we want to document that so that there's like a canonical document to go back and look at and say, this is how everything is set up in the organization now. Does it still work? And what do we need to change? And when we do change those things, what other areas or what other processes and technologies will be affected and how we do we need to adjust for that. So that's the pre-legwork before we can figure out what implementology to apply.

BRIAN ALFOND: And how do you go about determining what implementology or what implementation methodology to apply? Does it change from customer to customer? Or are you fairly consistent with how you're going about this?

MARISA SCORSONE: Oh, it varies from customer to customer. There are a lot of other factors that contribute to it, timeline, budgets if we're taking a roadmap approach, meaning, oh, let's just implement the core functionality or core areas that we need to fix first right away. And that will depend. Typically in my experience, it's some variation of a waterfall into Agile, hybrid type of methodology. But regardless of what methodology that we choose, there's still key components that are found in both, right? So we need to do some type of planning, discovery, design, configuration, testing, et cetera.

The areas that are often omitted in both or the hybrid version of those methodologies a lot are that pre-planning, doing that final scoping after they've committed to a project and tweaking it and then also checking any type of system compatibility both with processes and software. Another area is the discovery is not a fully vetted-out discovery. So somebody goes off and speaks to a bunch of subject matter experts.

They document what they think the processes are, what their current experience is. But we don't take that up, follow that through to the end, and have that validated by the rest of the organization, and then also signed off by maybe some type of leadership to say yes, like, I vouch for this is how things are. And that serves as a way to verify that we are working from the correct set of baseline assumptions and baseline circumstances.

And then last but not least, again, going back to change management, understanding the importance of that, and planning for the not only the change within the organization, but how are we going to roll out this new software or process, and how the consultant or whoever's in charge of implementing this is going to transition off who are we going to hand off those responsibilities for the upkeep and maintenance or any minor changes to? So those are the areas that are-- that I would say to pay special attention to because they're often neglected.

BRIAN ALFOND: I hear that. And I hope that people listening to this-- and if you're thinking of doing a project like this here that as well. I'm going to take a chance here because one of the things that I have encountered in speaking with customers-- and you and I, full disclosure, we've talked about this offline before-- walk into a customer-- Oh, we're Agile here in our marketing department. Or we execute these campaigns using the Agile methodology.

And sometimes, I think it's a little bit like The Princess Bride. That word you keep using. I'm not sure it means what you think it means type of thing. And I'm wondering if you're encountering this because we used to play Buzzword Bingo back in the day. And I think then-- what was the one that we're always-- I haven't see them. You're much younger than I am. So I get old, and I forget these things.

But there was another buzzword methodology that was around at the time. And we were trying to conform everything into that. But you can't take a process that's used for maybe developing software to easily map that over to configuring your marketing solution. Would you agree, disagree, or differ?

MARISA SCORSONE: Agree, yeah. And I'm glad because you brought it back to a point that I had made earlier about folks wanting to use the Agile Project Management methodology or waterfall or whatever that they're using internally to conduct business with. And so I think a good place to start is to distinguish between when we talk about things, like Agile, for example, and there's various types of Agile. There's Kanban. There's Scrum. There's APF, which is Adaptive Project Framework, which again, is just a repackaged way of referring to Agile, which if we take a step far back enough, it's all if you remember the '90s and early 2000s, the Six Sigma.

BRIAN ALFOND: That's what I was looking for. Thank you. Evidently, I don't remember the '90s or 2000. [LAUGHS]

MARISA SCORSONE: So a long, long time ago, at least, it is to--

BRIAN ALFOND: Me.

MARISA SCORSONE: --younger. Yeah, well, younger folks are not both of us. So I think it's good to take a step back and distinguish between when we talk about Agile and Agile methodology, there's Agile in terms of developing software from scratch. And then more recently, marketing organizations have adopted Agile-like methodologies, to get marketing campaigns out the door.

Those two are not the same. We use a lot of the same tenets where we're doing things in sprints. And we're going back and testing and reviewing and tweaking and then reissuing or making adjustments, certainly very useful. And specifically in software development, extremely useful if you're creating code from scratch.

BRIAN ALFOND: Right.

MARISA SCORSONE: A lot of these implementations are for out-of-the-box solutions that are-- we refer to as you can't really use them out of the box. I shouldn't say out of the box. But they are highly configurable. So all of the capabilities exist within the coding or is coded within the software. Our job is to enable what makes sense in accordance with whatever processes we develop for the specific client.

So we can't fully apply Agile software development methodology to these boxed software solutions. And I just wanted to make that distinction because a lot of times, clients don't know. And rightfully, they shouldn't know. They don't if we're developing this code or not. It's not their job to know. So I just wanted to level-set that way and just make that distinction.

BRIAN ALFOND: I think it's a good one. And as somebody who tends to operate and think in terms of metaphors, I've always explained, we're giving you a box of LEGOs. And there are different sizes, pieces, and shapes and different colors in this box of LEGOs. And you can build anything you want to do with this box of LEGOs. But what you can't do easily is design a new LEGO piece that isn't part of this box.

MARISA SCORSONE: That's a great metaphor. I need to start using that more often.

BRIAN ALFOND: Well, you're welcomed. You're welcome to take-- to do whatever you want with that one. I don't know. Just, it's how my mind works. But we've worked together long enough that you know that. I'm interested in customers. We're going to keep this all anonymous obviously. But in customer success stories or even though they might be somewhat more fun to talk about from a schadenfreudic way, the horror stories, where have you been successful? What have you seen where it hasn't worked out the way you want? And what were you and the organization able to learn from both?

MARISA SCORSONE: OK, so as far as success stories go, I tend to be more successful at organizations that have a culture of well-defined structured processes or that have been around for a while, like pharma companies, for example. And I'm not sure if it's because these companies are subject to heavy regulatory scrutiny more so than other companies. And so they're used to having to validate requirements and enforcing SOPs.

And then there's other industries, like either retail or media or social media that can be more challenging, especially when a lot of the primary SMEs and folks that I speak with can sometimes be allowed to color outside of the lines. As long as they get their work done or produce a deliverable on time, they are not as beholden to the strict processes that are supported by extremely verified and validated requirements. So that's what I found in my personal experience.

BRIAN ALFOND: Interesting.

MARISA SCORSONE: So I had one client. And again, not naming names.

BRIAN ALFOND: Yes, let's not.

MARISA SCORSONE: But they did want to-- they wanted to optimize their existing marketing op stacks by integrating their project management and their campaign development and execution solutions. But there's SMEs of folks that I were speaking with. And let me just not assume people know what SMEs are.

SMEs are subject matter experts. They lacked that leadership support needed to prioritize that implementation or that work. And they weren't given the bandwidth to meaningfully engage without letting their day-to-day work suffer. So they weren't able to really properly validate requirements or test and build things out.

BRIAN ALFOND: I had a client who had that exact same situation. In the way that the sponsor described it to me was it's really hard to steer the boat and figure out where you're going when you're so busy just trying to bail it out and keep it afloat. And so you have to draw that line between, OK, well, you have to keep your day to day. But at the same-- and if the day to day is going so poorly that that's really where you are, then maybe now isn't the time for that project.

MARISA SCORSONE: Right, and I love how you just tie everything into a neat little bow for me referencing. No, you really, you make-- you reference the point that I made early on as far as getting ready to do the work. Are you ready to do this? Is leadership ready to support? Are the resources that are going to be working with you available, willing, and able to do the work that needs to be done?

BRIAN ALFOND: It's all cyclical. It all comes back to do that prep work like you said. I know that we talked about one other example that I thought would be very informative. Again, we won't name any names. But please, if you can remember if you can recall that one.

MARISA SCORSONE: Oh, yes, there was a company. It was a startup company that was part of a larger, more established company. They wanted to implement an MRM solution, a Marketing Resource Management solution ASAP. And our definitions of ASAP, we found out later varied wildly. I was thinking more along three months. They were thinking last week.

But we finally came to some type of common ground on the timeline. However, I don't think I was able to impress upon them the importance of doing a proper requirements gathering so that we can understand what we were trying to build and what we are trying to solve for by replacing the Google Docs or the Excel sheets that they were using to manage their campaigns.

Needless to say, we finally implemented a piece of software after extraordinary effort because there was a lot of rework done because the lines of what was sufficient and what wasn't as far as a solution kept moving back and forth because we didn't have that Bible to refer back to as a business requirements document. So long story short, we ended up ripping out that entire system only to then be instructed to reimplement another system without again doing that performing the due diligence of requirements gathering.

That cycle happened about three times within a two-year period. And I'm hoping-- fingers crossed-- I'm no longer there. But after the third time, maybe they just are able to see a little bit more of the value in doing that work up front. Coincidentally, they were also a quote, unquote, "Agile shop." And we need to do a little bit of waterfall-type activity, a little bit of working up front without actually delivering anything upfront but getting our thoughts together. So that again ties in to making sure that we do our due diligence and don't stick hard and fast to a specific methodology because it's your chosen one within the organization and maybe determine whether it makes sense for this type of work or not.

BRIAN ALFOND: Yeah, that I'm wondering if they'd ever heard the quote that's attributed to Einstein, which I'm sure everybody else can quote for me, but something about doing the same thing over and over again and then think we've encountered that.

MARISA SCORSONE: Insanity. Yes, insanity quote.

BRIAN ALFOND: Exactly.

MARISA SCORSONE: It felt like insanity. And I'm sure it felt like insanity on their end because I don't think they were understanding what went wrong. And a lot of times, well, the software doesn't work. Or this is we shouldn't be using this methodology when in reality was something as simple as let's go back to the basics. What are the processes that we're trying to implement? And how are we trying to implement them? And are we fully-- are we vetting them out before we decide we're going to configure them into our software? Because it was really a matter of we want to create this type of project plan. Go ahead and put it in the system without understanding all the impacts to doing the process this way or setting it up this way. And all the resources that would be affected.

BRIAN ALFOND: Thinking we can all be glad that that company doesn't make houses. I have a question I ask customers when I'm talking to or people I'm interviewing sometimes. It's the, quote, unquote, "magic wand" question. So if I were to hand you a magic wand, and you could change one thing about the state of what you consider to be your industry right now, or maybe I could be generous like a genie and give you three wishes, are there are a couple of things that if you just go poof, it would make your life a whole lot easier?

MARISA SCORSONE: Yep, I'm going to try to get a twofer out of this. So I'm going to say it's--

BRIAN ALFOND: Just can't wish for more wishes.

MARISA SCORSONE: One. But then just stick-- slide two wishes in there. So one of them would be to, I think most importantly, set realistic expectations with clients. I don't want to use that cliche of overpromising and under-delivering.

BRIAN ALFOND: It works.

MARISA SCORSONE: It does. It does. It's just very-- it's like fingers on a chalkboard when I hear it. It's like that low-hanging fruit phrase. But no, but it does work. And sometimes it's OK for a client and a consultant to just walk away from each other and not work together if it's not a right fit. And then secondly, which ties into the first point that I made, is to present the implementation methodology as part of the deliverable itself, not as a means of producing the deliverable.

In other words, we'd say something along the lines of this is our standard. It's our vetted methodology. And if we use your untested methodology, you can lower your chances of success. Oftentimes, that allows the client to pause and reassess, like, do we want to be successful more than we want to be right or more than we want to use the methodology that we use in-house? So that's a little phraseology that I've picked up along the way to help mitigate or work through that conversation.

BRIAN ALFOND: That's a very polite way to say something that my late father, who was an auto mechanic, he had a sign in the shop-- that just gave different rates. If I do it, it's $50 an hour. If you want to watch, it's $75 an hour. If you want to help, it's $125 an hour because let the expert do what the expert is good at is essentially, I think, what you're saying in a very nice way.

MARISA SCORSONE: Yeah, and by the way, I learned that from you many, many years ago, about 15 years ago. And I saw how firm you were when clients pushed back when they were clearly wrong. And they didn't know they were wrong. They really believed that they were doing the right thing. They just don't have the benefit of how do they say it? They haven't been to this rodeo before of having implementing this type of software.

And I was a little bit nervous when you bring up that conversation and just how forcefully you push back. And then they almost always eventually came around and would come back and say you know what. Hmm, you are right. I'm glad that I listened to you. Or I'm glad that you gave me some resistance on that.

BRIAN ALFOND: Thank you for that. And I only ever had one customer actually hit me. So that was good. And I learned to mellow that approach over the years. But I think it was just have a little faith. And you've obviously learned that. And you're out there doing that. So I'm happy.

I think that's a good place to wrap up this episode. And Thanks, Marisa, for your time and thanks for the stories. And boy, you sparked some memories. I hope that we get an opportunity to work together again in the near future. I think would be a lot of fun. If somebody hearing this was interested in engaging your services or talking to you, is there a real concise or easy way for them to get a hold of you?

MARISA SCORSONE: Through LinkedIn. And my LinkedIn handle is mscorsone. It's M-S-C-O-R-S-O-N-E. I'm not sure if you can drop that in the--

BRIAN ALFOND: I'm sure we can pass that on over in the show notes. So that's great.

MARISA SCORSONE: Just, if I can do a shameless plug, you mentioned to have a little faith. And conveniently, coincidentally, a couple of days ago, I just published an article on LinkedIn about having faith or trust for the process for the consulting process. So if you're interested or you're curious, you can check that out. And I just want to thank you again for having me on and allowing me to wax poetic about--

BRIAN ALFOND: [LAUGHS]

MARISA SCORSONE: --marketing stories.

BRIAN ALFOND: Absolutely, and we'll include a link to that article in the show notes as well. So folks, if you enjoyed today's show or even if you didn't, you can head on over to sas.com, reimaginemarketingpodcast-- all one word-- to join in the conversation. You can subscribe to the series on your favorite podcast platforms too. Just search for Reimagine Marketing.

If you have a topic or guest idea, please email us at reimaginemarketingpodcast@sas.com where again, Reimagine Marketing podcast is all one word. I appreciate you listening. I hope you'll consider joining me next time. Until then, this is Brian Alfond for Marisa Scorsone hoping all the important things in your life are good.