The 2nd Age of Martech has arrived, and it’s all about convergence in ecosystems

In 2019, I hypothesized that we were on the cusp of a Second Golden Age of Martech. The defining characteristic of this new era was a shift from dichotomies to convergences:

• From suite vs. best-of-breed to integrated platform ecosystems
• From software vs. services to blended delivery models with both
• From build vs. buy to customization on top of commercial platforms

Instead of being forced to choose between X or Y — which was never fun because you were forced to make trade-offs that were suboptimal in either direction — you increasingly had the option to get X and Y.

In fact, the two were better together.

You could have a full-featured marketing suite as your core platform, but it now had open APIs and a marketplace of specialist (best-in-breed) apps with off-the-shelf integrations. Your software vendors now enthusiastically provided expert services to help you get the most out of their products, while your service providers increasingly incorporated custom or commercial software in their delivery. You could easily build custom business logic and bespoke customer experiences on top of commercially-available platforms, enabling digital differentiation — but without requiring you to reinvent the wheel, the cart, or the harness for the horses.

Through increasing convergences in the cloud, the 2nd Age of Martech is turning silos of software and services into a more integrated stack of capabilities:

While there were early examples of this, which I cited in my 2019 article, the evidence here in 2022 is that this shift from dichotomies to convergences is now fully mainstream.

Suite vs. Best-of-Breed Platform Ecosystems

Last month, I pointed out a Pandium study of the State of Integrations and APIs at 400 SaaS Companies identifying that 86% of the Top 100 SaaS companies in the market now feature an integration marketplace. Instead of pretending to ignore any software that wasn’t their own, these companies are proudly celebrating the breadth and depth of their integrations with these other apps.

Integrations have become a first-class competitive dimension.

In a world of 100,000+ B2B SaaS products, how could they not be?

For startups and specialist apps, integrating with the leading platforms in their category has become a must-have, not nice-to-have, requirement in order to win customers. The latest MarTech Replacement Survey 2022 showed that integration capabilities/open APIs were the #1 important factor in choosing a replacement martech app.

Integration consistently shows up as one of the top criteria for apps and platforms in almost any martech-related study now. For instance, just last month, a study from Ascend2 on the State of Multichannel Marketing identified integration/unified marketing technology as the #2 most essential element for success:

It’s clearly been a trend in martech stacks in The Stackies over the past several years that marketing tech & ops teams both (a) incorporate products from multiple vendors in their architecture and (b) have them connected together into a more cohesive whole. Indeed, Philips has explicitly labeled their own martech stack as an “ecosystem.”

Software vs. Services Blended Delivery Models

There was a time when it was considered almost taboo in investment circles for a software company to also provide services. In theory, the economic model for software — build once for a fixed cost, sell many times for a negligible variable cost — was diametrically different than the classic services model, where revenue was linearly tied to hours billed. This is why software companies got much higher multiples on revenue (10X) in their valuations than services businesses (2X). Blending services into a software business was kinda seen as cheating.

But when you think about it, the seeds of convergence were planted the moment we started selling software-as-a-service (SaaS). While the cost-of-goods-sold (COGS) was still very different for running software in the cloud (e.g., your DXP) vs. having humans do manual service labor (e.g., building a website on top of your DXP), the relationship with the customer started to get blurry.

Paying WordPress.com to host a site and paying Fiverr to have someone build pages on that site for you increasingly looked similar in the buyer’s experience. Both are largely self-service purchases expensed on a corporate credit card.

Consider Apple’s much ballyhooed push into services as an example of this blending.

But what really drove a shift in SaaS services thinking was customer success. With all the rapid digital innovation over the past decade — Exhibit A: the massive martech landscape — the technology has rapidly outpaced most companies’ capacity to develop the matching organizational capital (i.e., skillsets, processes, know-how) necessary to extract full value from it.

This is the essence of Martec’s Law.

And it was a major source of churn for SaaS vendors. When customers couldn’t figure out how to leverage their sophisticated software enough to justify the subscription costs, they canceled them. And that was a major drag on the theoretically non-linear economics of SaaS.

So SaaS vendors started investing more in “customer success” — which essentially amounted to services to help customers unlock the value of their products. They offered richer onboarding services. They offered training and education services (for two great examples at scale in martech, consider HubSpot Academy and Salesforce Trailhead). Many offered more tailored consulting services (see HubSpot and Salesforce examples again).

This blended model has generally worked quite well and spread throughout the industry. It delivers the “changes accelerated via external service providers” boost to organizational change in Martec’s Law, as pictured above, to a SaaS vendor’s customers.

Of course, SaaS customers can also buy this boost from other “services” companies: agencies, managed service providers (MSPs), systems integrators, management consultants, etc. In fact, the majority of tech-related services are provided by these independent companies who are part of a SaaS vendor’s broader ecosystem.

(See how these things connect?)

But just as software companies have gotten into services, services companies have gotten into software. Accenture, Bain, Deloitte, and McKinsey all have software products in their portfolios. Among the big agency holding companies, WPP owns Choreograph, Publicis owns Epsilon, Omnicom owns Annalect, IPG owns Acxiom, and Dentsu owns Merkle.

It’s not just giant services firms doing this either. For instance, in the HubSpot partner ecosystem, a number of our leading Solutions Partners that provide services now also have built packaged products for our App Marketplace: Aptitude 8 (A8 Labs is their product group), Lynton (SyncSmart is their product group), Bayard Bradford (Datawarehouse.io is their product group), Media Junction (BoldStack is their product group), Impulse Creative built Cohortium and CompanyOS, and more.

