MarTech East 2019 day zero: The right way to buy MarTech
What strategies are you using to build your MarTech stack?
(This blog is part of our pre-show coverage of the MarTech East 2019 conference - an event that covers best practices, strategy, security, and team-building for revenue operations teams. Keep an eye out for additional coverage and session recaps from the event.)
Read more MarTech East 2019 coverage:
It’s preshow day at MarTech East, which includes in-depth workshop sessions on a variety of MarTech-related topics. One session featuring @TonyByrne from the buy-side analyst firm Real Story Group covered best practices on how to evaluate and purchase new MarTech solutions, which we’ll recap below.
The most important factor in building a MarTech stack? Potentially, fit.
To kick off the session, Byrne asserted that “The most important concept in managing MarTech stacks is ‘fit,’ not ‘right,’” in reference to the fact that there are thousands of MarTech solutions available in the wild. It could be reasonably argued that no MarTech solution is perfect, but it’s certainly possible that some solutions will make more sense for your business and your customers than others.
While there still exist classes of MarTech applications that professionals consider to be central to operations, such as marketing automation platforms (MAP) and customer relationship management platforms (CRM), there is great innovation happening “on the peripheries” outside these formalized categories. However, consolidation among major MarTech publishers such as Oracle and Adobe has led such behemoth firms to become “very keen to sell you more apps belonging to their ‘cloud’ suite.”
This push to sell not just flagship products, but ancillary products, is a share-of-market measure that Wall Street analysts follow. Share of market may reflect favorably on a publisher’s stock share prices, but might not necessarily be favorable for operations professionals looking to build the best stack for their own unique needs.
Why MarTech stacks fail
Historically, IT projects, particularly at the enterprise level, have had an approximately 50% failure rate. Some reasons include scope creep, lack of adoption, a sequentially-ordered “waterfall”-based approach with too many time-consuming dependencies, changes of management, misalignment with a company’s strategic priorities, a lack of executive sponsorship, unrealistic expectations from a company’s senior leadership, and the dreaded “shiny new object syndrome” of purchasing more and more software because each new product seems more appealing than the last.
Other potential causes for IT project failure while building a MarTech stack include a skills gap (not having enough properly-trained operations professionals to operate the stack) or a gap on the part of the software itself and its ability to “fit” a company’s unique needs.
Arguably, some of the failure also comes from the strategy (or lack thereof) used to acquire new applications and add them to a MarTech stack. There are at least three different models for building a MarTech stack:
First, a common theme in the 2010s was focusing on functional digital marketing and engagement, building out components based on an idealized, “Big Picture” view that is functional, but lacks any customer experience (CX) component. Second is a more-recent model, the “MarTech Mall,” that partitions a stack into “anchor” systems that are mission critical, and peripheral “boutique” systems that may lend themselves to a more-experimental approach with lower investment. The third model is the customer-centric stack informed by design thinking - putting customer experience above all else.
The final model not only includes end users on the revenue operations team and IT support, but also a designated internal MarTech product manager who can add genuinely human perspective to what is often just a list of context-free features that pile up on a list for IT.
Design thinking focuses your MarTech stack around CX. Slides courtesy Real Story Group.
In fact, according to Byrne, “business use cases should always trump features...it’s best to come up with your own use cases and evaluate solutions against those use cases.” Operations organizations often face a greater risk of over-buying software rather than underbuying due to thinking too far ahead. However, the best vendors ideally innovate their own products to continually add value.
The real challenge occurs when organizations buy tech with extraordinary potential but lack the talent and knowhow to use it. As a result, instead of becoming faster, the new tech makes them slower. In other words, finding that a mid-range solution - not the most complex one on the market - is the best fit for a company is potentially cause for celebration. Adding a less-complex app to your MarTech stack means you need to take on less operational overhead than if you had gone for the most complicated app on the market.
Current MarTech trends
2019 has arguably ushered in a number of problematic trends for MarTech stacks, including increasing complexity and a push to ‘externalize’ personalization and segmentation to disjointed app suites and third-party consultants, making each initiative lose impact. The ongoing challenge originating in the 2010s of traditional MarTech stacks being too siloed for the era of omnichannel customer experience is due a number of factors, including stack components individually getting “too smart” with each having its own decision logic.
As a result, disparate stack elements got “smarter” independently, focusing on making better decisions individually rather than consolidating data into a usable repository and making a larger, holistic data picture actionable. In contrast to the contemporary recommendation of a digital experience platform (DXP) model, companies might be better served going in the opposite direction: moving key functionality and assets such as core data, content, insights, orchestration, and personalization ‘lower’ in their stack, then layering logical decision making ‘on top.’
Where to start with your MarTech stack
Byrne suggested that a customer data platform is as good a first acquisition as any, given how difficult it is to build one in-house. The next acquisitions you should make will depend on your business and the functionality you need at the center of your stack.
For instance, a consumer merchant that relies heavily on email promotions might center its stack around an email service provider (ESP), while a video-based company might build its stack around marketing webinar or campaign-based apps.
Operationally, a marketing operations team tends to be best suited to take the lead on growing and managing a MarTech stack, though depending on the business, web experience teams may also take point. CX teams can and should provide ideas and conceptual guidance, but may lack the technical experience to own a tech stack. Sales operations teams can also be critical partners, but are often siloed within their CRM. Long-term MarTech changes can take months to conceptualize, approve, and implement, and sales teams often don’t have the luxury of focusing on such long-term projects as their daily business is focused on ongoing sales deals.
Building MarTech in-house vs. buying external solutions
Byrne suggested that building applications and API integrations in-house isn’t a good idea in general, even for specific software suites that appear to be lightweight enough to support complementary development. Developing around lightweight-seeming solutions can actually incur additional business pain around factors such as permissioning and metadata.
Attempting to build applications, integrations, and even product enhancements in-house can introduce new problems. For instance, it’s common for teams to attempt to jury-rig a custom interface on top of an otherwise out-of-the-box, third-party solution. A seemingly simple set of tweaks can spiral out of control over time as projects expand in scope, often leading to teams having to consider scrapping the entire homemade interface.”When you have to rebuild the whole interface, that’s when it’s time to ask if you’re even using the right solution, long-term,” explained Byrne.
Another challenge with building functionality and integrations in-house for revenue operations teams is the unintended consequence of external teams getting excited by and heavily adopting such features. As a result, revenue teams end up with the added burden of having to provide technical support outside of their own group. Said Byrne, “at that point, you’re in the software business.”
Selecting new MarTech apps can be faster as an “Agile-ish” process.
How to select MarTech (and how NOT to select it)
There are several common paths to hastily adopting MarTech solutions that end up becoming a poor fit, such as having peers or your boss get excited by a demo without your involvement; hearing about a recommendation from a third party; coming to the end of a long and technical evaluation based on features but not any kind of practical human usage; or being forced to use an overweight, bloated solution for the sake of utilizing just one of its many features.
The MarTech selection process tends to work well with a list of about four to eight business objectives that can justify new purchases in terms of considerations such as reduced risk, gains in efficiency or productivity, enhanced value and revenue, and qualitative transformation. Any return-on-investment (ROI) analysis should consider the cost of doing business (CDB), articulate costs against the impact of doing nothing at all, and recognizing that migrations/integrations/ongoing enhancements will constitute most of your long-term total cost of ownership (TCO).
Implementing the selection process + committee
Operations teams should consider assembling a buying committee that focuses less on executive authority and more on credible, functional authority conferred by expertise. Buying committees should ideally include a business lead, a separate product manager, and a diverse set of interested stakeholders who are proxies for customers. In Byrne’s experiences, buying committees ideally consist of fewer than 12 stakeholders; it can be nearly impossible to keep a team of 15 or more people aligned.
Operations teams may want to consider taking the approach of empathizing with stakeholder problems, creating an RFP with a vendor shortlist, then ideating on proposals before proceeding to the demo and final decision.
When considering vendors, revenue teams should consider the status of vendors themselves as actual companies. Some important factors to consider include customer support, company strategy, professional services, viability and stability of a company (keeping in mind that even large, stable-seeming enterprises may make sharp turns and shut down individual products on short notice), the company’s product roadmap, the product’s technical modernity, its value for money, and its ecosystem and community.
To create RFPs that work, revenue teams may wish to avoid a “waterfall”-like process and instead consider a more “Agile-ish” process that avoids overly long & detailed requirements, gives vendors enough time to respond (4-6 weeks), avoids “wired” RFPs in which buyers already have a vendor in mind, allows vendors to ask questions in writing, and treats prospective bidders respectfully.
Takeways
Byrne recommends orienting the MarTech selection process around CX, and bypassing roadblocks by working backwards from CX-based goals. Other key steps in the process include identifying gaps, understanding that the future of revenue operations will focus heavily on media and content, extracting enterprise services from engagement silos and instead layering decision logic on top, focusing on “fit” above all else, and testing selectively.
Read more MarTech East 2019 coverage: