We’ve all heard the saying, “No one gets fired for choosing IBM.” But in consulting various organizations on their MarTech stack investments over the past five years, I don’t hear IBM as the gold standard. Instead, I hear, “We’re a Salesforce shop. Salesforce acquired Pardot, so it must have better integration and be the better long-term solution.” After helping dozens of clients with vendor selection, from marketing automation (MA) through customer data platform (CDP) to learning management tools (LMS), here’s one thing I know for sure: if you’re deciding which technology to invest in based solely on safety, then with all due respect, you shouldn’t be making this decision.
Heavy is the head that wears the technology decision crown. These decisions will impact the organization for years and the effort we put toward these decisions should align to that impact.
The Definitively Awesome Approach to Vendor Selection
In the past 12 months, I’ve assessed 75 CDPs, 30 messaging platforms (Chat/SMS) and 25 LMSs. Here is how I approach it.
NOTE: I’m sharing this for free with everyone, because all of these things are readily available to all buyers, but make no mistake: This. Is. Hard. Work. The payoff is that when you go to your boss, or your boss goes to their boss, or someone a few levels above you goes to the CEO, they don’t get laughed out of the room. They don’t get told, “That’s a nice opinion, but we already have a partnership with Microsoft.” If you follow this path, you will have the definitive proof for your recommendation.
Step 1: Gather ALL Options (ie – Do your homework)
Go to all the review sites that categorize software, including TrustRadius, G2, Software Advice, and get full lists of products – Crunchbase is a great source as well. It’s a simple, yet essential, first step.
Optional Step 1b for Enterprises
If you’re a company with revenue over $500MM or are approaching it with double digit YOY growth, eliminate non-enterprise ready solutions. Sorry 10-person Silicon Valley start-up, but you can’t handle Comcast right now. Remove the tiny players. Trust me, the risk is never worth the reward.
Step 2: Create Base Requirements and Select Top 10
After step 1, you probably have a laundry list of options. Don’t get overwhelmed! Narrow this field by creating base requirements. This is NOT yet into the nitty gritty; that’s step 3.
The best way to explain my definition of base is through examples.
- Must be cloud hosted
- Must serve our industry
- Must meet a revenue threshold
- Must have over 100 clients
- Must not have XYZ capability via an acquisition
Create 3-7 quickly-identifiable requirements. Immediately remove any system that fails these base requirements.
Ultimately, you’re looking to go into deep requirement exploration on between 5-10 systems. This saves you eons of time researching detailed requirements for systems that are never going to win.
Step 3: Flush Out ALL Requirements
Is “detail-oriented” on your resume? This is your chance to prove it!
It’s time to get specific with your requirements. Don’t get cute with it! Be as practical as you can. It’s okay if it’s not in technical jargon, but make it super plain and to the point. For example, platform security requirements are typically easy to collect and easy to evaluate.
As you start this process, you will quickly find that you’ll need a rubric. Big spreadsheets aren’t sexy, but they’re effective. Most MarTech requirements I see end up having between 8-12 categories with 5-30 requirements per category. A good example of how that ends up looking is here in Cassie Coke’s excellent and detailed breakdown of a Marketing Automation Platform rubric.
Step 4: Avoid the Website. Go to Product Docs
You remember the note when I said none of this stuff is rocket science, but it is time-consuming and therefore slightly hard. Get ready to read. Once you have your top 10 and all your requirements, it’s time to get into product documentation. Don’t rely on a product sales rep to tell you the truth about the integration you need most. Go to the documents and read about it.
What is product documentation? It is not the website or anything marketing has put a spin on. In most cases, you’ll only find it in end-user or developer documentation. Here’s an example from Marketo. Say you were interested in their real-time personalization tools (now known at web personalization), this is what you’d see on their website:
This actually gives you more detail than a lot of SaaS websites I’ve been on. Take the first piece here, “Target lead- and account-based audiences.” Okay, this is obviously really important. Say you have a use case that you need to personalize the website experience of your customers by industry and you have those industries specified in a unique field in your CRM.
If you go into the product documentation here, you’ll get clues about how you’d actually use the tool. Take a look at this screenshot:
Here you’re seeing the available industries to choose from. If you need an Aerospace industry selection, how will that happen? Is this customizable? Details like that make a big difference and you’ll never uncover them unless you dig in and educate yourself.
If you Google specific features of the technology, you can typically get deeper product documentation. Here’s another page I found still on the first page when Googling Marketo RTP. This, too, gives you so many intricate details that far surpass the shiny, refined nature of the marketing and sales assets.
If you take away anything from this post, remember this: NEVER start with a demo. Signing up for a demo is one of the last steps. Not the first.
Beyond the technical nature of these documents, also reflect on the following:
- Can you tell how invested they are in enhancing that product? When was the last new release related to it?
- Does it look like the rest of the platform? If you look at RTP, it doesn’t. Because it was part of an acquisition. With that, you can assume at least some heartache in how well it integrates with the rest of the product.
Step 5: Go to Support or Community Forum for Real User Questions
I suggested going to TrustRadius to get a list of the products to include in your evaluation, but I don’t recommend spending any considerable time reading through the reviews on there. Most folks run campaigns to get their best, happiest users to these sites. And for the most part, only customers who are EXTREMELY happy or extremely pissed end up doing it. So, instead, use user forums to get the real tea on what people are asking or struggling with.
Step 6: Finally, Do the Demo!
Once you’ve narrowed the field down to 2 or 3 solutions, you’re ready for a demo. Prior to the demo provide the platform team with use cases you want to cover, be as practical as you can and don’t let them present a cookie cutter sales presentation. You need to see it actually working. Be direct and don’t waste your time. Doing your work ahead of time will enable you to be direct. Tell them you need it to do x then y and here are the things that really matter.
You can also use your research to ensure no one lies to you. If you hear an answer in conflict to what you saw on the community forum, send them the link and get clarity. Yes, I am a salesperson’s worst nightmare. But that is why I am also a CEO’s best friend.
Do the demo and get to a solution engineer as soon as you can – they can answer the really big questions. If you’re chasing being the best, then you want the best fit for what you’re trying to accomplish.
Alternative Step 6: Go RFP
If you’re a big enough company, you can skip the sales rep rigamarole by doing an RFP. With your laundry list of requirements, softwares will be forced to show up and show you how they’ll accomplish your use cases.
Step 7: Get a Proof of Concept
If you’re researching a newer technology, or the documentation just doesn’t exist, you can ask for a proof of concept. Again, depending on the size of your organization and the size of your vendors, this may not be possible, but nothing sells a solution like seeing it for your use case in real-time.
So to summarize….
- Visit sites like G2 and Crunchbase to pull all options
- If you’re an Enterprise – look for proven enterprise ready solution
- Create basic requirements
- Detail requirements for your use case
- Don’t go to the website. Start with product documentation
- Look at the support or community questions being asked
- Do the demo, but throw 90% of what sales reps say out the window and get to an engineer
- If you’re an Enterprise – go RFP
- Try to get a proof of concept if there are any doubts
I hear your thoughts. Yes, this takes a long time. Just remember that your decision will impact your organization for years. If you want to be safe, then buy the suite your CTO has a relationship with. Being safe and protected feels great, but people don’t get promoted for being safe. People get promoted for being innovative, driving something forward and making an impact in the organization. Innovation requires really understanding your requirements and what you’re trying to do. You did the proper evaluation. You really understood the success metrics because you defined them. And you were willing to put aside brand affiliation and think about what is the best possible solution. That seems a bit better than buying IBM to me.