Merge Your Stacks

With a clear data strategy and plan, and clarity around your anchor platforms, you should now move on to looking at the rest of your technology stack. 

In an M&A environment there is a strong possibility that you will have redundant products in every layer.  The best approach to rationalizing these is to prioritize which layers you’ll tackle first, and then work them layer by layer.

To start, eliminate any remaining Zombie products. If you are trapped due to an auto-renewal clause with no immediate cancellation possible, make sure that you highlight the next auto-renewal date to ensure that you don’t miss your next chance to cancel the subscription. Note: In our experience, we’ve found that many companies will allow you to cancel your subscription despite auto-renewal and non-cancellation clauses, so it’s worth reaching out to ask.

This is the time to revisit the requirements framework that you and your stakeholders created for your marketing technology stack and the product attributes that you collected for each product.

For each product in your stack—both acquired and internally developed— review the following information that you’ve collected:

• Which marketing function or functions from your list does this product support?
• How well is the product performing its current function? 
• How is performance trending?
• Are there any concerns or issues with the product? 
• Are there adjustments that should be made to improve performance?
• What percentage of existing product functionality is being used?
• Does this product meet data compliance requirements?
• Has this product been assessed for data security risks? 
• How well does this product integrate with the other elements of your stack?

In addition, you should now also consider: 

• How well the product aligns with your company’s data strategy
• Whether the product could perform any of the new functions that are required in the stack. In a marketing technology stack, less is always more. The more you can do with each product you have, the less complicated the stack becomes over time.
• The anticipated impact of additional product training on platform utilization.
• The relative importance of this product: A simple 1-to-3 scale will help prioritize efforts when it comes time to consider replacing, retiring, or investing in additional product training.

With all this information in hand, you are now in a position to determine for each product whether to keep it in the stack, retire it, or consider it for replacement. 

As part of this exercise, identify redundant products. Email seems to be a common category for redundant products, and while there might be a reason to have more than one email platform, you need to consider whether you really need three, four, or even five different platforms. Compare these products alongside each other, and against your functional requirements, to see if there is an opportunity to reduce the number of redundant platforms. Make sure that as you work through this exercise, you take into account both existing functional requirements as well as anticipated future requirements, to ensure that if you do reduce the number of redundant platforms, you are as farsighted as possible in your decision-making. 

The last and hardest part of this exercise is to identify and rationalize platform redundancies that exist between product categories.  It’s not unusual to have different types of platforms performing the same functions, or a platform that is being used for one function that is capable of being used for an additional set of functions.  We see functional overlap most often in Email, Marketing Automation, CRM, and Account Based Marketing (ABM). As you rationalize your stack it’s important to look at how tools are being used and what they are capable of; you may be able to save significant money by eliminating functional redundancies.

For products that you intend to keep, identify contract duplications within each company and between companies. It’s not unusual to see multiple departments using the same products with each department establishing their own contract with the vendor. There’s money to be saved in consolidating contracts! For some reason, marketing automation seems to be a category in which this issue frequently exists. We’ve seen companies unearth more than five active contracts for the exact same marketing automation platform. 

A few notes

• For products you keep that you believe might support additional functionality, reach out to your vendors and ask them to discuss their product roadmaps. As noted earlier, not only could there be plans to introduce the functionality that you need, but you might also be able to influence the direction of the roadmap in order to acquire that functionality.
• If feature utilization is poor for products that you are keeping, consider allocating time and budget to additional training.
• For products that you are planning to retire, make sure that you are tracking contract end dates and can plan accordingly.
• For products that you are considering replacing due to poor performance or general dissatisfaction, it’s important to give yourself the appropriate amount of time to find and evaluate potential replacements. 
• Finally, when reviewing internally developed technology, it’s important to understand why it was developed in the first place. If it was originally developed because there was no available off-the-shelf product, but now there is, it might be time to consider retiring your internally developed equivalent (unless, of course, you are happy with its performance and you have the resources to continue to support the product).

Note: As you work through the rationalization exercise and spend time talking with the users of various products, you are likely to identify additional functional requirements to add to your overall list of technology requirements. It’s important to keep building, refining, and revising the list as you work through this process.