How to Think About Your Marketing Tech Stack

At the 2019 Adobe-Marketo Summit, I had the pleasure of presenting thoughts on Martech Stack management with Kelly Horton of Docker. We presented several methods to help fellow marketing operations teams think about how the MOPs function works in the organization. We also discussed in detail how to manage the Marketing Technology Stack (MarTech stack) within the organization in a way to deliver business value and take the burden off of marketers.

Solving Shiny Object Syndrome

The reality is you will never completely stop this. Other teams will do what they want thanks to the power of the corporate credit card and cheap SaaS tools that solve one single problem. In particular, event teams seem to love trying tools because they can never quite get their perfect solution for smaller events. With 7,040 or more MarTech tools, there are a lot of point solutions.

Shiny object syndrome is rampant across many teams of course. I also tend to see this syndrome occur with particular use cases at least twice a year. Standardizing the Department and the Company on a single tool reduces overhead (training, contracts, data flows, etc.) as well as ensures a single admin can develop use cases faster. Here are the top three Shiny Objects to watch out for:

• Event management tools from scanner apps to registration systems.
• Schedule Meetings and Meeting Calendar tools. Sales can easily buy 12 of these without realizing the other 14 sales teams around the world already have 4 other tools.
• Project management or Workflow management tools. Unless you’re a massive firm with a Project Management Office (PMO), you can easily end up with 4 or more just within a large Marketing team.

Ultimately, you have to know your organization’s place in the company as well as the stack. To reduce the impact of rogue apps that aren’t playing nicely, there are three easy steps to take:

1. Map out your current stack
2. Find solutions, vendors
3. Manage the stack: follow a process

Step 1: How to Map Your MarTech Stack

There are dozens of ways to map the MarTech stack to display it to different audiences. Scott Brinker’s Stackies provide a lot of idea fodder. You may also want to go through a Migration Exercise or a Marketing-Sales Process review at least once a year to capture new requirements and understand organizational evolution before it outpaces your technologies.

Kelly Jo Horton provided this option, which is a solid, digestible systems diagram.

You can use tools like Giphy, MS Visio, or Lucidchart to build these maps. I don’t recommend PowerPoint because it’s process charting tools are a bit limited.

For larger exercises, you may have to go full systems architecture. Here are a few ideas from a quick search:

I personally prefer something along the lines of Kelly’s map as an overview for new staff and higher-level discussions with IT.

The next step is to use Swim Lanes and a Marketing-Sales Funnel process to map both actions and systems to understand the full funnel process. Ask questions like:

• Who owns which systems?
• What action is expected at each step in the life of a Lead or Account?
• Which system takes an action if a Salesperson creates an Opportunity?
• What should a salesperson do at this point?
• Should marketing do something at this other point?
• If a Lead or Account doesn’t proceed to Stage 5, should those people go to a Nurture?

Thus, you will have several MarTech stack maps:

• Systems Level Map showing the connections between databases, tools, vendors, etc.
• Funnel Lifecycle Map showing the Stages and Handoffs between teams
• Funnel-Systems Map showing how each system manages parts of the Lead Lifecycle
• Workflow-Systems Map showing how each team works at each part of the Funnel.

You will find all four helpful in managing the stack. Each one has a different role to play in internal discussions.

Type of Map	What to Put in It	When to Use it
Systems Level Map	– Databases Tools – Connections between systems	– IT – Vendor management – Data transfers – How to move data around – Identify gaps
Funnel Lifecycle Map	– Sales-Marketing process – Funnel stages	– Sales-marketing process and handoff discussions – Updating processes – Identifying requirements from teams
Funnel-Systems Map	– Sales-Marketing process – Funnel stages Attribution	– Vendor management – Building funnel attribution models – Change management – Modifying key areas in the funnel or a CRM/MAP change
Workflow-Systems	– Marketing to sales workflows – Internal project management – Sales-marketing process – Use cases	– New vendor discussions – Changing a vendor – Designing a process – Modifying a process – Understanding what a team needs or wants

Once you have one or more of these guides, you can use them to walk people through various situations. Each can become a great training tool. I will walk new staff through one or more of the documents depending on their need. Then they can see what we have done and why we are there before making assumptions. We can then have a conversation about what they may see as a gap in the process or an area to automate, rather than focusing on a vendor.

