Pardot Solution Architects – Who are they, what do they do?

June 30, 2021
Pardot Careers, Salesforce Ben | The Drip

The Pardot Solution Architect role could be considered the pinnacle of the Pardot consulting career path. If you have experience delivering Pardot projects (for enterprise-level clients) and don’t want to become a CMO/go into management, then this career move could be for you. Achieve seniority, in other words, promotion within a technical discipline rather than a management discipline.

Although the “Solution Architect” (SA) role has been around in the Salesforce ecosystem for some time, it has been receiving more attention over the past year since the certification and ‘learning expeditions’ were released. This has made the Salesforce Solution Architect’s roles, responsibilities, and required skill sets, more formalized.

MarTech/marketing automation career paths are not as well-defined as compared to industries/specialisations that have existed for longer. Holly pointed this out in a previous article (with her 12+ years experience, she would be considered an industry veteran).

Cue this question, posted on LinkedIn by Sara McNamara:

What do you think of when you think “Solution Architect” in the scope of marketing operations/technology?

Whether you think Pardot warrants a Solution Architect, or not, there are people working in this role.

What does a Pardot Solution Architect do and how do you become one? To answer these questions, I had a conversation with Ben LaMothe, a Pardot Solution Architect at BDO Digital, Marketing Champion and an active Salesforce community member who hosts Pardot career panels regularly. What a great fit for demystifying who Pardot SAs are and what makes them tick – enjoy!

What does a Pardot Solution Architect do?

A Pardot Solution Architect is someone who is very fluent in the core Salesforce platform and who is also able to leverage other platforms that live outside of both Pardot and Salesforce. These other platforms are required to expand the functionality of Pardot and to meet the increasingly technical client requirements for reporting, routing, and a number of other things.

A Solutions Architect is the person who is able to develop the technical documentation to achieve that goal and further to then either implement, or assist with the implementation.

Where do you work? Client-side, or consultancy/agency?

I’m on the agency side. I work for a company called BDO Digital (in the US), which is a division of a larger company called BDO, one of the larger professional services consulting firms globally.

So you’re seeing into a lot of different Pardot/Salesforce accounts, working on that basis?

Having the larger parent organization behind us definitely enables me to gain access to many interesting companies that have various needs that involve Pardot.

Why are Pardot Solution Architects required? Why is your role required?

Pardot is becoming more enterprise-focused, Salesforce is trying to push Pardot upmarket (targeting larger SMB and enterprise customers); this is what I’ve heard from people who work at Salesforce/Pardot and that I have myself observed. Three scenarios unfold:

1. Expanding tech stacks, large data volumes

When you start targeting enterprises with a marketing automation tool, requirements get more complex because there are more tools that are involved in the implementation. Not only are these tech stacks larger, but all the tools also need to be able to ‘talk’ to each other. Pardot becomes much more than just the tool for email, it has to be able to access data from other places through the API, through webhooks, etc., to process and leverage prospect data and Salesforce lead/contact data in other ways.

You see the upmarket desire with the release of the new Pardot Premium license, a fully enterprise product (the license cost, if nothing else, says it all, as it’s several times more expensive than the Advanced edition). This comes with the analytics tool, B2B MA Plus, which uses AI to give projections for what to expect, based on previous trends.

So, the Solution Architect role is becoming more prevalent as more enterprise-level organizations become Pardot customers.

2. Organizations that need both Pardot and Marketing Cloud

A Pardot Solutions Architect needs to be familiar with Marketing Cloud, or at least have some level of familiarity, in addition to Sales Cloud.

This will enable them to develop technical requirements and documentation, push data between those two systems (i.e., it starts here and goes there, but if this happens, it pushes back into this database and so on).

Understanding both the Pardot-Salesforce connector and Marketing Cloud Connect is important as the ways that they integrate with Sales Cloud are different (Marketing Cloud Connect is more complex than the Pardot one).

3. To nip ‘technical debt’ in the bud

Lucy interlude:

Ben mentioned that he’s heard opinions about Pardot SAs from people who don’t believe that Pardot could warrant an SA because it’s not a complex tool. My thoughts are that Pardot’s simplicity is deceptive because additional customization is required to achieve various business use cases outside what I refer to as the ‘cookie cutter’ business model that Pardot fits into perfectly. However, the ask to customize, when in the wrong hands, leads to over-customizing, followed by technical debt. That’s where the SA should have nipped it in the bud.

The Pardot Solutions Architect role will grow

I’m seeing more Salesforce consulting partners look for SAs. I expect the demand to grow over the next couple of years.

