At last count, there are over 11,000 products on the martech landscape. And while it’s been a tough couple of years for many SaaS companies, forcing industry consolidation through acquisitions or shutdowns, the number of new martech startups that keep entering the field remains remarkably robust.

Are these people nuts? Hold that thought. We’ll come back to it.

However, while the martech landscape is massive by the total count of companies on it, the scale of those companies varies dramatically. If we draw a graph of martech companies by their scale — measured by revenue and/or install base — it would be a quintessential “long tail” distribution, like the illustration above.

There are a small number of very large companies at the head of the tail, such as Adobe, HubSpot (disclosure: where I work), Oracle, and Salesforce. Think public companies with a market cap greater than $20 billion. Then there are a couple hundred category and vertical market leaders in the torso. When a company has crossed $200 million in annual revenue and is considered a top brand in their space, they’re in the torso.

And then there’s the long tail.

There are more than 10,000 “long tail” martech products in the market globally. Yet it’s probably the least understood segment of the landscape. It’s insanely noisy and risky, with relatively meager revenue per product on average. So why do people launch long tail martech ventures? Why do investors fund them? And why do marketers buy from them?

To answer that question, we need to recognize that the long tail of martech is not one homogenous sea of delusional dreamers. There are many different kinds of long tail martech products, with different aspirations and raisons d’etre. The impetus for their creation individually may be more rational than you might think looking at the market in aggregate.

I’d categorize eight different kinds of martech companies in the long tail:

1. Horizontal software (disruptor) startups — early stage, but big ambitions.
2. Horizontal software (fast follower) startups — also early stage, chasing disruptors.
3. Vertical software companies — specialize in a specific industry (small or large).
4. Regional software — grow up embedded in a specific region and its culture.
5. Functional specialist software — narrow focus, aim to do one thing really well.
6. Ecosystem software — create a best-in-class extension around a larger platform.
7. Services software — augment services offered for scale/efficiency/differentiation.
8. Hobby horse — not (initially) intended as a scalable business.

Those first couple horizontal software ventures start out in the long tail. But their ambitions are to build large companies in the torso or the head. Unfortunately, this is hard to do. Most will not succeed at breaking out of the long tail and will either be acquired, go defunct, or limp along in a zombie state off into the sunset.

When people complain that “all these martech companies do the same thing”, horizontal software companies who fail to break out of the long tail are often the examples that come to mind.

But here’s the thing: some of these horizontal software ventures will become the break-out success stories in the head or torso. All of the leaders in the industry today started out that way. The big horizontal category winners emerge from the competitive jostling among many contending disruptors and fast-followers.

It’s a risky pursuit for those companies and their investors. But the potential reward can be commensurate with the risk — hence why these businesses attract a lot of venture capital.

But much of the rest of the martech long tail has a different dynamic. Vertical, regional, functional specialist, and ecosystem software products have less potential scale than horizontal ventures. But once they start to get traction, they tend to have a greater probability of success — albeit within a more limited total addressable market (TAM).

There are a lot more of these companies, but they each have their own “space.” You’re not typically going to evaluate them unless you’re in that particular vertical, region, functional specialization, or platform ecosystem. So they don’t add to choice overload as much as their sheer number would suggest.

Being in the long tail is not a bad thing for these companies or their customers. They may not be multi-billion dollar businesses, but they can be very profitable multi-million dollar businesses that are the best in their space and loved by their customers. And a few of them will evolve, typically by acquiring or being acquired, into larger head/torso businesses over time.

Software products offered by services companies also tend to be a bit different. They don’t necessarily have to be viable on their own. They’re often entangled with the services the firm offers. These products are sometimes used to acquire new clients as a (potentially loss leader) front-door. But they’re more often used to deliver differentiated or more efficient services — or to maintain a longer relationship with clients beyond more time-bounded projects.

Finally, there are the hobby horses.

This is my name for all the experiments, passion projects, side hustles that thousands of developers spin up every year. We’re seeing a ton of them around generative AI right now. Most are so small or so short-lived as to never even make it on to the martech landscape. But some do gain enough momentum to be visible. And the best of them may transition into “real” long tail businesses.

What’s unique about hobby horses is that they don’t need to become profitable businesses to be considered a success. The creators behind them can “win” by using these projects to learn new skills and technologies. They may build their personal brand. They may contribute to larger open-source movements in their space. Ultimately, it may help them get a great job and advance their careers. And in a very antifragile, evolutionary way, their micro-contributions help advance the industry.

These are the long, long, loooooong tail.

You probably won’t have to consider them in your selection set for evaluating serious new capabilities for your martech stack. But you might play with a couple of them in a purely experimental, low-stakes way to also learn and grow.

Martech’s long tail is challenging and complex. But it’s also beautiful in its own way too. So much raw innovation and invention. I hope by recognizing some of the differences between the types of participants in the long tail, you might see a bit of that beauty too.

By the way, these dynamics aren’t unique to martech. The same pattern appears in other SaaS categories too — engineering, finance, HR, IT, security, sales, etc. The software reviews site G2 recently published their Q4 2023 State of Software where they reported having ~125,000 B2B software products listed on their marketplace:

Almost all of these are long tail products too. Will this trend continue? Level out? Reverse itself? The morphing of software in the Age of AI has just begun, so it’s hard to predict. But I suspect we haven’t hit the ceiling yet.

The post Products in the “long tail” of martech have a wide range of different strategies and aspirations appeared first on Chief Marketing Technologist.

Was it John Lennon who wrote, “Imagine there’s no martech, I wonder if you can?”

I may be misremembering that lyric. But it’s what came to mind when I saw the above chart. It’s from a new Gartner report, 4 Actions to Improve Martech ROI, and it reveals a pretty dramatic shift in ownership of martech responsibilities from marketing to IT.

“Configuration and deployment of new marketing technology” saw a 10-point shift from Marketing Leads With Guidance From IT to IT Owns the Entire Activity.

Similar but less dramatic shifts are shown for acquisition of martech budget, creation of the martech roadmap, evaluation and purchasing of martech, and — perhaps most naturally — integration of disparate marketing technologies and databases.

Particularly surprising was a 15-point drop from marketing entirely owning “Driving adoption and utilization to support customer journeys.” Although the key words there are probably adoption and utilization — effectively tech enablement — more so than their context in customer journeys.

There was also a remarkable uptick in these responsibilities being managed by external services partners. But let’s set that aside for now. There’s something else happening there. In the context of the evolving marketing/IT split, the question you’d want answered is: are those external services providers reporting to the CIO or the CMO?

If I take a swag at illustrating this shift of martech ownership from marketing to IT, it might look something like this:

This raises a ton of questions. Is this shift real? If so, what’s driving it? And what does it mean for the future of marketing technologists and marketing operations professionals?

I do believe this is real. Given Gartner’s clientele of primarily large enterprises, it’s probably more prevalent in organizations at that scale than in smaller businesses or the mid-market right now. But it will spread.

I’ve seen this shift anecdotally at a few individual companies over the past year. But the real reason it rings true to me is that it makes logical sense in the context of how martech is evolving. And it’s actually a really good thing for marketing.

Here’s what’s driving this…

The Age of Aggregation in Tech Stacks

Simple consolidation, as one’s dominant technology management strategy, has fallen short. The diversity of apps in companies’ tech stacks has remained large because there are real business needs for specialized capabilities. And as new innovations arise in the market — along with corresponding changes in customer expectations — companies face real competitive pressure to adopt and leverage them as additive capabilities.

