The Real Story on MarTech: Is platforms vs. products replacing suites vs. best of breed?
Thinking of solutions as sitting on a spectrum between platforms and products will help clarify your business and operations models.
This distinction remains important, but seems less germane with each passing year, especially as enterprise stack leaders increasingly recognize they cannot effectively go all-in with the likes of Adobe, Microsoft, Oracle, or Salesforce, and still obtain the fit and coverage their stakeholders require. Major suite vendor solutions remain important, but only situationally, which means that best-of-breed offerings increasingly win out in expanding stacks, even when purchased from a larger vendor with multiple offerings.
Instead, there’s a newer, more subtle, yet potentially crucial distinction to make when building your marketing stack. Call it “platform vs. product.” Platforms are rich, extensible, and generally more expensive toolsets often favored by developers and systems integration firms. Products promise a more “out of the box” environment with less IT overhead, and therefore often appeal to businesspeople who want to quickly solve a problem or seize an opportunity. It turns out your stack needs both products and platforms…but which kind, and where?
Platforms vs. products
You might assume this is a David vs. Goliath conversation, and in small part it is. But platforms vs. products is about much more than size. In the marketing tech space, more product-like solutions tend to scratch a specific itch — say, social listening — rather than a broader undertaking, like omnichannel journey orchestration. Yet I believe a more crucial dimension revolves around complexity: your organization’s appetite for richer capabilities, your team’s ability to master and exploit a more heavyweight solution, and the simplicity of your business objectives in any given domain.
To that extent, this model parallels Real Story Groups’s tongue-in-cheek “Martech Mall” approach to stack analysis. The “anchors” in your mall are more likely to require platform-like solutions, while for the intermediary “boutiques” more productized solutions might suffice.
Nevertheless, it’s important to recognize there is a spectrum here. Not everything is Nordstroms versus the mobile phone kiosk. Some solutions fall more toward the middle, though in that case, a savvy enterprise stack leader will ask whether that offering isn’t the worst of both worlds, rather than the best.
What vendors say
Most big (and some small) marketing tech vendors tout their platform capabilities — base frameworks that customers, integrators, or the vendors themselves can customize and extend to meet a wide variety of potential use cases enterprises might need to address. Most (though not all) open source projects lean in the platform direction. Most (though not all) SaaS offerings are more product-like. Multitenancy usually favors uniformity and tight focus.
Of course, when confronted with this spectrum. Vendors will argue their offering can serve as both platform and product. This is generally not true. The “quick-start” packages that platform-oriented solutions promote will typically lose their luster after three months, when the real developer lifting begins.
Meanwhile, module-based extensibility models touted by product-oriented vendors can cause as many problems as they solve, especially when it comes to upgrades and microservices-based integration models.
How you should respond
Considering technology in a platform vs. product spectrum should help you clarify your thinking on business and operational models, as well as the underlying criticality of any solution.
For starters, establish whether your business case calls for shorter-term ROI versus long-term flexibility. Products typically offer the former at the expense of the latter. Platforms offer the latter — but only if you resource them fully.
Take a hard look at your internal capabilities and program-level maturity. If you can boast comparatively advanced internal resources and experience, you could obtain a real competitive advantage by going with a platform rather than a product. If you’re running lean or need to pivot quickly, then admit that you can’t address the complexity that comes with exploiting all that extra power and consider more productized solutions.
Then, when selecting vendors, have that difficult internal conversation about present needs versus future flexibility earlier in the process, or you’ll be fighting it out later via vendor proxies. When evaluating platform vendors, be wary of case studies, which typically conceal how much development work and fragile custom code went into the implementation. When evaluating product vendors, press for more decoupled services. Do you really need yet another email marketing subsystem in that nifty customer success management platform you’re looking to license?
Sometimes it’s useful to sense-check your assumptions through an empirical, agile-based selection process. When Real Story Group is assisting enterprise marketing tech selection teams, we’ll often suggest a product-oriented solution to supplement an otherwise more platform-oriented vendor short list, and vice versa. A product-oriented outlier might teach you that could succeed with a simpler solution. That’s a big win in a world short of marketing tech talent! Considering a platform-oriented solution amid otherwise more productized offerings will help you understand functional ceilings and opportunity costs in your decision-making.
In the end, where a particular vendor offering sits on the platform-product continuum will play significant role in how well any offering fits your short- and long-term needs. There’s no solid right or wrong here; consider multiple opinions, and let me know if our team can help you.
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.
Opinions expressed in this article are those of the guest author and not necessarily MarTech. Staff authors are listed here.