Another tip – make new MOPs and SOPs staff members create one of these on their own. Most firms let these process charts go stale very quickly. As part of your process, a new staff member should update it. The benefits include:

• New person meets all the key people they need to know.
• New person sees a new way to display information.
• New person understands the systems faster.
• New person can make recommendations and take on ownership of useful projects that are “their idea.”
• You now have an updated map.

Step 2: Finding Solutions, Not Vendors

Time and again, it seems marketers (or salespeople) get sold by MarTech sales vendors. Since most MarTech firms these days are point solutions, this is an interesting phenomenon to explore. Usually the conversation is something like:

Vendor Salesperson: “Hey, you want to increase MQLs (pipeline, opportunities, etc.), right?”

Marketer: “Yes, I do!”

Vendor Salesperson: “Great, we built this AI chat tool that increases MQLs 150%* so you should install it on your website, and it takes 15 minutes.”

Marketer: “Oh that’s great, just what I need, can you give me a demo?”

Vendor Salesperson: Let me hand you to our qualification Team…

New Vendor Salesperson: “Sure!” [shows demo of product, neglecting to discuss the excruciating details MOPs would want to discuss.]

Marketer: “Ok, how much and where do I sign?”

Marketer: “Hey, [website/MOPs/tech person], I bought this tool for a year that’s $15,000, please put this on our site today so we can get more MQLs!”

MOPs: “What is this tool? How do I turn this on? How does it generate MQLs exactly?”

Marketer: “Just do it and stop questioning me. It’s already signed.”

MOPs:  🤨 🙄

We’ve all been there. Maybe we’ve even done the reverse and had to sell a new tool to Sales or a Marketing team because the requirements changed, or the team changed while we were busy negotiating.

A Solution Based Approach to Marketing Technology Management

The Business Case or Use Case:

First, are you solving a real problem? Some refer to this as a Business Case. A good salesperson will use solution-based selling and questioning to help you build an internal case. Most of the time we skip all this and assume it will “work.”

In our all too common conversation with a MarTech salesperson, we use poor business case statements.

• Install AI Chat thing – it’s great!
• We need Vendor X because…
• We need vendor Y because I don’t want to use spreadsheets…
• We need an automated prospecting email tool.
• Connect LinkedIn Ads for me.
• Upload these leads I got from some place.
• Build a nurture program for me.

We all do this, it’s okay to admit it and do better next time.

Instead of saying, “I need vendor X, because I used them at my last firm,” or “Vendor Y does automated prospecting for sales,” we need to speak in Use cases.

When you, as the MOPs leader, start asking questions about the vendor, the marketer becomes defensive or simply tells you they’ve already signed. This is not the best decision for the business.

If you are doing your job well, or perhaps your vendor’s salesperson is a true pro and helps you build a business case first, here’s what to do.

Instead, we should have a Business Case – are you solving a real problem? If you’ve come from the Product Management world, you may recognize these techniques.

Establish a Business Case Process

This is where being a bureaucrat is a good thing. Why? It helps funnel nervous energy and excitement about things into a process where we collectively understand a problem, devise a solution, and actively make it happen. Only a process can stop arbitrary decisions and frankenstacks.

You can use this process as a one person MOPs shop or with 50 people; it’s about the process, not the number of people.

• Stakeholder Focus Groups

This is the fancy term for a series of meetings. Have a meeting where you ask the requestor to walk you through their needs.

Whiteboard everything.

Ask open ended questions and withhold any judgement or vendors you like.

• What would your ideal process look like?
  • What would you want to have happen next?
  • Why do you think this tool will help?
  • Tell me more about…
  • Help me understand the problem you are having today.
  • In six months, what would your workday be like?

The steps can be in one meeting or several:

• Bring together the USERS who will tell you use cases (and reality of daily use)
  • Bring together their managers who will tell you their goals
  • Bring the executives so you can align on budget and strategy

I can tell you from experience that a fast way to fail is to ignore executives in this process. One time, I negotiated a great deal, closed all the use cases, and thought I was pretty clever. When I went to get what I thought was final approval, I discovered I didn’t know our procurement process that well, and that I had four other executives to go through. Let’s just say that deal is not yet signed.