In an article I wrote about HubSpot’s App Accelerator program, I described many of the benefits that drive services providers to build and promote products:

• Identify recurring patterns in hourly client work that can be automated by software
• Deploy solutions to clients more quickly, more affordably, and/or more profitably
• Expand from one-to-one client engagements into one-to-many exchanges of value
• Smooth ups-and-downs of a contract-based work schedule with software revenue
• Retain clients as software customers after services-based projects are completed
• Offer software, possibly in a free/freemium model, to attract and acquire new clients
• Leverage acquisition channels, such as app marketplaces, not available for services
• Deepen their reputation as technical experts in their area of specialization
• Differentiate from competitors by offering an exclusive product that no one else can
• Develop intellectual capital (IP) beyond their services-based organizational capital

This is a win-win for both services companies and their clients, as it raises the bar on the solutions and outcomes that they can efficiently deliver.

Build vs. Buy Customizing on Commercial Platforms

In a study last year by LXA (formerly known as the Martech Alliance), the classic suite vs. best-of-breed question got turned on its head as the majority of companies participating said their customer/marketing data platform had been either custom-built in-house (16%) or was a hybrid of custom software and commercial platforms (38.5%).

That “hybrid” option has overtaken the false dichotomy of build vs. buy in martech.

Companies want the best of both worlds. They want to tailor their workflow and customer experiences to craft the unique digital contours of their business. But they don’t want to re-invent the wheel. Their greatest constraint is developer talent. Anything they can purchase on the open market to accelerate internal development and keep their engineers focused on the “cool stuff” that is unique to their business is a win.

Today, very few software development projects start from scratch. They leverage hundreds of sophisticated services from the major cloud infrastructure providers — AWS, Microsoft Azure, Google Cloud, etc. — and a plethora of services from API-first companies, such as Twilio, Stripe, Auth0 (now Okta), Mindee, Mux, etc.

Most developers now stand on the shoulders of giants standing on giants in the cloud:

As with commercial packaged martech apps, the most important thing to marketing and business leaders is that anything custom they build also integrate with the rest of their systems.

There are several ways to achieve that:

1. Allocate precious developer time to custom build integrations.
2. Use API services that already integrate to commercial app platforms.
3. Connect to aggregation platforms that facilitate sharing with other apps.
4. Build customizations natively on top of your commercial app platforms.

The first is the least attractive (see: scarcity of developer talent).

The second is an easy option, where applicable, as many of these API services include integration with relevant platforms. For example, the video API service Mux can directly route videos into headless CMS platforms such as Contentful, Sanity, Cosmic, and Strapi. (Got to love the names of headless CMSes.)

The third is an increasingly common pattern with the shift towards aggregation theory applied to platforms inside a company’s tech stack. Push your custom app’s data into an aggregating data warehouse such as Snowflake and let it inherently become accessible to every other app that connects to that warehouse — and everything downstream from those. Or expose an API in your custom app that will let enterprise automation platforms such as Workato connect and incorporate it into any configurable workflow business users want with every other app Workato is connected with.

As an important aside, note that with both the second and third options, those vendors — the API service providers and tech stack aggregation platforms — become participants in the platform ecosystems of the commercial platforms that they integrate with out-of-the-box.

The fourth approach, building customizations natively on a major app platform, such as HubSpot or Salesforce, has been common practice for a while. But the scenarios in which this is done have expanded significantly over the years as these app platform companies have improved their tooling for building and managing such customizations.

There are pros and cons to this approach. The upside is that it tends to be the fastest and easiest route for customizations that are operating in the context of that app platform — e.g., tailoring the data and services shown on a user’s CRM screen. They’re inherently integrated. The flip side is that because the customization is specifically within the context that platform, it may not be as portable if you decide to switch to a different platform in the future. For a lot of business logic, which tends to be fluid anyway, it’s often worth it.

But the real exponential growth with custom apps on commercial platforms is the result of the low-code/no-code (LCNC) movement.

Most of the major app platforms in martech now include some degree of low-code/no-code functionality, enabling authorized business users — or, more often, their trusted marketing ops teams — to build customizations without needing hardcore software engineering talent.

In conjunction with a wave of specialized no-code platforms, from (A)irtable to (Z)apier — see my post last year on Marketing Superpowers: How AI & No Code Transform Every Marketer into a Maker for a ton of examples — the number of custom “apps” built on these commercial platforms has grown tremendously over the past few years.

I put “apps” in quotation marks because many of these customizations are lightweight pages and forms, simple workflows, or glorified spreadsheets. But they get the job done for many jobs-to-be-done — without the overhead of traditional software engineering that was associated with choosing build in the build vs. buy dichotomy of the 1st Age of Martech.

Convergence > Consolidation in Martech

This 2nd Age of Martech is bringing significant improvements to marketing technology and operations on all three of these dimensions — commercial software, professional services, and custom software.

While massive consolidation in the martech landscape has not yet materialized — and given current software dynamics in the cloud, it seems unlikely to shrink to a handful of vendors in this decade — we are seeing convergence in this 2nd Age of Martech. The industry is converging around platform ecosystems, where the lines between services and software and between custom and commercial are blurring into the cloud.

This convergence is much more transformative than consolidation ever could be.

Disclosure: In case you didn’t already know, I’m the VP of Platform Ecosystem at HubSpot, which is why HubSpot examples pop easily into my head. I’m also an advisor to Workato. However, none of the patterns that I’ve described above are unique to either of those companies.