Speaker 0: Hi, everyone. Uh, for those of us joining today for the first time, welcome. We are excited for you to be joining in on ParDreamin. My name is Kate Godley, and I work with Sercante. And I’m here to introduce Lucy Mazzolonis and Jaime Lopez while they discuss future-proofing your Pardot through solid requirements gathering. Welcome, Lucy and Jaime.

Speaker 1: So much, Kate, for such a great introduction. And, um, yes, for anyone who’s joining and this is their first session, welcome. Um, I’m sure some of you have seen others so far today. Um, and, you know, we really appreciate you guys choosing to come and listen to us, uh, in the best part of thirty minutes. So we’re gonna talk about future-proofing your Pardot, um, through gathering better requirements, solid requirements. So this is thinking about what you should be asking your fellow users in order to figure out what they need from Pardot before you even touch the technology and start configuring. So I’m Lucy. Um, for those of you who don’t know, I’m, uh, six-time certified, and I spent a few years working as a, um, marketing automation consultant with Salesforce and Pardot. During that time, I just saw so many different types of Pardot projects and different types. Um, so I I know it’s really cliché to say this, but I’ve seen the good, the bad, and the ugly when it comes to Pardot. Nowadays, I’m actually the editor of salesforceben.com. Um, so we’re a news site and blog. We cover all things Salesforce, um, which is actually really hard with the ecosystem expanding so fast. And in 2016, I started The Drip, which, um, is all about marketing automation and shares kind of some of my war stories from working with Pardot. So, um, yeah, if you wanna read up more on Pardot from a consultant’s point of view, um, please check it out. Um, I’m also a marketing champion, and I co-run the London Pardot user group.

Speaker 2: Thank you, Lucy. I’m so happy to be here with you today also talking about this topic. My name is Jaime Lopez. I’m a three-time software certified. I’m an nuclear engineer by training. But, uh, surprisingly, I’ve spent most of my career working with data-driven marketing. It’s great. Um, I spent almost the past seven years building a world-class data-driven marketing operations practice at an industrial company called Wärtsilä, uh, which provides equipment, services for the energy and maritime markets. I have recently joined Aiven, which is a company that provides managed database infrastructure in the cloud. But I’m gonna talk today mostly about work I did, um, at Wärtsilä. So requirements and projects that have to do with very large engines, um, to prepare a cruise vessel, generally, just in the jungle. And just think about large, very complex enterprise environments, um, and industries where it can be quite difficult to showcase the value of marketing. There, at Wärtsilä, my team, uh, of which you can also find several members presenting up for dreaming today and and and during the other days, we leveraged machine learning to prove that what we were doing contributes to the growth of that business, and we could prove that approximately 8% of our sales in 2020 were caused by marketing, not just correlated. And we were returning approximately €5 in profit for each euro invested in marketing. And I’m also a Salesforce marketing champion.

Speaker 1: Yeah. And, um, I know, Jaime, you might be a bit embarrassed with me saying this, but I was so delighted to co to co-present with you because what I’ve noticed is that you really have pioneered both, like, the analytics side of Pardot and all the AI innovations that are going on. Um, so really drawing Pardot beyond its traditional form. Um, and as we’ll see, the more products that get added to Pardot, um, this is why this is why this topic is so important because it needs to be discovered properly.

Um, so why requirements, um, gathering, and why not? So there are four compelling reasons that we thought of why you should take this seriously. Um, for start, career development, um, this skill plays a huge role in advancing as a Pardot or Salesforce admin or if you wanna transition into a consulting role. Um, but, overall, it’ll enable you to become more vocal and visible, um, within the business you for project success. So it’s a process that’s critical for reaching a better outcome when, um, the project is eventually completed. Pardot is deceptively simple. So you may think you can plug and play, um, with next-node configuration, but, actually, it’s a huge misconception. Um, and it’s tempting to skip out, um, requirements gathering when there’s a tight deadline or, um, you’ve got limited people working on your project. But that’s you would likely to user adoption issues, um, further down the line. Um, but but worse, you’ll make, you know, you could make the marketing team feel a bit sidelined if they don’t feel like you’ve designed something with them in mind. So, yeah, on a similar note, Pardot is not an island. Um, as I already mentioned, the more related products that your Pardot setup, Salesforce orgs are becoming more complex increasingly, um, and there’s a greater reliance on Pardot from multiple teams. Um, and then it’s the for, um, especially if you’ve tried to study for the Pardot consultant, um, certification. It it’s it’s a very broad and subjective topic. So that’s why we were so keen to share, um, what we’ve learned in order to help, um, you know, mark requirements gathering. So, um, we’re just going to launch a quick poll, I believe.