• User Stories and Use Cases

User stories and use cases are product management techniques to help developers build features that solve a user’s problems.

The common method, often used in Agile, is:

As a [Persona], I want to [do something] for [this reason].

You can also call these “use cases” to prompt people into explaining what they are doing or want to do.
For example, an Event Marketer might say,

“I want to setup 1:1 meetings at the tradeshow.”

If you ask good questions, you can articulate the solution more clearly:

“We find 1:1 meetings between high level prospects and our executives (or salespeople) are very effective at advancing the sale. Many of these prospects will be at the show and it’s the only time to get their attention. My team needs a way to

1. send an email to a prospect,
2. have them click on a link,
3. choose an open time on our Calendar.
4. Then, that open slot will be filled for the Meeting Room and then the Account Executive for that Company.
5. Calendar invitations will be sent to everyone involved automatically.
6. We also need an easy or automated way to mark down if a person showed up for their meeting.

Once you know that, you can easily generate a process chart with more details like Fields, Databases, and potential systems that would make that process work in real life.

• Five Whys

Taking a cue from Six Sigma, asking “Why” five times is another method to get at the core of what someone really wants.

With Five Whys, you can go from a baseless assertion to real business reasons to take action.

Example:

            Why did we forecast all our leads to come from SEM?

            Why is the forecast wrong?

            Why was SEM weighted to 100%?

            Why was the process not checking for obvious mistakes?

            Why was the attribution model approved by an intern?

• Solution Based ROI Statements

A combination of methods is to work toward an ROI statement. What would an “AI Chatbot” actually do for us if we installed it? Is the juice worth the squeeze?

Always ask, “If we spent $X and 500 hours building this, what would we save or gain?”

• AI Chat will free up 2 hours per day for 20 reps to work on SQLs and generate more qualified MQLs by 20%
• Scale events to enable additional registrants without manual work.
• Nurturing our opted in pre-MQLs takes about 120 days for a 3% conversion, but 90% of those go to SQL.
• User Stories: As a marketer, I want to know how many registrants I have for Event Z with one glance, not go to 3 places that takes my team 3 hours a day.

• Are you able to demonstrate scale, time, or money savings?
  • Would this process or tool allow you to build a Campaign in 30 minutes with perfect HTML across devices instead of 20 hours?
  • Or does it just shift work to a different team or person?
  • Automate away boring, tedious jobs such as
    • Data Enrichment
    • Data Normalization
    • Transferring Data
    • Transforming Data (calculations, remapping)
    • Recording Data
    • Sifting Data (from basic logic to fuzzy to “artificial intelligence”)
• Does your firm have clear ROI thresholds? Should you?
  • For example, you want to automate a process that takes 2.5 hours/week.
  • The replacement tool that pulled the same data in one place cost $10,000/year or $833.33/mo. If the hourly rate for human time is $2.99 then $2.99 x $2.50 = $7.45 per week * 52 weeks = $387/yr. Therefore, there is no dollar reason to purchase the tool.
  • If your hourly rate is $15.00 then $31,200/year in man-hours > $10,000 for automation. Thus, buy the tool and allocate people time to better things.

User Stories and the 5 Whys are great ways to dive into what a marketer is actually trying to do. I also like walking through an ideal scenario as a process to help envision what a Solution would do and how we might build it.

What does a Business Case Look Like?

Once you have gone through the exercises above, you will be able to create a one-page document, or a couple of slides to summarize the Problem, Solution Options, ROI, and Recommendations to an executive.

Problem Statement: our chat tool on the website means we need to have 24/7 coverage, but our sales team can only be on from 7am EST to 4pm EST, which means we lose several business hours in Europe and West Coast. Our calculations show that each hour we receive 10 chats, 5 of which become MQLs, and 2 go on to Opportunities within the month, with at least 1 sale that has an ASP of $5,000.

Solution 1:

So, if we could stay open 24/7 (168 hours) instead of 9 hours x 5 days (45 hours), we could get the following:

• 123 more hours
• 1230 chats
• 615 more MQLs
• 246 opportunities
• 123 closed sales * $5000 = $615,000 expected revenue per month.

And I’m not even calculating per week and cohort analysis here. The chat tool itself costs $15,000 a year at this volume and it will take about one month to install and train the AI to collect MQLs properly.