That’s not to say that consolidation isn’t good. By all means, consolidate as much as possible. But consolidation alone doesn’t solve all our tech stack challenges. We are still going to have many apps. But we need them to work together.

The more powerful — and adaptable — pattern that has emerged for this is aggregation.

Consolidation in about reducing a large set of things to a fewer number of things — or just one. Aggregation is about making a large set of things easier to consume or access through a single source.

Aggregation Theory in tech was conceived by Ben Thompson of Stratechery. He’s applied it mostly to Internet services such as social media, where an aggregator such as YouTube or TikTok aggregates millions of creators, making discovery and consumption easier for hundreds of millions of users.

Ironically, the best aggregators end up consolidated in their domain. An aggregator is most effective when there are only one or a few of them in a particular space.

It occurred to me a couple of years ago that this same dynamic was happening inside companies’ tech stacks. Cloud data warehouses, such as Snowflake and Databricks, aggregate data from many sources, making it easier for others across the organization to reach and use it. CRM platforms, such as HubSpot and Salesforce, aggregate an ever wider range of customer touchpoints — again, making it easier for such data and activities to be orchestrated from a single platform.

With aggregation, you can productively harness a wide diversity of apps in your tech stack, as long as they integrate with your chosen aggregation platforms. (You must consolidate to a small number of aggregation platforms to make this effective.)

Aggregation can happen at different layers within your tech stack: data, workflow, UI, and governance. I’ve shown a number of examples in the above graphic.

The important thing to note is that these are horizontal aggregation platforms. Most of them span departments across your organization. There are also vertical aggregation platforms — which aggregate data, workflows, UI, etc., within a particular business function. But for today’s discussion, let’s just focus on the horizontal layers.

Because these horizontal aggregation platforms span multiple departments, it makes sense that they should be owned and operated by a department designed to manage technology on behalf of everyone else. This is what IT was born to do.

Who should manage the cloud data warehouse infrastructure? IT. Who should manage your workflow automation platform? IT. Who should manage your shared analytics tools? IT. (Or, if company-wide data management or analytics lives outside of IT, it’s possible that department might be the better owner of some of these.)

The important point is: it’s probably not the marketing department.

These are not exclusively martech tools. Non-marketing teams use them too. But, they are certainly technology used by marketing. So we can call them inclusively martech tools.

I believe this shift will be a massive windfall for marketing operations for two reasons.

First, this is a classic opportunity to give away your Legos. Spending less time managing technology infrastructure will free up more time for marketing operations to build better processes, experiences, and enablement for employees and customers. I know of no marketing ops teams that have an empty backlog, at risk of running out of valuable things to do at any time in this decade.

Second, these aggregation platforms open up a tremendous amount of new data and new cross-organizational services that marketing can tap into. And it’s accompanied by greater technical expertise from dedicated IT and data teams running that infrastructure. This offers a huge opportunity to innovate on top of a much greater foundation.

To be sure, there will still be domain-specific platforms and apps that marketing operations will steward. But asymptotically, all of them will be connected to one or more aggregation platforms. This will increase IT’s governance over such integrations. But the additional operations power this will unleash for marketing will make that a sweet deal overall.

It’s worth emphasizing that in this future I believe more and more of the work marketing operations will do is composing automations, agents, analytics, and employee-facing and customer-facing custom “apps” built on the foundations of aggregation platforms.

Increasingly in this aggregated environment, marketing ops will have the opportunity to expel the frustrations of Inverse Conway’s Law from their stack and shape the way that marketing operates with far greater agency.

Let’s celebrate this shift of inclusive martech into IT. It heralds an exciting road ahead.

The post Dissolving martech? Tech stack aggregation brings more power to marketing, more control to IT appeared first on Chief Marketing Technologist.

Martech utilization sucks. At least that’s the conclusion one draws from Gartner’s latest 2023 Marketing Technology Survey, which includes the above chart.

“Thinking about the totality of the capabilities made available by marketing technology, what percentage of those capabilities are being utilized by your company today?” The average response to that question has dropped steadily for the past four years, from 58% in 2020, to 42% in 2022, to a dismal 33% here in 2023.

Now, I confess, I find this a rather dubious measurement. How does one determine what percentage of their capabilities are being used? How does extent of usage or frequency of usage of a particular capability get factored into this? Is there any quantitative analysis being done here at all by respondents, or is it just gut feel? A Likert scale from 0 to 100?

You could also question of whether utilization of capabilities is even a metric that should matter? If a product gives you great ROI for the subset of features you use that are relevant to your business, does it really matter that other, less relevant features in that product are unused? It’s not like there’s any physical waste there.

As recently as last month, I questioned if martech underutilization is a myth.

But still. For hundreds of marketing technology leaders in Gartner’s survey to report that they’re only utilizing 1/3 of their martech stack’s capabilities — even if that’s just their gut feel — is a pretty disturbing signal. If it were a Likert scale of 1-10, like NPS, it would be a very unhappy “3”. Major detractor.

So I’ll set aside my beef about the methodology here and dive into some ideas about how to diagnose and remedy this martech utilization crisis.

Before offering my rubric for such diagnosis, however, I want to draw a distinction between primary and secondary users of an application.

While “capabilities used” is a fuzzy measure of utilization, a more solid metric is frequency of use by the number of users who have a license/seat for that app.

When reviewing data about frequency of use in another report last month, it occurred to me that many apps have multiple segments of users in a company, each of which may have different usage patterns. Primary users of an app should be expected to use it frequently, while secondary users may use it infrequently — and such infrequent use for them may be perfectly okay. In fact, that may be the expected pattern of usage for them.

A few examples to make this concrete:

An analytics platform such as Looker might be used by analysts on a daily basis. But marketers might use it less frequently. A marketing ops pro might spend a lot of time in a CRM platform, aligning with sales ops or revops colleagues. But other kinds of marketers might only go into the CRM occasionally to look up a specific customer. A designer might often work in a particular creative tool, while other marketers might only use it when they need to access what the designer produced.

In other words, if you’re counting seats, not all seats are equal.

Makes sense, right?

We can also extend this primary vs. secondary user distinction to the range of an app’s capabilities used. Primary users might take advantage of a lot more advanced features within the product. Secondary users may not need those features — or may even be disallowed from using them.

Diagnosing Martech Utilization

We can now diagnose several different kinds of martech utilization metrics, consider the root causes of poor underutilization, and recommend how to fix them.

This is a simplified heuristic, of course. There’s a lot of nuance in evaluating utilization, especially with larger and more complex platforms. But hopefully this framework helps us talk more precisely about utilization challenges in our stacks and the options we have for resolving them.

Note that “do nothing” is a possible remedy, such as in cases where secondary users are only intended to work with the app infrequently. Or in cases where certain features simply aren’t relevant to your busiuness, but you otherwise love the app and are getting excellent value from it.

Probably the most underutilized remedy for underutilization — that’s a little meta — is investing in good enablement. Training, coaching, peer engagment, reference materials, managerial encouragement to experiment and learn, access to great help desk support, a culture of learning, etc., can all make a world of difference in the value you get out of your martech stack.

As Avinash Kaushik observed years ago, the 10/90 rule makes all the difference: invest 10% in your tools, 90% in your people.