Speaker 2: Yes. That is correct. We want to start with our first poll where we will ask you, uh, who are you, basically. We wanna have a pulse onto onto who is listening to us today and how does this topic relate to you. But as Lucy mentioned, you’re probably good leaving the straw hat, the flip-flops in the closet. Pardot is no longer an island. Every release brings it closer to the core, to even others products like WCrm, and, um, I predict that the role of a Pardot-only admin will be extinct in a few years. So now that you can, get trained, get even certified in core, and see your existing Pardot expertise as your special superpower. So let’s go with that poll.

Speaker 1: Yeah. How are we doing? How’s it looking? Who have we got in the house today?

Speaker 0: So, uh, it looks like we’re still getting a couple of votes in here, but we have 54.3% are Pardot admins. So the bulk of people in the room are Pardot admins, followed up next closely by consultants at around 22%. Oh, wow. Salesforce admins at 18%, and then marketing super users coming in at 8%.

Speaker 1: Wow. That’s interesting. Pretty good split. That’s that’s kind of like we expected, I suppose.

Speaker 2: Yeah. I would say so.

Speaker 1: Great. So testing. Um, let’s so sorry for the 22% of consultants that probably already know what, uh, requirements gathering is, but, um, let’s start from there. It’s a good place to start. So there have been plenty of frameworks, I guess, you know, online and over the years about what requirements gathering actually is, but for the purposes of this presentation, I’ll just keep it very high level. Um, so we’ve defined it as asking and observing users about how they are currently using technology and their future aspirations, um, what they hope technology will enable them to achieve in their job. Requirements gathering based on factors and others. Um, so the project type, whether it’s for the sales team, service, marketing, etcetera, um, the project size, and the industry. Um, for example, if you’re, um, in a more sensitive industry like, um, health care or financial services, you may have to consider other security protocols, um, as part of your requirements gathering. And where it fits into the project life cycle, if we look at this diagram, um, it’s at the top. It’s the first stage. Um, it comes before you design the solution. And notice it comes far before testing and user access acceptance test. Um, so that should never really be the first point that users, uh, hear about what’s going to be developed. That that should be all done at the requirements gathering stage. So we’ve already alluded to this, um, but just to reiterate, why not? It’s an important point. Um, so it’s essential for designing and delivering solutions that meet user end needs and expectations. Um, say leave no stone unturned, leverage what technology is at your disposal, um, understand how the business operates, and in turn, reduce assumptions. Just a real-life example, I was called into a project once. Um, it was for customer journey, email marketing automation, and I had those flows handed to me, so, like, the mappings of the email journeys. And I was just told this is a plan to implement. Um, one day, I casually mentioned it to one of the project stakeholders. She was, um, one of the business development managers, and she hadn’t been consulted. That was the first alarm bell in my mind. Um, then I found out through a few more conversations and a bit of investigation that the they they were totally oversimplified and wouldn’t work in tandem to how the business development team would actually work, um, and how custom their Salesforce org was. So it turns out no one had been consulted. And that’s, you know, day the day that I learned to always check no matter, you know, if someone’s handing me something that looks official and looks like it’s ready to implement. Um, you should always ask. Um, so and what about you, Jaime? Have you had anything similar?