With that much money, we could even hire one or two more people to cover more hours to assist the AI and close faster.

The ideal scenario is then to request a 3-month proof of concept to see if such a lift really occurs (or what the lift may really look like).

Now, that’s a business case. There could be other options as well. Executives love to have two options, so they feel like they had input and “guided” you and “added value.”

Success of Every Tool is Your Responsibility

As a MOPs (or SOPs) leader, any tool you agree to install is ultimately your responsibility whether it was your decision or not. Ideally, the Business Case process reduces risk to the firm by clearly identifying the Who, What, Why, and How of solving the requestor’s problem. Then you will understand how to install the tool for maximum benefit.

Why do MarTech Failures Happen?

While this could be a long post on its own, there are a few clear ways vendor failure occurs.

Failures are likely to occur when:

• Business Process wasn’t defined first, so the implementation becomes messy and the vendor is blamed.
• No buy in from users or executives so no one feels they have to use it.
• Overpromised and underdelivered in time period.
• Onboarding and training met too much resistance and people “blamed” the vendor instead.
• No one to use or manage the tool.
• Vendor was decided without discussing why the vendor would help (see Executive Playbook).
• Vendor Name becomes synonymous with the Process it helps to manage. Once people decide they hate the process and the process means “Vendor X” that Vendor will be cut loose eventually, even if the tool could have been modified to meet peoples’ needs.

Success occurs when:

• Business process before RFP
• Ensure vendor is fully vetted.
• Ensure migration plan is very detailed and you have the integration documentation. Drop any vendor who can’t show this to you before the contract.
• Consider professional services to temporarily help.
• Vendor Name Does Not Equal Process

Step 3: Managing the RFP: Salespeople, Negotiation, and Procurement

In the example above, we saw how a fictional, but likely sales conversation goes with a MarTech vendor. In order to mitigate fast and poor decisions, your process included an internal component to understand the Use Cases and the ROI Business Case.

Now that you understand what you want, it’s time to go out into the marketplace to see who does what and how they talk about it. I’ve written about this before in the Marketing Automation Vendor RFP Process. Here’s a quick summary of an RFP-Feature Table.

What we want	Feature	Vendor 1	Vendor 2
Save time on meeting setup	Show rep’s calendar to the Lead	x	✔︎
Click to Schedule	Link to Rep’s calendar	✔︎	x
Show calendar in an email	Show calendar in an email	✔︎	✔︎
Low cost per Lead	Per lead pricing	$50/meeting	$500/mo. no limit
Take people out of online chat	AI chat script	x	✔︎
Route to correct sales rep	Connect to SFDC Take down info to send to rep	✔︎	x
Knows Lead Reps	SFDC API or Package	✔︎	✔︎
Push data to Marketo for deduping	REST API	✔︎	✔︎

Work the Process to Make Better Decisions

Remember to establish a process and work with Finance and Legal to understand the procurement process at your organization. It’s all too easy to bypass the rules and end up crashing into another team’s process that you must follow.

Being a Bureaucrat is easy! Here are some examples. Your organization likely has fewer or more steps. Smaller firms may condense these steps or let you make more decisions, especially for those monthly single point SaaS solutions that take credit cards.

1. Have the Business Case
2. Understand the ROI
3. Get Executive Approval
4. Vet vendors
5. Sell the vendor to the people who matter, including executives.
6. Set aside budget.
7. Requirements vs. Reality of Vendors
8. Plan the Migration with Stakeholders
9. Negotiate the Terms with the Vendor
10. Executive Approval
11. Purchase Order
12. Privacy and other Legal Review
13. Security and IT Approval
14. Renegotiate Terms as needed
15. Business Term Review
16. Legal and Privacy Approval
17. Contract Approval
18. Sales Order or SOW Approval
19. Start working!

How to Negotiate with a Vendor

Again, hundreds of books on negotiation are available. The key tips with software vendors boil down to these.

All negotiation experts will tell you that unless you understand your own positions (your Business Case and limits) you will find it hard to make your best decision. Remember, you can always walk away if you discover the internal situation has changed.

Both vendors and marketers should read this article about Working with MarTech Vendors.

Step 4: Managing the MarTech Stack Lifecycle: Add, Subtract, Expand

