I recently wrote how martech stacks have arguably become virtual platforms. Even if you have a completely heterogeneous, “best-of-breed” stack, you likely have a set of products that work across your stack to provide cohesion, albeit each at a different layer of integration:
- Data: everything ultimately ends up in a “data lake” platform such as Snowflake
- Workflow: tools such as Workato and Zapier orchestrate processes across apps
- UI/UX: tools such as Slack provide a common UI to interact with many different apps
- Governance: SaaS management products such as Torii and Blissfully help govern all the SaaS apps in your stack
That’s not to say that these canonical services for particular capabilities at different layers in your stack, when taken together, are perfectly a platform. But each is a platform in its own layer and domain, and if you connect the dots between them, you get remarkably close to a diversified yet scalable “virtual platform.”
Now, another way of thinking about platforms is as vehicles for aggregation. The four layers of integration also correspond to four layers of aggregation in a platform, as shown in the graphic at the top of this post:
- Data Layer = Aggregating Data
- Workflow Layer = Aggregating Process
- UI/UX Layer = Aggregating Experience
- Governance Layer = Aggregating Control
Aggregating data is what we most often think about with platforms in martech stacks. But the other layers of aggregation are important too — even more so as we move from big data to big ops.
Aggregating Time
Hugh Durkin, who works with me on platform ecosystem at HubSpot — and also writes an excellent Developer Ecosystem blog — has inspired me with his insights on how platforms are often about “aggregating time.”
Human time and attention are the scarcest resources in our infinite digital age. Platforms that acquire a larger and larger share of time where people spend their day acquire greater and greater power. They mostly achieve this by providing a common UI/UX experience where their target users are able to service more and more of their needs, without having to jump out to other apps or browser windows. But value can also be unlocked by saving time in other ways, such as automation.
I’ve taken Hugh’s elegant concept of aggregating time and inelegantly split it across the different layers of integration to better illustrate the relationship between integration and aggregation. Aggregating data, workflow, UI/UX, and governance all play a role in aggregating time. But their contributions are distinct enough that, especially in a virtual platform stack, different products are able to be the authoritative service for that slice of aggregation.
So, for example, SaaS management platforms such as Blissfully and Torii aggregate time for ops teams running marketing stacks because they help aggregate control. An ops pro can see everything running in the stack, who’s using it, what’s spent on it, where there’s unwanted redundancies, etc., both saving them time and serving as an aggregated interface for such governance tasks. But they don’t directly aggregate customer data, or broader workflow, or customer experience.
They aggregate just one layer. In fact, they aggregate just one facet of one layer.
But aggregating one facet of one layer can be powerful in a heterogeneous stack.
Aggregation Theory Inside a (Martech) Stack
It’s impossible to talk about aggregation with platforms without immediately thinking of Aggregation Theory as defined by Ben Thompson of Stratechery.
A number of years ago, Ben came up with aggregation theory as a framework to explain the dynamics of platforms such as Facebook, Google, Airbnb, Netflix, etc. The three characteristics of “aggregators” he identified:
- Direct relationship with users.
- Zero marginal costs for serving users
- Demand-driven multi-sided networks with decreasing acquisition costs.
Uber is a good example. It owns the relationship with app users (in contrast to taxi companies that had no persistent relationship with their customers). They incur almost no marginal cost for each additional ride a user takes (as compared to taxis themselves, which have to pay for fuel and depreciation on their vehicles). And there’s a flywheel effect where acquiring more users attracts more drivers, and in turn, greater driver coverage attracts more users, and so on, which decreases acquisition costs for both supply and demand.
There are some important subtleties in aggregation theory that I won’t do justice to here — but do go read Ben’s work on the subject if you aren’t already familiar with it.
I believe that aggregation theory is also playing out inside companies’ tech stacks.
Each of these canonical products in a stack that serve to aggregate even one facet of one layer of a company’s virtual platform are effectively “aggregator” services — with dynamics that are very similar to aggregation theory in the Internet at large.
These in-stack aggregators:
- Own a relationship with users — such as being their UI for communications and collaboration (e.g., Slack) or the reference “source of truth” for a set of data (e.g., Snowflake).
- Incur zero marginal costs for serving users. For example, no matter how many channels and conversations you’re having over Slack, the marginal cost to the company (and to Slack) is essentially zero. Companies often pay per-seat license fees or volume of storage fees, but increased usage by those paid seats over their paid storage is effectively free.
- Benefit from demand-driven network effects. Once you have onboarding, training, and enablement resources in place, adding more users decreases their marginal cost. (Even per-seat licenses are often discounted as your number of users scales.) On the supply-side, often apps integrate to the aggregator service — e.g., all the apps that integrate to Slack or Snowflake — at no cost to either the aggregator or the company using that service. At the same time, the more users and the more integrations you have through the aggregator service, the more value you unlock.
As with Internet-scale aggregation theory, there are subtleties with these costs and network effects that cause some aggregators to be stronger than others. But in broad strokes, it seems like most products gaining ground as a canonical service in a company’s heterogeneous tech stack are likely benefiting from aggregation theory.
Now, that’s looking at it from the perspective of aggregation within a company’s stack.
It’s also likely that many products — but not all — that are aggregators within individual stacks are also aggregators within the larger market for their capability. It really depends on if they’re able to achieve network effects across customers.
Continuing with our example of Slack, because so many different apps integrate with Slack, Slack becomes more attractive to companies to adopt. In turn, that larger user base attracts even more apps to integrate, and so on. The marginal cost for Slack to have an app build an integration to them — and then deliver that value to customers — is zero.
Of course, this makes them a more dominant aggregator inside an individual stack too.
And it’s a pretty direct illustration of why integration = aggregation.