Speaker 2: Unfortunately, I do, and I think that every solution designer, admin, consultant has some some nightmare they still wake up to in this. Um, for me, it’s very important to underline that if you haven’t agreed on what the requirements are, you can simply just never deliver a solution that satisfies your stakeholders, either now or or in the future. It’s a little bit like trying to herd cats. It’s not gonna happen. Um, and if there’s a topic, um, I wish I had invested time in learning earlier in my career. It’s probably project management and requirements gathering. It’s it’s a very important part of it because your requirements find your scope, and scope, resources, and time are your project management triangle. So if you don’t do this well, you will encounter as I have as well cases of scope creep, constantly get asked to also have this small piece of project now that you’re working on it, or even worse cases where somebody didn’t do a job with requirements and the solution totally messed up the private instance. Like, not too long ago, I woke up to 55,000 sync errors overnight in an instance that had, like, 300,000 prospects because somebody just didn’t bother to consider the part that might be affected by a solution built in Sales Cloud. So as a team leader, also, I can tell you that absolutely crucial for the well-being of your marketing operations team. Here process, here timeline for requirements. If not, the goalpost will be moving constantly for your people. Your people will get frustrated because they’re not able able to deliver a good solution, and it’s not their fault. It’s the requester’s fault for me in the goalpost and, by extension, your fault as a team leader for allowing them to do so. And I think that now it’s time for us to after our small soapbox moment to ask our audience, uh, what is their attitude towards requirements gathering?

Speaker 1: Yeah. We know our attitudes. But it’s time to find out yours.

Speaker 2: Yeah. Now you know what’s right and what’s real. Um, and we are eager to hear how do you feel about this. I think that even even Lucy, even you and I, uh, should everyone once in a while go to the, like, requirements confessional and say, I confess I didn’t do the requirements ex the assessment for this. So no shame in that.

Speaker 1: No. No. Exactly. And, uh, it’s an anonymous poll at the end of the day.

Speaker 2: Yeah. So

Speaker 1: So do we have results?

Speaker 0: Uh, we are slowly getting some results in. Let’s give people just another minute or two to

Speaker 1: Oh, to read the answers. Yeah.

Speaker 0: And then I will announce where we’re at.

Speaker 2: Yeah. Definitely. Um, once again, I mean, they’re they’re really not right or wrong answers. If you have to take something home from this session, Lucy, and I hope that you take home the fact that this is important and you should do it. If you haven’t done it in the past, this is a good moment to change that and, uh, and understand the the ripple effects, the implications of it.

Speaker 1: Yeah. And don’t tolerate it being cut out at projects. Um, it’s just so important.

Speaker 2: Yeah. Absolutely agree.

Speaker 0: Alright. So it looks like we have most of the votes we’re gonna be getting, and, thankfully, no one selected. I am not interested in wasting time on requirements gathering. So I I know that there you said there were no wrong answers, but I think we can all agree some requirements gathering should be done. Um, and we’ve got 61.8% of the votes go for I do it for any Pardot or significant Pardot changes. 20.6% is I sometimes do it when we’re not under time pressure. And 17.6% is I don’t do it currently, but I would like to start.

Speaker 2: Excellent. You are in the right session, my friends. Um, I’m happy that we can we can contribute to that. Fantastic.

Alright. So now I’ll take over for a couple of slides and talk about who should we involve. Uh, we we talk about why and what, and now who. And, um, from my in-house perspective of running a mops team, my or in my opinion, the most crucial part of solution design and solution implementation is the one that does not involve Pardot or code at all, which is stakeholder communications. You do this right, your project will move forward forward effortlessly. If you neglect this, you are going to endure endless friction and endless pain. Um, it’s handy for me to divide this in stakeholders in two groups and talk to each of them differently. The technical ones will define what your solution needs to do and where and when and for whom. And these questions and answers will give you the lines of the requirements, and these are people with whom you can probably talk talk Pardot language to. But understanding nontechnical stakeholders on the on the right-hand side of the slide will help you figure out potential pitfalls, find synergies, find opportunities for scale-up, and generally unlock more value than your solution from your solution than than the original ideators considered. And now we will yes. Please Yes. Take over, Lucy.

Speaker 1: Yeah. So, again, I know we’ve said this. This is like our catchphrase of the talk, I guess. Uh, but Pardot’s not an island. And, um, this is just some of the additional products that are that could be coming into the conversation. You know? It’s it’s not just Pardot by itself. There are so many other things to consider. Um, but your job as a consultant Pardot owner is to and make requirements on a path forward. Um, so I’ve actually lifted this formula from the Pardot consultant, um, certification outline, um, because that’s, you know, that that is how the study guide is split out. So, um, assess your Pardot Salesforce landscape, so what I showed you on the last screen. Um, that should be your starting point before you dig deeper into each part of your Salesforce. Know your business objectives. So in other words, marketing’s goals, and then you just gotta pair that to together to hit the mark. Um, much of what we’ll be covering in the following section is outlined in further detail online. We’ve included we can, uh, send around links to resources as well. Um, but, yes, first of all, give yourself course.