Because utilization of talent that is the real thing you don’t want to waste.

The post Martech utilization problems: how to diagnose and remedy them appeared first on Chief Marketing Technologist.

One of the most interesting annual martech surveys out there is the Martech Replacement Survey produced by the team at MarTech.org. (Kudos to Chris Elwell, whose brainchild this was.) Every year they ask marketers:

• Did you replace any martech applications in your stack?
• Why did you replace them?
• What did you look for in the apps you replaced them with?

They also ask about commercial vs. homegrown martech, what the approval process was like, and how the replacement affected staff. Did existing employees get retrained or were new staff or service providers added?

Having run the survey for the past four years, this longitudinal dataset offers unique insight into the “churn” of martech stacks and staff.

As you can see from the chart above, the good news is that replacement of major martech systems has been steadily declining year over year. 2020 was clearly a year of enormous disruption in martech — and everything else, for that matter. The mad rush to all-digital transformation in the first year of the pandemic coincided with the zeinth of massive martech investments from VCs, a perfect storm of surging supply and demand.

Since then, however, things have stabilized significantly. For instance, in 2020, CMS systems were being replaced at rate of 41%. This year, that rate dropped to just 11%. The rates at which CRMs, email platforms, analytics/BI, and other attribution and performance tools were replaced have been cut by more than half. Notably, CDPs are an exception, continuing to churn around ~17%.

Overall though, it’s less rip-and-replace, more extend-and-embrace.

To answer the question of why replacement rates have plummeted, it’s easiest to ask what motivates a martech replacement in the first place?

The top reason that marketers look to swap out one martech app for another — at least commercially packaged apps — has consistently been to get better features (42% this year). The second most common motivation for the past two years has been better/easier integration (25%), which is near and dear to my heart. If you’re a martech vendor who isn’t prioritizing good integrations as a first-class feature, you’re ignoring the big, booming voice in the sky at your peril.

Somewhat surprisingly, reducing expenses comes in third place, at only 22%.

Once marketing has decided to kick an existing app to the curb, the list of factors that they look for in its replacement shows that cost matters — it’s the second most common criteria on which they evaluate alternatives.

But here too, integration capabilities and an open API stand out as a factor 36% of the time. Right behind that are data centralization and data capabilities (35%), which strike me as integration under another name. (The data layer is one of four dimensions of integration, but the foundation upon which everything else is built.)

So why are martech apps being replaced less frequently these days? The logical answer:

• Marketers are increasingly happy with the features of their martech apps
• These apps are increasingly integrated into their overall martech stack
• The cost of these martech apps align with the market prices for their categories

Otherwise, they’d be motivated to switch.

Personally, I’m delighted that better integrations seem to be permeating throughout the industry. This aligns with the patterns I see in my work at HubSpot, where more customers are integrating more apps and the inventory of off-the-shelf integrations available to chose from continues to grow rapidly. Martech still has further to go with better breadth and depth of integrations, but the progress is encouraging. And it’s showing up in results such as this report.

One related data point from Gartner’s latest CMO Spend and Strategy Survey reports that the majority of CMOs are under pressure to cut martech spend. The most common actions CMOs plan to take are to reduce investments in further improving and optimizing their existing martech solutions (62%) and to reduce investments in services focused on installing and integrating martech solutions (58%).

Surprisingly, pulling back on planned net-new martech solutions is only intended by 32% of those expecting to make cuts. The release valves for budget pressure seem to be mostly about getting more out of the current applications in the stack without as many third-party services supporting them.

Which brings me to one last encouraging finding from the MarTech.org survey. When companies are replacing martech products, they’re mostly (66%) keeping their existing staff. In another 16% of cases, they’re also adding new talent — while still retraining their existing team. Only in 10% of the cases are they ripping-and-replacing the team or, 9% of the time, hiring an outside services provider.

It’s great to see that martech and marketing operations teams running these systems are increasingly vendor agnostic in their skillset and roles and able to adapt to new tools. They’re operating at a strategic level above the tools, pushing against Inverse Conway’s Law. And the fact that companies are pulling back from outside services is also a growing recognition that martech management needs to be a core internal capability of the modern marketing department.

Greater stabilization of the martech stack — especially a more integrated martech stack — and of martech teams is an excellent sign of increasing maturity in martech and marketing ops. Let’s take a moment to celebrate that.

The post Martech stacks and staff are stabilizing, thanks to both better integration and budget pressure appeared first on Chief Marketing Technologist.

I’ve floated the idea of an Inverse Conway’s Law in previous posts before, but only in passing. So today I want to fully describe the concept, because I believe it is a useful way to understand some of the current challenges in martech — and why it may drive a major shift in marketing software in the AI Era.

Conway’s Law (broad interpretation)

To understand Inverse Conway’s Law, you first need to understand Conway’s Law. It’s named after Melvin Conway, an early computer scientist who in 1967 observed, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

The classic example of Conway’s Law is if you have three teams build a software app, the app will have three parts that relate to each other in a way that mirrors how those three teams interacted. The boundaries and hand-offs between the teams will be reflected in the way the software works.

I actually believe in a broader interpretation of Conway’s Law: the design of a software app will reflect the way the company that built it works — its organizational structure, beliefs, culture, and philosophy. The app is not just a mirror of the organization’s communication structure. It is the embodiment of how that firm thinks and operates.

Product managers sometimes talk about “opinionated software” that takes a point of view in how people should use it. But that’s just being conscious of this. All software is opinionated by the people who built it.

If you have 100 companies build even a moderately complex software app to accomplish the same high-level goal, you will get 100 different implementations. (This helps explain why the martech landscape has so many products that “kinda all do the same thing — but not really.”)

Inverse Conway’s Law is what happens downstream

But there’s an interesting corollary for commercially packaged software. A product reflects the organization of the vendor who built it. It does not, however, necessarily reflect the organization of a company who buys it. At least not initially. Very often a company that buys a non-trivial software app must adapt its own structure, processes, and experiences to fit the “opinion” of that software.

This is what I’ve coined as Inverse Conway’s Law: adopting a commercial software app often requires a company to adapt the way it works to fit the design of that software app.

Now, that’s not inherently a bad thing. Particularly if a buyer’s company needs to shift the way it works to adapt to new changes in the market. Being “shaped” by a software product that brings new processes and experiences to how the company operates is a feature, not a bug. You’re paying for software, but what you’re really buying is business transformation.

The history of martech brims with examples. Consider the roles and responsibilities of your current marketing operations team, their workflow, their relationships with other teams and each other. How much of your martech stack is mapped to your flow vs. how much is your flow mapped to your stack?

Differentiation drives firms back to Conway’s Law

Depending on the maturity of your marketing operations team, you may have answered that last question differently. Less mature teams are more likely to map their work to the design of the software they use. That out-of-the-box structure is a real benefit to them. They follow the sheet music and play the cover tunes. And it’s danceable.

More mature teams, however, start to improvise. They make the music their own. They want to perform originals, not covers.

Musical metaphor aside, mature marketing ops teams are more likely to have developed their own preferred workflows, customer journeys, employee experiences and customer experiences. They map the tools in their stack to their vision, rather than the other way around.

Inevitably then, they want to bend their software to that vision.

They are no longer are satisfied to simply consume an app. They’ll work to configure it, but may chafe against the constraints of what was made configurable or not configurable by the original developer. This will lead them to customize the app, where possible. But they are limited to the extensions points the vendor opened up to enable such customization.

