Why and How We Audit Our MarTech Stack
[et_pb_section fb_built="1" _builder_version="4.16" global_colors_info="{}" theme_builder_area="post_content"][et_pb_row _builder_version="4.16" background_size="initial" background_position="top_left" background_repeat="repeat" global_colors_info="{}" theme_builder_area="post_content"][et_pb_column type="4_4" _builder_version="4.16" custom_padding="|||" global_colors_info="{}" custom_padding__hover="|||" theme_builder_area="post_content"][et_pb_text _builder_version="4.16" background_size="initial" background_position="top_left" background_repeat="repeat" global_colors_info="{}" theme_builder_area="post_content"]
What’s Revenue Got To Do (Got To Do) With It?
By DeAnn Poe | Vice President, Demand Generation | DiscoverOrg
As marketers for a marketing technology company, my team and I know how important it is to get the marketing technology stack right. That’s why we audit our martech stack every quarter to make sure every piece is contributing to revenue. Here’s why and how we do it.
Listen to the full podcast below:
Saying Yes While Staying Focused
As a marketer, it's easy to bring on new technology. There are so many new marketing tools out there; it seems as though there's a new one being presented every day. They all promise that they're going to be the "end all, be all" to solve your marketing woes.
Our marketing team, like many others, have said "yes, sign me up" to many of these tools - which is why it’s smart (and necessary!) to periodically look at the tools within our marketing tech stack and evaluate the tangible value they bring to the organization. Specifically, how they are contributing to our ability to drive revenue.
Our Evaluation Framework: Current Tools
Using a framework from SiriusDecisions, we start by inventorying all of the tools that we currently use and noting:
- What we use them for
- Which team within the marketing organization leverages them
- The cost associated with them
- The quantifiable value that each tool brings to either our workflow, campaign performance, or the measurement of those campaigns
Then, we categorize our technologies into four buckets:
- Tools to be evaluated for removal or replacement that don’t seem to be bringing any value at all.
- Tools that we are not leveraging to their fullest, but that do have the potential for upgrading functionality, integrating better with existing tools, or consolidating. These are next in line for removal and often where a majority of our discussions are centered.
- Tools that have potential but have not been widely adopted. These have the right features and functions but require additional training, improved support, or increased understanding of the available functionality.
- Tools that we need to extend our usage of, potentially by including a broader group of users within our company. These are tools that are delivering a lot of value and we are leveraging well.
We've had a number of tools that we've ended up removing from our tech stack, and either replacing or just removing, because we weren't seeing their value from the investment that we put in. For other tools, we have doubled down, extended our investment, and looked to leverage new functionality along with proper training with our team.
Our Evaluation Framework: New Tools
We use the same framework when we're evaluating new technologies to add to our tech stack.
- Do we already have an existing tool that meets the need or requirement? If so, how is that tool performing?
- Does the current tool fall into the category where we think that we're not seeing the value from it? If so, then we can potentially replace it.
- Does the new tool fill a need that we haven't addressed yet in our tech stack?
- Does the functionality we need exist within the new tool today?
- Is the new tool easy enough to adopt in our workflow that we will realize the value as quickly as possible?
Finding and Resolving Technical Overlap
The first time we did an assessment, we found that we had a lot of tools that overlapped with the functionality of another. Two different teams might be leveraging those two different tools to do the same thing.
Our operations team is in charge of our marketing tech stack, providing an objective perspective to evaluate tools based on cost, value, and adoption, and then to determine the best solution for the whole organization.
When someone is protecting a tool because they’re used to it, we discuss what we would not be able to do if we took the tool away. The answer to that question should be focused on lead generation, pipeline generation, and revenue generation.
Those kinds of conversations tie a revenue element to tools that people might think of as just making jobs easier or making people more efficient. We want to see how the removal of something from our tech stack would ultimately impact the bottom line.
What Our Martech Audits Reveal
The themes of data hygiene and deliverability come up a lot in our audits. Deliverability is becoming a lot like SEO, where one day you think you have it mastered, and the next day you find out the whole world has changed and what you thought you knew yesterday is no longer true. Tools that allow us to keep our databases accurate and clean, and with valid data, always come up for us - as they help combat deliverability challenges. Even more specifically, we are always looking for deduplication tools. We've yet to find the Holy Grail of deduplication solutions.
We're also always looking to dig into campaign performance and marketing contribution. I would like to see what we can do more and better, as well as what we should start and stop doing.
Keeping A Clear Head In An Explosive Environment
The martech space is expanding rapidly. In May 2017, Scott Brinker’s Chief Marketing Technologist Blog reported that “the landscape grew again this year, by about 40%, to a total of 5,381 solutions (from 4,891 unique companies).”
That kind of growth makes our stack audits crucial to our success as marketers. We need reminders to stay grounded to the revenue reality that these technologies are meant to serve - and to not fall victim to shiny-object syndrome.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]