Yours is a way more nuanced view, but FWIW I have always basically thought there are two types of valuable platforms – distribution platforms and infrastructure platforms. I actually think Ben Thompson's whole aggregator framework here is useful, as distribution platforms aggregate consumers and infrastructure platforms aggregate developers.
In a distribution platform, businesses fundamentally adopt the platform for distribution. You have built a product that has captured a valuable-enough audience that other businesses want to integrate with you to serve that audience. Examples:
- iOS. No one would care about the iOS platform if it had 100k users. I'm sure some people like Swift and Objective C, but the real reason you build iOS apps is because the iPhone has a billion+ users globally.
- Facebook (circa 2007-2012). Facebook was the largest, fastest-growing app in the world. We let people access that audience.
- Android, Windows, Xbox, Playstation ... most hardware products.
I had never thought of SAP but I think SAP and Salesforce are examples of this, too – they have enough customers out there that other businesses would rather just build on top of this and co-sell/distribution with them then start from scratch.
Infrastructure platforms in my mind are things that make a developers job and time-to-market substantially easier (e.g., AWS). I think the dividing line between product and platform here is hazier, but I think an infrastructure product starts to become a platform when a large part of the value of the platform comes from the fact that other developers use it and that connective tissue bleeds into all kinds of other systems.
The end user typically has no idea what infrastructure platform you're using and doesn't care (they don't know if you're using AWS vs. GCP or Stripe vs. Adyen and don't care).
Common mistakes I've seen:
1/ Trying to build a distribution platform from day one. Developers will only care about a distribution platform if you have distribution, which in almost all cases requires having a great product that lots of people are actively using (ideally 10s or 100s of millions). This is one of the reasons that not having an App Store was arguably a feature, not a bug, of iOS v1.
2/ Being confused about what kind of platform you are. Distribution platforms should aspire to good APIs and developer experience, but they should be clear-eyed about the fact that developers aren't picking them because of the quality of their API or technology but based on maximal relevant reach. A Twitter competitor isn't going to win because of a better API. MacOS wouldn't have beaten Windows in the late 90s with a 10x better API.
To your point about paradigm shifts, I think the fundamental reason they are vulnerable is that the most visible platforms are distribution platforms (they aggregate consumers) and paradigm shifts are almost ipso facto shifts in consumer behavior and aggregation. E.g., Linux and Windows are still exceptionally relevant as operating systems and the dominant environment in which software runs, but their importance as chokepoints for consumer demand are massively diminished.
You raise a perfectly valid split of platforms. I was trying to get at the core question of “what to build” and especially what to build you’re making an infrastructure (which I called technology) platform. I find in talking to people embarking on a “platform strategy” or “platform play” that the specifics of what to build represent the core questions.
At least for me I’ve always found the notion of “aggregator” a bit of an after-the-fact framework akin to declaring a moat to be a strategy. I also tend to think that at some level (which many might disagree with me) almost every business aggregates and that this is really a disintermediation strategy. Enterprise software is almost always an aggregation of some combination of horizontal features or vertical players. At the consumer level you see the same thing all the time—Walmart might be viewed as a distribution play but it also aggregates what was essentially a mall and charges rents to appear (banking, optometrist). Beyond that, I do think that the key “aggregators” are really enterprise software companies selling advertising platforms and much of the platform technology follows the framework I offered up—AdCenter, Analytics, etc. are each platforms (via UX, API, H&V, etc.) and have all the associated positives and negatives. They are the business and infrastructure no one talks about :-)
It is, arguably, too easy to have a semantic battle or debate the arrows and boxes, which is why I try to just go a level down and get concrete about what I mean :-)
Yours is a way more nuanced view, but FWIW I have always basically thought there are two types of valuable platforms – distribution platforms and infrastructure platforms. I actually think Ben Thompson's whole aggregator framework here is useful, as distribution platforms aggregate consumers and infrastructure platforms aggregate developers.
In a distribution platform, businesses fundamentally adopt the platform for distribution. You have built a product that has captured a valuable-enough audience that other businesses want to integrate with you to serve that audience. Examples:
- iOS. No one would care about the iOS platform if it had 100k users. I'm sure some people like Swift and Objective C, but the real reason you build iOS apps is because the iPhone has a billion+ users globally.
- Facebook (circa 2007-2012). Facebook was the largest, fastest-growing app in the world. We let people access that audience.
- Android, Windows, Xbox, Playstation ... most hardware products.
I had never thought of SAP but I think SAP and Salesforce are examples of this, too – they have enough customers out there that other businesses would rather just build on top of this and co-sell/distribution with them then start from scratch.
Infrastructure platforms in my mind are things that make a developers job and time-to-market substantially easier (e.g., AWS). I think the dividing line between product and platform here is hazier, but I think an infrastructure product starts to become a platform when a large part of the value of the platform comes from the fact that other developers use it and that connective tissue bleeds into all kinds of other systems.
The end user typically has no idea what infrastructure platform you're using and doesn't care (they don't know if you're using AWS vs. GCP or Stripe vs. Adyen and don't care).
Common mistakes I've seen:
1/ Trying to build a distribution platform from day one. Developers will only care about a distribution platform if you have distribution, which in almost all cases requires having a great product that lots of people are actively using (ideally 10s or 100s of millions). This is one of the reasons that not having an App Store was arguably a feature, not a bug, of iOS v1.
2/ Being confused about what kind of platform you are. Distribution platforms should aspire to good APIs and developer experience, but they should be clear-eyed about the fact that developers aren't picking them because of the quality of their API or technology but based on maximal relevant reach. A Twitter competitor isn't going to win because of a better API. MacOS wouldn't have beaten Windows in the late 90s with a 10x better API.
To your point about paradigm shifts, I think the fundamental reason they are vulnerable is that the most visible platforms are distribution platforms (they aggregate consumers) and paradigm shifts are almost ipso facto shifts in consumer behavior and aggregation. E.g., Linux and Windows are still exceptionally relevant as operating systems and the dominant environment in which software runs, but their importance as chokepoints for consumer demand are massively diminished.
Thank you for your insightful comments.
You raise a perfectly valid split of platforms. I was trying to get at the core question of “what to build” and especially what to build you’re making an infrastructure (which I called technology) platform. I find in talking to people embarking on a “platform strategy” or “platform play” that the specifics of what to build represent the core questions.
At least for me I’ve always found the notion of “aggregator” a bit of an after-the-fact framework akin to declaring a moat to be a strategy. I also tend to think that at some level (which many might disagree with me) almost every business aggregates and that this is really a disintermediation strategy. Enterprise software is almost always an aggregation of some combination of horizontal features or vertical players. At the consumer level you see the same thing all the time—Walmart might be viewed as a distribution play but it also aggregates what was essentially a mall and charges rents to appear (banking, optometrist). Beyond that, I do think that the key “aggregators” are really enterprise software companies selling advertising platforms and much of the platform technology follows the framework I offered up—AdCenter, Analytics, etc. are each platforms (via UX, API, H&V, etc.) and have all the associated positives and negatives. They are the business and infrastructure no one talks about :-)
It is, arguably, too easy to have a semantic battle or debate the arrows and boxes, which is why I try to just go a level down and get concrete about what I mean :-)
I think "technology platform" is a much better name than "infrastructure platform" so I will adopt it. :)