This is when teams start composing their own apps. “Apps” may be overstating it, as initially these compositions are more workflows and automations using tools such as Workato and Zapier that cross app boundaries. They may use no-code tools such as Airtable and Webflow to assemble small database apps or web apps from templates and components. More advanced teams with more complex requirements may use low-code platforms such as Microsoft Power Apps.

Here they start to cross the boundary into creating software apps completely tailored to their needs. They become more likely to engage in open-ended programming with Python or JavaScript — albeit drawing upon a universe of software libraries and open-source frameworks to accelerate and simplify their development. At a technical level, this “create an app” stage gives companies the maximum degrees of freedom in crafting their digital operations.

But now we’ve come full circle. By building their own software, a company’s home-grown apps will be subject to Conway’s Law — the design of those apps will reflect the company’s structure, beliefs, culture, and philosophy. Which is exactly what they want.

As shown in the illustration above, moving along this spectrum — consume, configure, customize, compose, create — takes you from the dynamics of Inverse Conway’s Law to the dynamics of Conway’s Law. You gain more degrees of freedom. But the cost in required expertise and software development lifecycle (SDLC) overhead increases too. Is it worth it? It depends on the value your own business can unlock with a differentiated software app for a particular purpose.

Most businesses will have a mix of apps along this spectrum in their tech stack.

The future of martech software in the AI Era

Last week, I proposed a thought exercise to consider 3 possible scenarios for the future of martech in the Age of AI.

Would AI result in a massive expansion of the commercial martech landscape? Or will AI tools enable more companies to build their own apps, resulting in a shrinking commercial martech landscape but a massive explosion of custom-built software?

Or would AI consolidate all software into a small number of ultra-powerful super apps — Skynet for Marketers, if you will?

There has been some healthy discussion on LinkedIn around these scenarios. But most people believe the future will have more apps, not fewer. Sorry, Skynet, not today. The debate really revolved around whether we’ll see more commercial apps or more custom ones. (Or both, which is probably the most likely scenario.)

As you contemplate those alternatives, you can map the “more commercial apps” scenario to the left side of the spectrum above and the “more custom apps” scenario to the right side.

Will one dominate the other?

The post Conway’s Law vs. Inverse Conway’s Law and the future of build vs. buy in martech appeared first on Chief Marketing Technologist.

For years, people have been prognosticating the collapse of the martech landscape. That all these thousands of different martech apps are going to be winnowed down to a handful of winners. For the past 12 years, those predictions have been consistently proven wrong, year after year after year. (The myths of martech are nothing if not resilient.)

But maybe, just maybe, the Age of AI will be the inflection point that will bring those failed prophets redemption.

We’re going to give them — and you — a chance to place a bet on three scenarios for the future of marketing software in the AI Era that’s rapidly unfolding around us.

But first I’d like to offer a simple explanation for why predictions of martech’s collapse have been so wrong for the past decade. In a nutshell: people expected the market dynamics of the SaaS Era to play out like they had in the PC Era that came before it.

But software in the SaaS Era was radically different. Development, distribution, economics, interface, integration, buying, selling, context, experience — pretty much everything about software underwent massive structural shifts. Comparing software businesses from the PC Era to those of the SaaS Era was apples and oranges. Heck, it was more like apples and orangutans.

The SaaS Era software market wasn’t a “broken” version of the PC Era that was destined to eventually self-correct. It was a fundamentally different creature that was correct in different ways. And we only really learned the nature of it as it played out over a couple decades.

It seems likely that the AI Era could be as different from the SaaS Era as SaaS was from the PC and mainframe eras that came before it.

So what will the future of software — let’s narrow it to marketing software — look like? I’ve sketched out three possibilities and will walk through the rationale for each. To be sure, the future might look like something else entirely. Or some variation of or blend between these models. But in broad strokes, these seem like the major alternatives.

Option A: Software collapses into a few super apps

Okay, martech doom-sayers, this is the scenario you’ve been pining for. It’s possible that AI enables a small number of big vendors to embed HUGE amounts of functionality into their products while simultaneously simplifying the user interface to all that power with genie-like AI co-pilots that make it manageable by mere mortal marketers.

Who will those winning vendors be? Probably the largest incumbents today who already have market share and significant resources to quickly spend their way into AI-powered dominance. Those who have a ton of data in their flywheel are also going to be significantly advantaged.

What’s interesting is we might see major companies from outside today’s martech space move in with the benefit of their AI prowess and cross-business/cross-consumer scale. Amazon, Google, Meta, and Microsoft could all be formidable contenders in this scenario.

In this scenario, where a few super apps do it all, I don’t think you’d need a lot of custom-built software either.

While this martech superapp theory is conceivable, it strikes me as just steps away from the singularity. If a single app can manage everything in marketing — which any CMO will attest is one of the most complex, diverse, and ever-shifting fields in business — then why can’t it run the whole business? If it can do that, why not run the world?

Option B: AI lets everyone build most martech custom

Option B doesn’t converge to one-app-to-rule-them-all. Quite the opposite. It delivers much greater specialization of software, in a world where AI enables many more people to build much more custom software, faster and better.

For software engineers, this will be with coding co-pilots and more advanced, AI-powered services just an API call away.

But the real explosion of custom software will come from the next generation of AI-infused low-code/no-code platforms. No-code martech was already on the path to giving marketing operations pros and power-user marketers superpowers to craft workflows, integrations, interactive content, data analyses, simple web apps and mobile apps, and more. AI will both boost the power of these no-code tools and make them more accessible to general business users. It could easily 100X the amount of custom software “apps” in the world.

At this intersection of no-code AI and composability, most marketing teams will be able to assemble custom software that is tailored to their specific needs and business operations. It will be highly malleable and mark the demise of Inverse Conway’s Law (my observation that companies have had to adapt their businesses to the software they use rather than the other way around).

There’s still a place in this scenario for commercial software. But it will be mostly no-code tools for building things, API services these no-code apps draw upon, and the underlying platforms that provide critical cohesion across all these purpose-built agents, apps, and automations.

The vast majority of apps marketers work with day-to-day will be built, not bought.

Option C: An exponential explosion of all software

Option C looks at the size of today’s commercial martech landscape and says, “Hold my beer.” Like Option B, this scenario will see an exponential explosion of new specialized software apps. But in this case, a large number of them are commercially available apps that marketers buy, not build.

If you took a snapshot of the emerging AI Era today, this would be the scenario currently playing out. A flood of new AI-powered apps rolls out every week these days.

But will that last? There’s certainly a limit to how many large software companies the market can hold. But it’s possible that the long-tail of many smaller software companies could grow significantly. They won’t fit the VC funding model that defined much of the martech wave of the 2010’s. But they could be bootstrapped and profitable small businesses.

This is what Kevin Xu, senior director at GitHub, envisions in a post he wrote explaining how AI will create more developers, not less:

“More digital products will be created, but the companies that build them will on average be smaller. More of them will be bootstrapped, self-funded, generating revenue earlier in their lifecycle, and not funded by VCs. There will be more and more one-person teams building meaningful products and companies.”

Of course, there will still be large software companies at the head of the tail. In particular, platforms that serve as a cohesive force for these myriad of specialized apps will be immensely valuable. This is why I believe the biggest strategic battles today are around winning ecosystems. (Of course, I’m biased, since I work at HubSpot on their platform ecosystem.)

