Framework 1: Infrastructure or App?
Entrepreneur Elad Gil writes that conflating ideas of application, platform, and infrastructure “can backfire and cause a team to have the wrong strategy for building a product or getting customers." Elad advises that — at the start — companies should choose either an infrastructure strategy or an app strategy.
What’s the difference? Elad explains that infrastructure products are necessary for a customer’s own product to function. They have clear economies of scale and, at least at the beginning, are easily commoditizable. In his example, “Early on, many users of Twilio didn’t care if they were using Twilio or another telephony provider — they just want it to work quickly, simply, at a good price." In other words: pipes are pipes.
A vertical app strategy is very different. (Note: by “vertical" app I mean an app intentionally built on a platform layer with APIs for extensibility later on.) Successful vertical apps lead way to platforms because they provide “proprietary, non-commodity data and/or distribution," that is not easily commoditizable. Elad writes: “If a developer tried to use another social product’s API (e.g. Foursquare) instead of Facebook’s, they would not get access to the right type of data or the same distribution." User trust and brand equity are important assets as well. This unique access, often through connection and trust from end users, belongs first to the app and then ultimately to the platform that spawns from it.
At Comfy, we are very clearly a vertical app. (A quick and dirty background: Comfy delivers enterprise clients a workplace app that connects into existing building/workplace systems to give occupants added control and transparency.) We have direct connection to our end users (employees) while capturing unique data (employee preference and behavior) with strategic access to distribution (system agnostic integrations).
Ultimately, both an app and an infrastructure play have the long-term opportunity to become a platform. But let’s not get ahead of ourselves. Becoming a platform first necessitates differentiation through unique data and/or access to distribution.
Framework 2: Multi-sided network… with what sides?
In Platform Revolution, the authors describe multi-sided networks as between two sides: the producer, the side that creates value, and the consumer, the side that consumes value. These sides exchange, you guessed it, a unit of value. For example, in Lyft’s multi-sided network, Drivers create rides,which is the value unit desired by Riders. This multi-sided network thrives and ultimately creates excess value by “reducing the friction and barriers that prevent producers and consumers from interacting."
Whether pursuing an app or infrastructure strategy, this multi-sided thinking is important. Apps that embrace a multi-sided network from the beginning need to ensure their product and distribution efforts match both sides. Infrastructure products that ultimately want to become platforms should also consider how this evolution will apply. Who are the producers? Who are the consumers? And what units of value will they exchange?
Add in another question — who pays in a multi-sided network? Sometimes, one side is willing to subsidize the other to participate on the platform. According to Platform Revolution, “this works when Users A highly value the opportunity to make contact with Users B, but the feeling is not reciprocated." A good example is Ladies’ Night. Non reciprocated feelings galore!
You wouldn’t think it on first glance, but Ladies’ Night demonstrates the same multi-sided scenario as Enterprise Productivity tools. In the enterprise scenario, Side A is the Employer and Side B, the Employee. The employer is willing to pay for the other side, the employee, to participate. Think of Zoom and Slack. The employer pays for their employees to participate on Zoom or Slack and in return, the employer receives a value unit of more productive, less burdensome work by its employees.
At Comfy, I find it useful to think of our multi-sided network in the following way. Employees provide a value unit of employee preference and behavior. It may be counterintuitive, but they are the suppliers in this scenario. Many of our customers are willing to subsidize their employees onto our vertical app because of the ROI received in operational savings and employee engagement. However, we believe that there’s *even more value* to be gained through exchange of the value unit. How can employers use richer, real-time information on employee preference and behavior to do their own jobs better? Facilitating this exchange of value is core to our success at scale.
To be clear, in the evolution from app/infrastructure to platform the value unit between sides can and will change. The sides themselves might even change! And equally susceptible to change is the *type* of value exchanged. In pure subsidized scenarios, often proof of ROI is sufficient. Can the employer justify the cost of getting their employees on the network? However, in scenarios where the employer reaps additional value from their employees participating on the network, simply demonstrating ROI misses out on much of the value capture available. In these cases, a startup will be smart to ensure that they are maximizing exchange of the value unit.
Framework 3: Aggregator or not?
Ben Thompson of Stratechery writes “Aggregation Theory describes how platforms (i.e. aggregators) come to dominate the industries in which they compete in a systematic and predictable way. Aggregation Theory should serve as a guidebook for aspiring platform companies."
According to Ben, non-aggregator platforms facilitate the interaction between 3rd parties and end users, often creating greater ecosystem value. In contrast, aggregator platforms intermediate end users and bundles of 3rd party services. This aggregator approach is most apt in a fragmented market. “Aggregators harvest already produced content or goods" as evidenced by these aggregators supreme: Netflix and Facebook.
Aggregator-applicable or not, Ben’s theory is useful *even if* you determine you don’t fit within the aggregator classification. It’s a useful framework to think about the demand vs. supply-side opportunities & constraints of your multi-sided network. (And, it’s useful regardless of whether you’re still a vertical app or if you’re already on your way to becoming a platform.)
So what does this theory look like? According to Ben, successful aggregators (1) own the end user relationship (2) have near-zero demand-side marginal costs, (3) have *some* supply-side marginal costs, and (4) use network effects to reduce acquisition costs. I’ve distilled his thinking into an easier-to-use framework below: