Some common mistakes made when evaluating and choosing solutions and how to avoid them.
Buying marketing technology can be stressful. The impact of your choice will reverberate across your enterprise, and switching costs can become prohibitive. Yet, it can seem hard to know in advance whether you’re picking the right solution.
There’s a bad news/good news story here. After more than two decades of advising technology buyers at Real Story Group, we’ve seen many enterprises fall victim to critical pitfalls, but on the other hand, those tend to be predictable — and therefore preventable. Here are my top five technology selection pitfalls, along with some advice for avoiding them.
Pitfall #1: Creating a one-dimensional selection team
The traditional divide between IT and marketing silos — or IT and business teams more generally — is frequently lampooned by cartoonists and otherwise much joked about.
You might recognize the phenomenon: Marketing has the budget and picks a tool without adequately consulting IT, or IT is given sole responsibility for finding the right vendor and doesn’t adequately involve marketing stakeholders, or the marketing team simply declines to participate.
In my experience, the best technology selection teams are interdepartmental. Depending on the size of your organization and the type of technology you’re procurement, that team could include:
- Marketing product owner/manager
- Project manager
- Business analyst
- Data analyst
- Developer/integration engineers
- Enterprise & solution architects
- Systems/security specialist
- Content strategist
- Sourcing/procurement specialist
- Other functional reps as needed: e.g., legal/compliance, sales, customer care, and so forth
Sometimes the marketing-IT divide gets overplayed. Just as frequently the real problem is that a single business unit is tasked with selecting a system for the entire enterprise, and presumes that their choice will flex for all. “If it works for us, it should work for everyone else.”
This can stem from a rational desire to apply existing investments in a particular solution more broadly across the enterprise. However, if different business units did not participate in vendor selection in the first place, the chances of the solution natively meeting their needs drops precipitously.
The key word there is natively. With ample time and money you can abuse software to get it to do many things it was never intended to do. But it will be painful for all concerned. Better to involve representative business units from the start if you wish to scale a pilot project enterprise-wide.
Pitfall #2: Being beholden to spreadsheets
Spreadsheets can be useful tools for product selection — as long as you employ them judiciously. Over-reliance on long rows of feature lists can lead you down the wrong path. This typically happens in two places: RFPs and vendor scoring.
In RFPs, it is tempting to try to challenge vendors with long lists of desired features and attributes. Here’s a secret: Vendors have seen all your requirements before, and I assure you that they have very attractive answers.
One of your rows might say, “Offers a REST API.” Nearly every vendor will check the box. They don’t dare not. For all they know, RESTful API support could be the one key requirement that will nix them before they can even meet you. What this process might not tell you is that their REST API was retrofitted into the platform and doesn’t expose some key services. So keep your Excel checklists to the bare essentials (such as preferred IaaS environment). And then if you want to see how vendors really differ, don’t ask, “do you?“ but rather, “how do you?” In my experience, vendors tend to differ more on how than what.
The other reason to keep checklist items to a bare minimum is that you want to focus on a more agile, design-thinking approach, which centers on human-centered, testable scenarios.
Many selection teams also use spreadsheets for decision-making: To measure and filter finalists by applying weights to criteria, scoring how bidders perform, then adding up the math. Some government procurements require this type of approach. However, you should try to be more flexible.
For one thing, selection team members will emerge from the competition with favorites, and they frequently reverse-engineer the equations before entering scores to give their preferred vendor a high total. This seems sneaky, but it also signals a need to uncover and discuss why members possess “gut” instincts about particular vendors.
The other problem with this approach is that some stakeholders’ judgements matter more than others, or matter more situationally. Marketers should evaluate usability; architects should evaluate stack alignment; and so on. In my experience, contrasting vendors becomes an exercise in trade-offs, and mathematical approaches ususually get in the way.
To be sure, you still want a structured evaluation process, but rely more on qualitative factors when humans are involved, and make sure to take a 360 view of the solution and the vendor.
Pitfall #3: Failing to test the proposed solutions
Buying software without trying it out is frequently compared unfavorably to purchasing automobiles. “Would you buy a car without test-driving it first?”
Indeed, technology selection teams often assume they have to make a decision based on written proposals and inevitably thin, generic demos. The fear of making a bad choice with incomplete information creates tremendous stress. Buyers become suspicious, and it sets up a conflictual process from the beginning. (As Master Yoda counsels, “Fear leads to anger. Anger leads to hate. Hate leads to suffering.” You shouldn’t have to suffer…) If you are going to make a major marketing technology investment, it behooves you to test at least two finalists against important usage scenarios for a limited amount of time, before committing to a solution.
At its best, this bake-off phase becomes a cooperative search for understanding how a particular tool fits your environment. At its worst, it will uncover the difficulty of working with outside suppliers under the press of a week-long sprint. In other words, it will resemble a real implementation, after which you can sign a contract with much greater knowledge and confidence.
Pitfall #4: Focusing too much attention on the platform — and not enough on the vendor
Testing platforms is important, but typically your relationship with the winning vendor will have just as much influence on your long-term success. It is hard to quantify effective relationships, so here again a spreadsheet will fail you. Just remember that your relationship with the software sales team will drift away just as sure as rose petals in autumn, while your relationship with the vendor’s services and support staff will endure year-round. Make judgments accordingly.
All companies have personalities. Software companies (and open-source projects) have strong personalities. One vendor might excel at core software engineering while the other focuses on customer-driven feature development. One vendor promotes a large and active consulting arm; another works primarily through local systems integrators. (Recognizing the increasing importance of corporate “fit” over features, we have spent more time on plumbing vendor tendencies in RSG vendor evaluations.) There is no ideal model — the best vendor is the one that works best for you.
That said, I’ll urge you to pay special attention to the customer and developer community around any platform. It’s the best predictor of longevity, even as vendor investment can wax and wane.
Pitfall #5: Defaulting to an incumbent
In a world of expanding marketing technology, I hope you can achieve some measure of simplicity in your stack. But you should not pursue vendor or platform consolidation for its own sake. Of course your incumbent vendor will suggest otherwise, and claim that the solution you already bought could fill your gaps (possibly true), or that a different product they sell is going be better integrated (usually untrue).
You may find benefits from obtaining, say, a CDP from your existing Web CMS vendor, but more likely you’ll lose business value in the equation. Diversified martech suite vendors that cobbled together multiple platforms through acquisition typically don’t have the technical coherence to back their appealing marketing stories. In many cases, they’re actually higher risk.
So sure, include your incumbent vendor on a long list for any new platform that they happen to provide, but make them prove out in the same, test-based selection process that I’ve outlined earlier in this piece. Above all, make sure that you maintain a composable stack for a flexible, customer-centric feature.
Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps enterprises make better marketing technology stack and platform selection decisions.
The post Real Story on MarTech: Avoid these five vendor selection pitfalls appeared first on MarTech.
MarTechAbout The Author
Tony Byrne is founder of Real Story Group, a technology analyst firm. RSG evaluates martech and CX technologies to assist enterprise tech stack owners. To maintain its strict independence, RSG only works with enterprise technology buyers and never advises vendors.
(31)