There are three things you can do with a MarTech stack (or revenue stack):

• Add – buy a new tool to automate or enhance capabilities.
• Subtract – remove unused tools, or tools that will be replaced, or tools that are no longer needed.
• Expand – leverage an existing tool more through use of new features.

The devil, of course, is in the details. How do you decide to Add, Subtract, or Expand within the MarTech stack? The methods I discussed above are how you make better decisions about your stack.

There is another consideration: the lifecycle stage of your organization and its ability to use the tools in the workflow. You can read more about these issues in the MarTech Maturity Model.

For example, if you want full funnel visibility with Channel-Offer attribution so you can see which assets are working and in which places, don’t expect that on day one. Even if a magic system spit out the data, does anyone know what to do with it?

The same goes for a lead gating system like Predictive Scoring. Marketing may think it’s great that they are using “science” to make better decisions, yet Sales goes by their gut; they don’t trust this new filter and think it will ruin their pipeline.

In other words, don’t put the cart before the horse.

Scott Brinker discusses the idea that a MarTech Stack, or even areas of it, are akin to building a product. As we saw above, the techniques used to make better decisions about Processes and the Tools to support them are essentially software product tools. I’m not sure I always think about it in the moment, however, it is a helpful guide when you consider that your goal is to enable another team to do their job better with a set of tools.

Adding to the Stack

Adding is usually the easiest and most fun part of managing your stack. Follow the steps above and find the best fit for your team. A few more things to consider:

• Future Proof – will this work for a year or grow with us?
• Integration Points
• How it really works.
• Can we do a Proof of Concept or would it be too much work?
• Adoption Plan: what’s your roll out plan? Are you sure regular users are going to be ready or will they sabotage this? Adoption is your best defense against Resistors and Executive Playbooks. Adoption helps the vendor lock you in too – and this is why your vendor needs to support your efforts.

Subtracting from the Stack

There are three questions to ask before Subtracting or Switching vendors:

1. Why does this tool exist?
2. Who uses it?
3. What is its value?

You would be surprised how often no one knows who owns a tool. It’s just “been there forever” and now you have to trace the connections and data to see how vital (or not) it is to automation or a particular person. See the slides below for more details on the steps.

• Does this tool duplicate features of another vendor?
• People who ran it left?
• Does it connect to something?
• What might break if we turn it off?
• What’s the contract say about shut off?
• Do we understand how to remove it?
• Did we speak with everyone who might be remotely affected and get their approval?
• Did we back up any data or do we have a rollback plan
• Did we discuss the shut off with the vendor? Did they have alternatives?

In the extreme case, you may not have any idea who owns it or what it does. The person who bought it moved on and there isn’t a clear data flow or dependency. In that case, biting the bullet and turning it off may be the only way to find out. Best case: nothing happens and you save some money. Worst case: you pulled out the wrong Jenga block and kicked off a random process that now clogged the sync or overwrote 1 million records. Be careful!

Upgrading or Switching Vendors

Ultimately, you will outgrow a vendor at some point. Perhaps they stopped keeping up with competitors. Perhaps they are best used at a 200-person firm and not a 10,000-person firm with larger data needs. Just like letting someone go, it’s a good idea to keep your vendor’s salesperson in the loop and give them a chance to discuss your new requirements.

I’ve written and spoken about how several marketing automation platforms are great for startups or certain situations and to recognize when your firm is ready for a Marketo or other MAP. I’ve seen a few companies buy too much MAP, waste money, and then downgrade for awhile.

Sometimes that $50/mo. tool that’s “good enough” and gets used a few times a month, but that no one loves is the right tool to stick with. The alternative power solution may cost $2,000/mo. and take months to install and takes a highly trained person to run. Are you sure it’s worth “upgrading”?

Another consideration is how will this change the organization? Are you sure this change is to support organizational growth or change? Or is this going to cause change that will make it harder to roll out?

As we saw with the rise of Marketo and Eloqua, vendors can persuade us that our processes should change to get with the times and accelerate revenue. Always be sure this change is in line with executives and other teams. The rise of MAPs was a catalyst for B2B marketers to become more disciplined and up level their departments, but it wasn’t always a smooth transition.

Building a Martech Stack to Make Your Marketing Sing from Josh Hill