Platform Liquidity: Why Economic Incentives Matter
Platform Liquidity: Why Economic Incentives Matter

The economic incentives of a platform determine its liquidity barriers — but they also create long-term trade-offs with the effectiveness of developer marketing programs Sameer Singh Follow Oct 5, 2020 · 6 min read

Image credit: Unsplash

Network effects can only take hold when a product has reached a minimum threshold or critical mass of users (also called liquidity) — this is true for marketplaces, interaction networks, and data networks. Platforms, on the other hand, are unique because they are always built on top of another product with existing adoption. So, as we saw with SaaS-enabled marketplaces, it is natural to assume that platforms can leverage these existing customers to attract a critical mass of developers. Wouldn’t they have liquidity right from the get-go? Not always.

Platforms are a combination of four elements — an underlying product, a development framework, a storefront to “match” users with apps, and an economic benefit for developers. Thanks to the underlying product (and existing customers), fledgling platforms already have a critical mass of demand. As a result, liquidity is purely a function of supply, i.e. developer adoption. This is driven by their economic incentive which varies based on the type of platform in question. I previously identified two types of platforms, each of which creates different economic incentives for developers, leading to different liquidity dynamics:

Type A: Focused platforms with integrations (weak defensibility & scalability) Type B: Multi-purpose platforms with native apps (strong defensibility & scalability)

Type A: Focused Platforms with Integrations

On Type A platforms, developer programs are created to complement the underlying product. The use cases of this product are already well defined and this lowers the barrier for developer adoption — developers merely need to cater to existing behavior, not discover new needs. As a result, the platform is initially adopted by professional developers of complementary apps, who often have significant user overlap with the platform owner.

Take Slack as an example. Slack began its journey as a simple collaboration and messaging tool for teams and businesses. After growing rapidly, it announced a developer platform and app directory in 2015. At launch, Slack’s app directory had 150 apps including Dropbox and Airtable. Both Dropbox and Airtable were used by teams to enhance collaboration — they addressed needs that were complementary to Slack. As a result, they had a significant number of shared users. This created an opportunity for companies like Dropbox and Airtable — they could improve engagement and retention by making it easier to use their products on Slack. This was their economic incentive.

This economic incentive makes it very easy to reach liquidity. Since professional developers simply want to cater to existing product users in new contexts, the case for adopting the platform becomes obvious. As a result, Type A platforms like Slack, Zoom, and even Figma are liquidity inclined. This is true as long as the user base of the underlying product is large enough and has a meaningful overlap with products from third-party developers.

Type B: Multi-Purpose Platforms with Native Apps

On the other hand, Type B platforms are much more complex to create because there is no blueprint for developers to build apps. The role of developers is to experiment and discover new use cases for the platform. Professional developers will only create new apps from scratch if they have confidence that their investments will pay off. And without a track record of direct monetization, new platforms are a major financial risk. So unlike Type A platforms, Type B platforms face a variation of the “cold start problem” — they cannot attract professional developers without traction, but they cannot build traction without developers. This is why Type B platforms always begin by reaching out to “hobbyists” first — per Slashdata, this includes student developers or those who code as a hobby.

Shopify is a great example of this. Its underlying product helped retailers and other sellers create online stores. As it grew, it launched its app store in 2009 to help customers address needs that Shopify could not cater to itself. However, there were hardly any popular apps in this space. As a result, Shopify needed developers to create new apps for its platform — a challenging task without a track record. So Shopify first attracted hobbyist developers like Mapify (order tracking & store locator) and Fetch (digital product delivery). Initially, these developers had no overarching economic incentive (beyond status) — they were just experimenting with the capabilities of Shopify’s platform. But as they experienced success and developed revenue models, they became professionals. Shopify enabled them to generate revenue and build new businesses. This economic incentive then attracted other professional developers like Yotpo, setting the flywheel in motion.

The economic incentive here is less straightforward for new platforms to capitalize on — in other words, Type B platforms are liquidity challenged. As a result, they are forced to take the “scenic route” to build liquidity — attract hobbyist developers first to prove traction and then go after professional developers. Smartphone platforms like iOS and Android are also good examples here — with game developers like Rovio playing the role of hobbyists turned pros.

The Platform Matrix: Economic Incentives and Developer Marketing

The dominant economic incentive has a significant impact on key KPIs and the way platforms market themselves to developers — even after liquidity is achieved.

Direct monetization is not an important consideration for Type A platforms. Instead, platforms like Slack, Zoom, and Figma highlight interoperability and UX advantages for developers to better cater to their own users. This makes it difficult to establish clear KPIs to promote the platform. As a result, their developer marketing efforts tend to be nebulous, relying on the traction of the underlying product and developer adoption. So even though it is easier for Type A platforms to achieve liquidity, they can be challenging to promote beyond a point.

On the other hand, developer revenue is a critical KPI for Type B platforms. This is the metric developers use to evaluate the potential payoff from creating new apps for a platform. As a result, platforms like Shopify, Salesforce, iOS, and Android (+Google Play) report developer earnings publicly and advertise new businesses they have enabled. The propensity to report developer earnings can be considered to be one of the strongest indicators of a successful Type B platform. Also, clear success metrics make their developer marketing initiatives much more effective. So even though Type B platforms may be liquidity challenged in their early days, they are much easier to promote once that barrier has been cleared.

To summarize, the economic incentive innate to a platform is the primary factor that determines liquidity barriers. Startups building platforms with known use cases (Type A) can easily reach liquidity by targeting developers who already share users with them. On the other hand, startups building truly multi-purpose platforms (Type B) have a more difficult path to liquidity — they need to attract hobbyists first to show some traction before they can appeal to professional developers. While this can be challenging, there is a payoff at the end — the monetization metrics that help you reach liquidity also help power the flywheel to further growth.
['Sameer Singh']
['Platform', 'Venture Capital', 'Technology', 'Startup', 'Business']