With every subsequent release of Pardot, there will be new enhancements that, I would consider, outside of the standard functionality of Pardot (closer Sales Cloud, the analytics tools, etc.).

That’s where a Solutions Architect comes in, to see the bigger picture and have a level of comfort with more than just Pardot, putting together the tactical documentation that illustrates the wider requirements of all the systems, the pushing and the pulling of data, and how to build those things.

There are two other trends at play here:

1. The revamped Pardot API

The Pardot API is getting more robust. A significant proportion of the requirements to access different systems outside of Salesforce will involve the Pardot API. The Pardot API is for scenarios where the data you need to use doesn’t live in Salesforce (and never will) and/or you need to get data into Pardot where it’s not going through Sales Cloud.

As I said, the Pardot API is getting more robust and is definitely a skill to learn (something that I’m still learning to at least become conversant in the API). Pardot API is something that an SA should be overseeing.

2. Einstein Analytics/Tableau CRM

When you start working for enterprise organizations (going ‘upmarket’), you will have reporting requirements that go beyond what Sales Cloud reports can achieve.

B2BMA is great but it’s largely out of the box, i.e., the dashboards are meant to work as-is.

I’ve had clients who say: “this is great, but I want to be able to filter this and that”, in a way that is not out-of-the-box functionality.

As an SA, you need to build that functionality, do the data manipulation and build the Pardot datasets in order to produce these reports in Tableau CRM (i.e., the platform that B2BMA is built on).

That’s the tactical side, not necessarily requirements gathering. You need to grasp the platform to be able to write documentation (i.e., telling clients “here’s what needs to happen for this to work”). You need that level of familiarity to write documentation confidently and coherently.

Pardot Solution Architect vs. Consultant

The level of familiarity that will enable you to write documentation confidently and coherently for products that go beyond Pardot is a differentiating point between a Pardot consultant and a Pardot SA.

1. Familiarity with Einstein beyond B2BMA for reporting

A Pardot consultant has a baseline familiarity with Einstein and B2BMA, which will take their specs (whatever the requirements are) and build that in Pardot. This means they’re not really thinking about what’s happening in other systems. They may have another resource in their organization to help them bring the data they need into Pardot from other systems.

The SA is at a higher level, from a systems capability perspective, with the ability to see the entire requirement and then write the documentation to fulfill the entire solution.

2. Pre-sales involvement

Often the SA, when working for a consultancy/agency, will be also involved in the pre-sales process. When your sales team has a prospect, they’re going to look to their SA to listen to the requirements and ‘have a voice’ (i.e., be convincing in what you’re talking about). Being comfortable in a pre-sales role is part of becoming an SA.

Lucy’s interlude:

As you can tell, Ben is very enthusiastic about Pardot and knows so much about the platform; as a result, he can really talk about what the future vision could be for his clients. I see an SA as having to upsell but not overpromise; validate so they’re not overpromising what the project can deliver.

Ben:

It’s about knowing which questions to ask, hearing the client’s responses, and being able to offer realistic solutions, saying: “yes, we’ve done this before. I have experience with this and I’m comfortable being able to deliver on this”.

An SA will write statements of work (SOWs), which will include the level of effort for the proposed project. Therefore, an SA needs to be comfortable enough with the platform to know roughly how long requirements would take to deliver. That’s a departure from a consultant, as they’re the ones that actually implement. Having done it before means they will know what the quote should look like, based on their extensive past experience.

3. Be the escalation point

As an SA, you’re the main person for the client (other than the account manager).

Something that I’ve learned the hard way and is advice I pass on to newer consultants, is that consultants will sometimes not get treated well. They’ll bear the brunt of their clients’ temperament that day.

An SA is meant to be the ‘cool head’ in the room when clients get upset if they feel something isn’t going right. You are the expert in the room who can bring the temperature down, the escalation point that’s going to diffuse angst. That’s at least my take on it.

I tend to come in light, but deliberate, objective, and calm in my delivery; if you meet the client where they are, at their level of irritation, then that’s not going to diffuse the irritation.

There was a call with a client where one consultant said something that upset the client because they felt it was the opposite of what they had been told. I wasn’t even on the initial call, but I got brought in to help ‘set the record straight’.

4. Voicing limitations as a product expert

As the SA, you’re the product expert. I don’t see myself as a salesperson for Salesforce or Pardot. I’m the person who knows the platform, so I am as honest as possible with my clients: “yes, this is the product. This is an area that needs improvements. This is something that is not as good as [insert other marketing automation platforms]”, or “yes, I wish that this was possible, but it’s not, here’s a solution that could get two-thirds of the way there”.

5. Future-looking product authority