Speaker 2: Absolutely. And you know what they say. If if I have three hours to chop down a tree, I’ll probably spend the first two sharpening the axe. This is exactly about what this is about. When you begin to work on your project in house or as a consultant, spend time understanding the direction, where the team, where the org are going, and and how are you going to work in that direction. Here, I see that the goal is twofold. First, you need to understand the constraints under which your solution must be built. So what are the boundary conditions? Who will be the end users? How skilled are they in Pardot? Who has permissions in Pardot and in Salesforce that allow you to implement it? Um, do you need to build room to scale up later? And the other part of the goal is build that rapport with the project stakeholders. Understand what are their drivers, their hopes, their fears, and adapt your communication so that it’s easy and pleasurable for them to work with you. Even more so if you’re a consultant that they are paying by the amount of time invested. The nicer you can make the experience, the better the overall satisfaction the project will be.

Speaker 1: And future projects? So, yes, um, next is another part of your background investigation work to assess your marketing trends available tools and methods. And as a Salesforce customer slash Pardot, you have you’re fortunate to have many, um, resources at your fingertips, um, to help with that investigation. So here’s what’s at your disposal, um, in terms of reporting. Salesforce standard reports and dashboards is a great place to start. Um, don’t just look at marketing ones. Find dashboards from other teams as well. You’ll get they’re keeping a close eye on. Um, if you are a B2B Marketing Analytics customer, that that’s a good place to go. Um, it it will enable you to slice and dice the data from more ways that you wanna see it to to gather, um, what the current There are out-of-the-box dashboards as well if it that’ll enable you to get up and running fast. So you can see, um, for example, how a form or a landing page contributes to the sales pipeline and opportunity life cycle. So, um, you can actually see a couple of those down at the bottom of the slide. Fields like score grades, um, and behavior Google Analytics is especially useful if you’re not using so you can get a feel for what visitor behavior is like on the website. Observing users offers really rich insight, um, that you can’t get from a report to have them good recording that information. Automation, um, reports from that tool. And so what you’re looking for, it’s as important. It’s well, like conversions and, um, speedy, like, speedy, um, way through the lead life cycle. Um, but you are, after all, looking to make improvement. People may not realize their systems and processes are failing them. So you’ll you need to improve and not just carry carry on the status quo. And let’s move to another analogy, the onion.

Speaker 2: Yes. Um, this is it’s nice. It’s a model that I like. I mean, I think that in the end, gathering the requirements when you jump into a project is a little bit of an explorer job. You have to find clarity in the jungle of interactions between the different tools and parts of the Salesforce ecosystem, and you also have to leave behind a documentation that can be understood by whoever gets here next. And for that, I advise that you take this as an onion with three layers, and you first consider how your solution will interact with Salesforce Core, which is probably the master source of all the person, account, opportunity data you’re gonna be using, and pay attention to the sync behavior, to which system has primacy or which value, uh, overrides the other. If there are issues, address them then before you build the whole castle on top of quicksand. Um, then the middle layer, probably the part that you’re most comfortable with, not worth spending even more minutes in this, How does your solution work within Pardot? If you’re taking a certified consultant preparation notification, which I completely recommend, you’ve already learned a lot about designing solutions inside Pardot. But then, last but not least, outer layer of the onion, figure out whether your solution interacts with other non-Salesforce applications. If you’re implementing lead routing, are there any lead sources outside of the Pardot that you need to consider? Are there connectors that can alter score in a way that will break your process or wipe it? Will a webinar tool create duplicates if people raise it for non-Pardot form? Your project stakeholders are going to be fixated on the middle layer of your onion. Your solution doesn’t Pardot, that’s why they hired you a Pardot expert or consultant. It’s the most visible part, but make sure that enough attention is paid to the innermost and outermost layers of the onion because they are crucial.