There’s composability here, like in Option B. But many more of the “Lego blocks” you’re composing with are bought, not built.

This explosion of commercial apps, mini-apps, and micro-apps doesn’t preclude the possibility of a ton more custom software too. In my illustration above, the blue area of custom apps stretches beyond the boundary of the graph. By how much? I’ll leave that to you as an exercise for the reader.

What’s your prediction for the future of martech?

So which do you think is most likely? Scenario A, B, or C? Why?

Don’t worry, I won’t hold you to your prediction. Because in truth, I think all three of these scenarios are plausible. Part of why I’ve sketched this is to help people keep an open mind about these different alternatives, so we can be ready to adapt to any of them.

Because almost certainly, the AI Era will be different from the SaaS Era.

P.S. My best guess? I’ll go with Option C. But Option B is a close second.

The post 3 possible scenarios for the future of martech in the Age of AI appeared first on Chief Marketing Technologist.

Why let data get in the way of a good narrative?

Tech stacks are going to shrink dramatically. Marketing’s tech stack is bloated compared to every other department. Shadow IT is a scourge across major martech systems. And most SaaS products — especially martech apps — are highly underutilized, a wanton waste of resources.

It’s enough to make you shake your fist in the air. “Down with martech! Down with SaaS!”

The only problem with those cathartic rants? They’re not true.

Or, more accurately, the latest data from Productiv’s 2023 State of SaaS report doesn’t support those claims. On the contrary, it mostly refutes them.

Productiv is a SaaS intelligence platform that helps companies manage their tech stack. For this report, they analyzed over 100 billion app usage data points across nearly 100 million SaaS licenses managed through their platform over the past 3 years. So the basis for their report is empirical data, not unreliable survey answers. And it’s a pretty significant pool of data to draw meaningful analyses from.

So what does their data say about these popular “myths” of martech madness?

Myth #1: Tech stacks are shrinking dramatically

Nope.

As you can see from the graphic at the top of this post, SaaS tech stacks haven’t shrunk significantly. In fact, the average SaaS stack grew 32% over the past two years.

However, that doesn’t mean there hasn’t been some “rationalization” in tech stacks:

You can see that after peaking in 2022, most categories of apps in company tech stacks started to reduce the number of different products they were using. Granted, this was after a much larger jump in app diversity from 2021 to 2022.

Such rationalization of tech stacks is good, clean living, and I’m all for it. But it hasn’t made a significant dent in the total size of stacks.

Will this consolidation trend continue? Possibly. The challenge in predicting these things is that it’s the tech stack equivalent of the three-body problem. While there are strong forces in the market and in IT that work to reduce the number of apps, a continually changing tech landscape — hello, AI — keeps spinning up new products that companies eagerly adopt to stay competitive.

Anyone who claims they know, with absolute certainty, how that will net out in the next few years is delusional. Or maybe with the benefit of being Fooled by Randomness, prophetic.

For me, empircal data remains the arbiter of such debates. And this data unequivocally says that, as of today, tech stacks have not shrunk dramatically.

Myth #2: Marketing has the largest tech stack

No, actually, marketing has the second smallest tech stack.

Granted, an average of ~75 apps being used within marketing — note, this count includes apps used across multiple departments — isn’t exactly small. But it’s below the company-wide average of 83, and well below the 100+ apps used on average by engineering and operations teams.

I can’t help but note wryly that IT & security teams use more apps than marketing, sales, or customer success teams. And in the chart of app categories that we looked at earlier, it’s Security & Compliance that pops with nearly twice as much diversity of apps compared to any other category. Who’s guarding the guardians of SaaS sprawl?

As Alanis sang, “Isn’t it ironic, don’t you think?”

Myth #3: Shadow IT is a terrible scourge in martech

“Shadow IT” is the label used for software apps that business users adopt without express permission from IT. Other things being equal, I’m against it — as most rational ops people I know are. For security reasons, compliance reasons, financial reasons, support reasons, and more, it’s a wise idea for the IT department to have visibility and governance across the apps employees use.

So when you hear that 51% of SaaS apps are identified as shadow IT — the stat cited in Productiv’s report — it’s easy to get the impression that major systems are rampantly out of control. And, of course, marketing and martech are assumed suspects for such shadowy SaaS skullduggery.

But Productiv double-clicked on that stat to reveal the top 20 apps that contribute to this shadow IT scourge:

Hmmm. Coursera? Grammarly? Glassdoor? Todoist? Doodle? Meetup?

I’m not saying there’s zero downside to people using these products outside the watchful eye of IT. But a marketing manager using Canva to generate a few graphics to promote a get-together on Meetup doesn’t seem like a four-alarm crisis. Frankly, the line between “app” and “website” seems blurry here. ChatGPT is an app, but Bing and Google Search with Bard enabled are websites?

Yes, these shadow IT apps should be brought out of the shadows.

But looking through this list puts things in perspective. Especially since anything that you would consider to be a core part of a martech or salestech stack is nowhere to be found here.

Myth #4: Most SaaS is terribly underutilized

I’ve long argued that utilization is often a misguided metric in martech.

When talking about a specific product, it makes little sense to measure utilization by how many of its features you use. Most apps have a ton and are constantly adding more. Use the ones that matter for your business. Don’t feel compelled to use the rest. They’re not “wasted” just because you don’t use them. Software doesn’t work that way.

A more reasonable measure of utilization is whether the app is being used at all. Or, more commonly, if you have multiple “seat” licenses for a product at your company, how many of those are being regularly used by the people they’re allocated to?

This is the measurement that Productiv reports: how many SaaS seat licenses have had any usage within a 90 day period? Their answer: on average 47% in 2023. Which is pretty shocking! 53% of a company’s SaaS licenses aren’t being used regularly?!

The obvious move would be to cut half your licenses and — implied — halve your costs.

But sniff test: something doesn’t smell quite right about that. That seems like an awfully big number for so many companies to have been blind to for so many years.

Once again, Productiv sheds some light on what’s really happening by listing the top 10 apps with the lowest utilization rates in Q1 2023:

First, I’d point out that no martech app is in the top 10.

But more importantly, the “worst” offender on this list — Greenhouse, which has only a 20.1% utilization rate — reveals a more rational explanation for so-called underutilization.

Greenhouse is an applicant tracking and hiring platform. Naturally, it’s used regularly by anyone in recruiting and perhaps with reasonable frequency elsewhere in HR. But to be effective, everyone else in the company who is ever involved with hiring people — hiring managers but also anyone who even once interviews a candidate — also needs to use it. That’s a lot of people. But most of them are involved in hiring only occasionally, perhaps rarely.

As result, probably most Greenhouse users don’t utilize the app in a 90 day window.

That’s not an aberration, and it’s not “waste.” That’s how the software is designed to be used. And while I don’t know the details of Greenhouse’s pricing and packaging, I’m sure that’s reflected in what they charge. Because the ATS space — like every other SaaS category — is insanely competitive. If Greenhouse were to massively overcharge, they would get eaten by a more fairly-priced alternative. Switching costs on an ATS aren’t that big of a barrier.

You see this same dynamic with other “offenders” on this top 10 list too.

DocuSign? Legal and procurement might need to sign things frequently. But many more people in the company need to sign things only once in a while, maybe a long while. 55% regular utilization seems pretty impressive when you think about it.