If the client asks about some future functionality, I’ll say “FYI, I’m plugged into the Pardot ecosystem/product and this is something I’m expecting Pardot may address in the next 12 months”. Demonstrating that connectedness to the core Salesforce product and product teams is what an SA should relay.

That’s not always the case but I like to instill a level of confidence that you’re talking to an expert and someone who is familiar with the platform and acquainted with the teams that are working to enhance the product.

A day in the life of a Pardot Solution Architect

Lucy’s interlude:

As Ben and I had been talking high-level/with intangible concepts that might be quite hard for people to relate to, I asked Ben to take us through a day in the life, what he may get up to.

While I do have the title “Pardot Solution Architect”, I still do things that are typical for a Pardot consultant, for example, Pardot implementations.

As I mentioned, being comfortable in a pre-sales role is part of becoming an SA. I would say that over the course of a week, 25% of my time is involved in pre-sales and the sales process – some weeks that could be more.

The first hour of my day could very much be pre-sales. For example, tomorrow I have a meeting that’s been put into my calendar for a prospect meeting. I’ll tell them about who I am, plus I take notes and collaborate with the sales team to put together a proposal/SOW (statement of work), following the call.

Over the course of a week, the other 75% of my time will be spent building and writing documentation and attending to other client obligations. I could be implementing a lead routing system and Engagement Studio, then have another client where I’m writing documentation for a lead management system. Or I often review documentation that a consultant gave me and send my feedback. Sometimes things come up where clients will have questions here and there.

And you’re also thinking: “what could the next statement of work include for this client?” – Being the expert in the room who is very familiar with their system and very familiar with their processes, what’s the next thing that I should recommend to them?

How many other Pardot Solution Architects do you know?

There are probably 8 to 10 people I know well, who I would consider SAs. They may not have the job title “Pardot Solution Architect” but based on their skills, familiarity with the platform, and rapport, I would consider them architects.

Lucy:

The reason I asked is that I wondered if you were mentored by anyone? Was there someone that you saw had these responsibilities and you modeled your role after them? Or, did you just naturally slide into this role?

I’m just in awe of people in the Pardashians Slack group, people who write blogs, and others who just know so much about Pardot. You think: “that’s something that I wouldn’t have thought to do”, which leads me to think: “maybe I’m not as good as I thought because there are people out there who are very good”. That’s humbling but it’s also inspirational. With the mindset of an SA, you should be seeing these people and not be intimidated by them, but be inspired instead.

What steps are you taking to improve as a Solution Architect?

SAs will always come across tools they need to grow into because a) technology moves so fast and b) the larger enterprises they work with have the budget for huge tech stacks. You need to have a heightened level of familiarity with the technology that’s out there; even if you don’t ever use it, you’d benefit from being conversational in it. I’ll throw out one example: Snowflake. This is something I haven’t used that I hear people talk about a lot, used by the large enterprises and as Pardot goes further ‘upmarket’, it’s likely I’m going to run into it.

I’m currently working to get better at Sales Cloud because my familiarity up until now has been within the realm of Pardot: leads, contacts, accounts, opportunities, campaigns, but not the other sales functions. It’s foreign to me because it’s something I’ve never implemented. On my to-do list is to become more familiar with Process Builder and Flows, an area where I’d like to be able to hear a requirement and know how to build it.

As a Pardot Consultant/Solutions Architect, you need to be strong in Sales Cloud because with every release, Pardot and Sales Cloud get pushed closer together and at a certain point Pardot will be considered an extension of Sales Cloud.

Final Thoughts

I was grateful to speak with Ben about his experiences growing into this role. All this learning in an industry that’s moving fast is overwhelming. Being able to stay on top of new technology is key and in addition, synthesize anything new with your past learnings/experience – two things that I believe are why the Solution Architect role is so well-regarded.

I want to leave you all with this – let’s not “pigeon-hole” Pardot Solution Architects, or confuse the job market. What I mean by this is job titles can be easily misinterpreted by the wider industry, for example, a senior Pardot consultant can’t be automatically promoted to a Solution Architect as the step-up requires more than simply more of the same consulting experience.
Solution Architects work “cross-cloud” (across multiple Salesforce platform products), which was the founding principle of the Salesforce Architect Success Program; the title “Pardot Solution Architect” should never be solely a Pardot-focused role.

Inspired to become a Pardot SA?

If you are inspired by what Ben shared about his career path, keep an eye out for the upcoming Pardot career panel he will be hosting (details will be shared by Ben and myself when the event registration goes live).

In the meantime, if you have any further questions, please drop them into the comments section below.