Speaker 1: Thank you for sharing those examples as well. Um, I think it really helps people to relate, you know. You plant the seed of vision, which according to Jaime has grown into a jungle yourself class. And prioritization is arguably your most important job. Um, so what I mean here is first setting reality, and secondly, which order in. So, um, I’m gonna introduce something called MoSCoW. Um, some of you may, um, have heard of it before, But it’s not unusual for people to get excited, um, because you’ve shown them Pardot during the workshop, you know, laid out this whole customer journey. Um, there’s a there’s a rule of thumb, though, Pardot first Pardot after. Pardot has to slot around automations, rules, data, and so implementing Pardot should come org is relatively consistent state. Pardot’s best implemented phases, like I’ve hinted at. Um, so which resources are at disposal are in fact finite, and this the time, budget, and people. Um, so the people who expertise and advice. So be realistic, especially if one of these resources is a deal break continuing. For example, you don’t have an endless then you need to know what you can afford right now and comes available. Um, you can then re-re-prioritize. So, yeah, this is, um, MoSCoW. Um, I’ve used, multiple exercises. Um, so it stands for Must have, Should have, Could have, Might have (often referred to as Won’t Have for the bottom tier). Um, so start items that are necessary and nonnegotiable for the product to actually function, like dependencies. Um, if they’re not completed, then you can’t move forward with any other parts of the project. Um, I’m being in situations, and I’m sure others have too, where stakeholders not familiar with Pardot want to cut corners on crucial implementation. So, um, for example, not setting up email for authentication, um, which, you know, is gonna bite you back when you can’t get good deliverability. Um, so, yeah, you should dedicate time as part of the workshop when you’re wrapping up, which is a good option, um, to set some next steps at the same time. Or, you know, if you’re feeling a bit overwhelmed, take your time. You may wanna go away. Um, think of the most logical order to deliver these in. So, you know, what can what can offer, like, the the phrase two birds, one stone? What can be bundled? Um, and, also, that could also be beneficial for everybody else that attended to think about what they really want. Um, So once you have your requirements in a list that’s somewhat uniform, not too chaotic, you can, um, start placing them into these boxes. So you can use quick documents, Google Docs, Sheets, um, so everyone can visualize that.

Speaker 2: Alright. And now since we’re approaching the end of the session and we’re pushing towards the time limit, I’m gonna speed it up a little bit. But I just want to open your eyes a little bit more and tell you that since you’ve probably connected Pardot to a series of other tools, when your project or solution crosses the boundaries of Pardot, you need to consider the implications on the other parts of the stack. Life looks very easy, very simple, if you just consider what happens inside Pardot. But if you do a seemingly meaningless configuration change, you can completely wreak havoc on other connected applications. But this cuts both ways, so you need to be vigilant on this because it’s likely that nobody else is considering the impact on Pardot of other solutions. And with this, I’ll leave it to Lucy to summarize with some challenges.

Speaker 1: Yeah. And I know we’re running up on time, and quite a lot of these challenges we’ve mentioned already in the session sprinkled throughout. So I’m just gonna pick one, my favorite one, um, getting fixated on terminology. So learn to talk in your team’s language. Um, so note that be diff to the team users, so adjust accordingly. Um, you could even have a glossary to between what they’re saying and what you’re referring to, um, so that you can start to build in that that language change. Um, so, yeah, don’t worry about it. That’s a process that comes later when you train users. Um, just be adaptable and, um, aware of that. Which one’s your favorite, Jaime?

Speaker 2: I think for me favorite and least favorite are the same, which are scope creep, uh, because it’s of itself inflicted. And if you do a good job, do you deliver what’s been agreed on time and a budget, you will often be asked to squeeze a little this thing also in the solution, and this can take a toll on people. Uh, you can process things very well, but these small things are sand on the gears that that completely kind of clobbered whatever the process and requirements you’ve built.

Speaker 1: Great. And, um, I know we’re almost at time so I think it’s gonna be a q and a. Um, I’d love to hear from you. We’ll gather up your questions and consider what you’ve been asking and, you know, maybe some of those. But, yes, they’re all coming and, um, yep.

Speaker 0: Yeah. Thank you, Lucy and Jaime. That was an amazing session. Uh, we are out of time for a q and a discussion. But if you have questions for our speakers today, you can always reach out to them directly in the event chat. Uh, thank you again for joining us, and a special shout-out to our sponsors today. Without their support, we would not be able to offer Pardreamin the way we are. Make sure to pop in to your sponsor to to the sponsor booth sometime during the event and show them some love. Thank you, guys.

Speaker 2: Thank you.