ServiceNow? If that’s used for IT service management, then IT staff are probably regular users. The rest of the company only occasionally utilizes the product when they need to request a service from IT. So here too, 58.9% utilization seems about right. You could argue that most companies would want lower utilization, as it would mean fewer requests for the IT department.

The point is that you can’t just ditch all these “underutilized” Greenhouse, DocuSign, or ServiceNow licenses without breaking the fundamental value they provide. They actually are being utilized in the exact way they’re intended to.

Products such as Asana, Jira, Miro, etc., are a little different. In theory, you can imagine how they could — should? — be used by most people most of the time. But in practice, especially in a larger company, that’s not what happens. Some teams or individuals within teams use those products a lot. Others not so much. But the option to access an Asana, Jira, or Miro board when necessary is valuable to non-frequent users.

There is a more plausible argument that such underutilized licenses are wasted.

But even then, the reality of SaaS purchasing compensates for this. When companies negotiate for enterprise-wide licenses to such popular-but-not-universally-used apps, this utilization is factored into the discounted price they pay. While there may be a number of “seats” allocated in such a deal, it’s really more of a fixed-priced bundle: get access for your entire company for $X. You can divide $X by your number of employees n, but it’s somehwat of an artificial number. All that really matters is whether it’s worth $X for you to have that capability company-wide. If it is, buy it. If it isn’t, don’t.

There’s no physical waste here at all. You’re simply paying for a set of employees to use the product regularly and for the rest of your employees to have the option to use the product occasionally — and maybe even be converted to using it regularly.

Anyway, this isn’t to say that you shouldn’t work to reduce truly underutilized apps from your tech stack. SaaS management platforms such as Productiv are super valuable for helping to eliminate redundant and unused apps. And they can be very helpful tools in negotiating fees for “underutilized” — i.e., occasionally used — apps.

But the notion that the vast majority of SaaS is truly underutilized is a myth — even if it makes a great narrative to rant about.

The post Countering 4 “myths” of tech stack dysfunction: shrinkage, martech, shadow IT, and utilization appeared first on Chief Marketing Technologist.

Lately, I’ve been excitedly talking about “composability” as a major new trend in martech (and business technology in general). But in the absence of defining it more precisely, the term has triggered some confusion and debate about what is or isn’t technically feasible today.

So let’s rectify that.

In the most broad sense, composability is simply the ability to combine things together. This might be data, for instance, if you want to analyze products (one dataset) that have been sold to customers (another dataset). Or it might be steps in a workflow, app, or customer experience — e.g., when a prospect fills out a form, add or update them in your CRM and email them the report they requested.

So, wait, this doesn’t sound very new. Haven’t people been doing that for decades?

Yes! If we look at this spectrum of composability that I’ve sketched — I’ll explain it in more detail in a moment — some ways of composing things together have been around for ages.

Spreadsheets are probably the oldest “no-code” tool for business users to “compose” data analysis by combining different lumps of data together on a sheet — or, more ambitiously, in a workbook — where they could manipulate them into something insightful. Historically, most of those lumps of data were either manually typed in by the user or imported from a CSV file. Not exactly state-of-the-art data pipelining. But effective. Marketers have gotten a ton of mileage out of Excel and Google Sheets.

On the more technical end of the spectrum, programmers have been “composing” apps by using packaged functionality from reusable libraries for the past half century. The concepts of encapsulation, modularity, and reusability have been foundational to the discipline of software engineering. No developer writes everything from scratch. They pull in existing libraries — Python has over 400,000 such packages — or API services in the cloud from AWS, Azure, or Google Cloud to assemble an app. They stand on the shoulders of others who came before them and try to only add net new functionality or the logic of how these pieces fit together for a specific purpose.

Trading granularity/flexibility vs. guardrails/safety

I keep putting “composability” in quotes above because while spreadsheets and software libraries are used for composing things, the more modern notion of composability seeks to bend the trade-offs between these two opposite ends of the spectrum.

There’s been a kind of Pareto curve between granularity of composability (how much control do you have at the most minute level) and guardrails for composability (how constrained are you in what you can do, often for your own good).

Composing with code, with a high-degree of granularity, has required significant technical expertise. It gave you essentially unlimited flexibility in what you could build. But all that freedom was a double-edged sword. You could easily hurt yourself by accidentally doing bad things. Bug city, baby.

In contrast, using a basic spreadsheet — without any fancy scripting or advanced function calls — would let you combine data together. But you could only work with “small data” that fit into a tabular format that was a static snapshot in time. You couldn’t execute workflows or build apps with it. This was significantly more limiting than programming with code. But it was much, much safer. The guardrails of what you were able to do and not do within a spreadsheet kept you from hurting yourself, at least in a technical sense. (You could still hurt yourself with shoddy data analysis presented to a skeptical CFO, but that’s different.)

Much of the innovation in composability over the past 5-10 years has been filling in the middle between these two ends of the spectrum. Low-code platforms could build apps or workflows with a little less flexibility but safer guardrails. No-code products even more so. Pick your preferred trade-off point along the curve.

Many contexts for composability in marketing

“Filling in the middle” between the dangerously-unlimited and the safely-constrained incarnations of composability has been a boon for marketing and martech. A lot of the innovation here has been a result of narrowing the context of a particular platform or tool, so as to put guardrails around that context but provide a lot more flexibility within it.

Sorry, that’s a bit abstract. A couple of examples to illustrate the power of context…

No-code website builders took off because they narrowed the focus to creating pages that had limited technical functionality and set design boundaries with themes and templates. This gave non-technical marketers tremendous freedom to quickly, easily, cheaply publish great-looking landing pages and microsites, with low-risk of technical error.

Any content marketer could now compose a web page from pre-built components within the no-code website builder’s editor.

On the more technical side, CDPs have been a heck of a lot easier for technical marketers to work with than raw databases, because they operated within the context of creating customer profiles and audience segments explicitly for marketing use cases. They enabled more freedom for how data could be ingested and composed into operational marketing datasets than the “closed” marketing suites that came before them. But the operations of how such data was leveraged — which could get more technically complex — was often downstream from the CDP itself. This made the environment inside the CDP safer to work in, at least relatively speaking.

Yes, I know, you can still make mistakes — big mistakes — with data inside a CDP and the things you execute with that data downstream. But those risks are much more controlled than the open-ended, Wild West of writing Python programs against a generic relational database.

Any data-savvy marketing operations professional could now compose audiences within a CDP, assembled from multiple sources of data.

Now, the term “composable CDP” has come to mean something more specific. Instead of having to copy data into your CDP to use it, composable CDPs let you use data directly from your cloud data warehouse without copying it. This has advantages of reducing storage costs, data desyncs, and security and compliance risks. In this sense, you’re composing across physical data storage in addition to composing logical datasets.

But setting aside the technical architecture innovation, the benefit of a composable CDP is to simply make it cheaper, easier, and faster to compose customer profiles and audience segments.

My point: everything described above is composability that exists in marketing today. To the degree that we don’t talk much about it explicitly, it’s actually a testament to how well this composability works. Composability is best when it’s almost second-nature in context.

So why is composability being talked about as something new?

A New Generation of Composability

This new generation of composability is riding a massive wave of API proliferation and the gravitational flow of more data into centralized cloud data warehouses (CDWs).

As applications expose more of their functionality via APIs — driven by the market demand for integration between apps — those APIs can be used to programmatically “compose” workflows and customer experiences that span multiple applications behind-the-scenes. As applications pipe more data into CDWs, it’s all stored in one universal and professionally governed location, where it can more easily be “composed” into context-specific datasets.

iPaaS and workflow automation products, such as Workato (enterprise) and Zapier (SMB), have long taken advantage of APIs to let low-code/no-code users orchestrate workflows across multiple apps. But as the number of APIs grows — and as deeper functionality is exposed through them — it becomes possible to not merely sequence integration tasks between apps, but to effectively craft your own custom apps with those API services used under the hood.

Here’s a metaphor: instead of the glue holding the timbers of a ship together, the glue becomes the surface of the ship itself, with the embedded timbers serving as a frame and a structural support inside. The glue is infinitely more malleable, and lets the shipbuilder create highly differentiated ship designs.

Okay, that’s an overextended metaphor. But do you get the idea?

There’s also a ton of innovation happening in building better “contexts” for composability in marketing. One approach that has a lot of runway is multi-level composability: an IT expert might define certain boundaries for composability, upon which a marketing ops manager might package up pre-defined bundles of data or functionality, upon which a non-technical marketer can assemble campaigns and programs from those ready-made components. Each level creates a “context” for the next level up.

However, the really exciting thing ahead for composability is generative AI.

You knew that was coming, right?

Generative AI engines will be able to understand the technical mechanics of writing code, invoking APIs, and mapping across multiple data sources on one side. On the other side, they’ll be able to accept natural language requests from more non-technical users and translate them into composed workflows and datasets.

This will effectively shift the accessibility of more advanced composability further within reach of less technical users. The likely second-order effect of this will be ever more customized internal digital operations and external digital customer experiences, crafted and adapted on-demand by everyone across the marketing org.

Generative AI will be able to push out the Pareto frontier of enabling more flexibility while simultaneously providing more context-specific guardrails because it will be able to understand the full enterprise architecture in which these requests are being made.

We’re not there yet — although it’s advancing quickly.

This is why I and many others are so excited about composability as a “new” thing these days. Composability-wise, we’re on the cusp of transitioning from rowboats to rocketships. But the core concept of composing things from point A to point B has been with us from the beginning.

The post Composability is already everywhere in martech today, you just may not realize it (which is a good thing) appeared first on Chief Marketing Technologist.

To regular readers, it’s no surprise that I’m bullish on ecosystems. I’ve long advocated that platform ecosystems solve many of the challenges of an ever-changing, highly-diversified martech landscape. It’s also what I focus on at HubSpot, with the company’s ecosystem of technology partners. (So, yes, I’m biased. But that doesn’t mean I’m wrong.)

In my post earlier this month, I explained why platform ecosystems are powerful as an engine of innovation. Today, I’d like to highlight the remarkable impact ecosystems can have on a company’s go-to-market performance.

But first, I want to emphasize that I’m not just talking about software platform ecosystems. When it comes to go-to-market opportunities, many different kinds of businesses have an ecosystem of complementary products and services that are related to their business. Anything that influences your customers in how or why they select, use, or get value out of your own offerings is potentially part of the ecosystem around your business — whether you acknowledge it and actively manage it, or not.

McKinsey, who studies these things at the macroeconomic scale, estimates that a full 1/3 of the world’s economy will be driven by “integrated networks” of related businesses — to the tune of $105 trillion (that’s trillion with a t) — by 2030.

It’s worth contemplating just how broad your own unearthed ecosystem may be.

Activating other companies in your ecosystem is usually done through partnerships. Classically, the majority of these are sales “channel” partnerships. But as Jay McBain — the world’s leading analyst in this domain — has pointed out, there are often many other potential partners who assist and influence sales and customer success, beyond the one partner who executes the purchase transaction.

All of them have potential to be harnessed in ecosystem sales and marketing motions.

HubSpot, Partnerships Leaders, and Pavilion just released a joint report on The State of Partner Led Growth, surveying over 200 marketing and sales leaders about how they leverage partnerships in their go-to-market and the performance impact they see from it. The results are pretty eye-opening.

The chart at the top of this post has the key takeaway: 80.5% of marketing and sales leaders who aren’t directly in partnerships themselves (the light teal bars) report that partners are becoming a more effective channel in reaching their audience.

A full third of them (33.9%) said partners were becoming significantly more effective.

That’s remarkable because most marketing and sales channels are fighting noise and entropy that make them less effective. From demand generation in marketing to outbound prospecting in sales, the hill keeps getting harder to climb. So to have a go-to-market channel that is accelerating in its performance is noteworthy.

By the way, on the dark teal vs. light teal bars. Many partnership teams report into sales or marketing or the broader revenue org. So we segmented the responses from those leaders directly owning partnerships vs. those who don’t. As you’d expect, partnerships people tend to report a more optimistic view. The non-partnerships leaders bring a more objective lens, so I view their responses as closer to the ground truth. (That said, it is interesting to see where and by how much the two segments diverge in their opinions.)

Let’s look at a few other data points as to why partners are seen as more effective.

Quality leads are the bloodstream of B2B marketing, where “quality” is in the eyes of the sales org by their close rate. The majority (55.6%) of non-partnerships marketing and sales leaders say that partner-sourced leads close at a higher rate than the average lead. A third (33.3%) reported that partner-sourced leaders are significantly (26% higher or more) likely to close.

This goes beyond just sourced leads to also influenced leads. When non-partnerships sales leaders were asked which factor has the biggest impact on a prospect’s purchase decision, prior to speaking to the sales team, trusted agencies, consultancies, and tech vendors were ranked #2, only behind opinions of people in the buyer’s own professional network.

Given this data, it would make sense for marketing to look for opportunities to bring more partner-sourced or partner-influenced leads. One way to do that is through co-marketing programs and campaigns.

While co-marketing motions aren’t as common — for reasons we’ll dig into in a moment — the data suggests that they are more effective on a number of important dimensions:

For brand awareness, engagement rates, conversion rates, lead quality, and the lifetime value (LTV) of those leads, co-marketing campaigns outperform the typical marketing campaign.

The one criteria on which they don’t is customer acquisition costs (CAC). In some of the qualitative interviews conducted as part of this report, the concern of a “planning tax” was raised as a reason why co-marketing is less frequently pursued and view as more costly (in time and effort as much as hard costs).

This makes sense. Coordinating inside one’s organization can be challenging enough. Coordinating across multiple organizations even more so. But this is where I see an opportunity for marketing operations and a growing field of partner-oriented marketing technology to help systematize and optimize more ecosystem marketing motions. The space around 2nd-party data martech is evolving rapidly, and given the statistics in this report, the opportunities for leveraging it effectively are quite promising.

There’s a bunch more data in this report, which you can download for free, as well as fascinating interviews with CROs, CMOs, VCs, and GTM-experts from BCG — whew, that’s a string of acronyms — on different facets of running effective partner-led growth.

The post Breaking through the noise getting harder? Here’s one marketing channel that’s getting more effective appeared first on Chief Marketing Technologist.

A few weeks ago, an internal memo from Google (or so it was claimed) was leaked that warned, “We have no moat.” Allegedly, it was written by an AI researcher at the company who was explaining how the real competitive threat to Google’s generative AI initiatives wasn’t OpenAI. It was open source communities.

If you want to understand the enormous power of ecosystems — and if you’re in martech, this may be the most important topic of your career — there’s a true masterclass in the subject playing out in front of us.

A super short summary of that memo: while Google and OpenAI were busy investing in their own massive but “closed” large language models (LLMs) with Bard and ChatGPT, a foundation model from Meta — LLaMA — was released/leaked as open source. Within a matter of weeks, hundreds of independent developers all around the world built upon that model in ways that rapidly approached the performance of Bard and ChatGPT, but at a fraction of the cost. They found ways to make the model smaller, run on laptops and even mobile phones, accelerate training and tuning, and more.

Meta’s LLaMA was taking off as a platform for ecosystem-led innovation.

“Plainly put, [the open source community is] lapping us,” the Google memo stated. “Things we consider ‘major open problems’ are solved and in people’s hands today. … While our models still hold a slight edge in terms of quality, the gap is closing astonishingly quickly. Open-source models are faster, more customizable, more private, and pound-for-pound more capable.”

Pause here for a moment.

Consider: a trillion-dollar company with many of the world’s most talented AI developers — this current wave of generative AI is based on their invention — and billions of dollars to spend can’t keep up with the speed of innovation of an uncoordinated mass of hobbyists, students, and tinkerers.

“The value of owning the ecosystem cannot be overstated,” the author concludes (emphasis theirs). “Google itself has successfully used this paradigm in its open source offerings, like Chrome and Android. By owning the platform where innovation happens, Google cements itself as a thought leader and direction-setter, earning the ability to shape the narrative on ideas that are larger than itself.”

Why ecosystems are often underestimated at first

What is the deadliest animal on earth?

Great White sharks? Bengal tigers? King cobras? Cocaine bears?

Nope. It’s mosquitos, which kill 725,000 people every year by spreading disease. Sharks, in comparison, kill about 10.

Now, don’t take that metaphor the wrong way. My point is that just as people underestimate mosquitos because of their individual size, large companies often underestimate the impact of many, individually small contributors in an ecosystem.

Large companies tend to view the world in terms of big chunks:

1. Who are big competitors that threaten them?
2. What are big M&A deals that can significantly expand their market?
3. What are big products they can launch that will generate big revenue streams?

Hey, those are totally valid ways of thinking about their strategic landscape. When you’re big, only big things move the needle. But this focus on individually big things can cause them to overlook swarms of small things that can be very big in aggregate. They’re looking for Jaws in the water from a beach tower while unconsciously waving away the mosquitos circling right in front of their eyes.

They can think — as perhaps Google did with their initial approach to generative AI — that their size uniquely enables them to drive breakthrough innovation. But in truth, innovation often happens in a more evolutionary way, with hundreds or thousands of experiments and iterations that converge in a paradigm shift (as in the Thomas Kuhn definition of scientific revolution, not eye-rolling corporate-speak).

Small companies, entrepreneurs, and individuals are much better suited to embracing that frenzy of experimentation. They’re less constrained by existing products, revenue streams, org structures, budget committees, approval processes, executive politics, etc. Without that friction, they jump right to trying their ideas. And if one idea doesn’t work, they try another. And another. And another.

The magic here isn’t in any one person or team taking that experimental approach. It’s in a legion of them, all trying different ideas in parallel, cross-pollinating the winning concepts, building on them, competing with different variations. Most individual contributions to the field are small. But in aggregate they are a relentless force of nature.

It’s hard to replicate that dynamic of innovation inside a closed, large company.

There’s another aspect of size that escapes big companies and enables small ones, and that’s specialization. Big companies need big products that generate big revenue streams. This drives them to pursue broad horizontal offerings that serve wide audiences. That’s not a bad thing. But it filters out a vast range of more specialized opportunities that don’t meet the threshold of being an obvious $1 billion line of business in five years.

But for small companies, entrepreneurs, and individuals, those specialized opportunities are golden. They can build something that is the very best at what it does within a more focused domain. They can tailor it in ways that big-company, horizontal products can’t because they’re willing to ignore large swaths of the broader market in order to delight a smaller subset.

Ironically, some will grow to become $1 billion runaway successes by not requiring that as a pre-validated outcome at the start.

This is part of a broad cultural and market shift over the past three decades, what Seth Godin identified as “the end of normal” — the flattening of the bell curve distribution of consumer preferences — and the rise of tribes, catalyzed by the Internet. There are over 19,000 craft beers in the world. Over 5 million podcasts. 2.8 million subreddit communities. 5.9 million sellers on Etsy. A blog or newsletter for every subject imaginable (even one for strategic martech geekery).

It shouldn’t be surprising that this same dynamic is happening in software. There are 1.6 million apps in the Apple App Store, 3.5 million in the Google Play Store. There’s 58,000 WordPress plugins. And, of course, 11,000+ martech products, which is just a fraction of the 100,000+ business software apps listed on G2.

The symbiosis of platforms and ecosystems

But here’s the catch. Nobody wants to deal with hundreds of fragmented, siloed products in their lives or their business. We want our choice of apps on our phone, but we want them to all work on our one phone. We’d never lug around a dozen different devices to use a dozen different mobile apps.

Platforms solve this problem by providing a common foundation upon which a set of apps interoperate. They serve as a coordinating device not only for shared technical standards but also for reach and reputation to a defined audience. They’re the center of gravity for a community of people who use that platform and its surrounding apps, which brings a ton of secondary benefits for all: best practices, career development, supporting services, talent networks, etc.

So what prevents a proliferation of platforms, pushing the problem down a level?

In general, software platforms need a large user base in order to persuade developers to invest in building to them. Development effort and go-to-market effort are zero-sum games: what you invest in one platform you aren’t investing in others.

Which companies tend to have large user bases? Large companies.

Do you see the beautiful symbiosis here?

It’s difficult for large companies to innovate through diversified experimentation themselves, and they can’t justify building products for niche markets. But they have a large user base at their core, for which they can serve as a coordinating force for other apps around them.

In contrast, thousands of small companies can innovate like the wind and address a long tail of specialized customer needs — but individually they don’t have the market power to serve as a coordinating force for all the other adjacent apps in their space.

It’s a match made in heaven. Potentially.

See, all those small companies, startups, and individual innovators have a ton of choices of existing and emerging platforms on which they can place their bets. A large user base on the platform is a major factor. But it’s not the only one. It matters what the platform enables them to build and how it supports their go-to-market. It matters if they trust the ecosystem to be a fair and level playing field, where they can win through their own merit. It matters the degree to which they feel appreciated and loved.

This rarely happens by accident, but by intentional choices of the platform company.

People tend to think that platform companies can act as “kingmakers,” able to pick winners within their ecosystem. (It’s tricky, and I generally don’t recommend it.) But in fact, it’s the participants in an ecosystem who are the real kingmakers. By voting with their development choices, they determine which platforms will thrive and which will wither.

I think that Google memo was right on the money.

Creating an ecosystem around your platform is both immensely valuable and incredibly hard to do. But the challenges that make it hard are the very reasons it can be a real moat. Once a company starts getting flywheel effects around its ecosystem — more developers create more value, which attracts more customers, which attracts more developers, and so on — it’s increasingly difficult for a competitor to usurp it.

In my opinion, generative AI will be all about the ecosystems.

The post The key point of Google’s “we have no moat” memo on generative AI is that ecosystems are the moat appeared first on Chief Marketing Technologist.