Platform Theories, Aggregated

Liz Voeller -

OR: How frameworks like Ladies’ Night helped me think about product & distribution strategy

When scaling a startup in what *feels* like a new category, it’s exciting to think that you’re doing things for the first time. Then — out of the blue — humility slaps you in the face and you remember: history offers patterns to learn from. As do other industries. And thoughtful people. We realize our challenges (and opportunities!) are not so unique after all.

Learnings culled from those who *share* their experiences compound into useful tools and frameworks to help us tackle our own. Things never apply 1:1, but these tools offer a WAY to think through current challenges and opportunities. A lot of what is faced is the same; our own puzzles just have different filters.

So that’s the goal of this piece: Share tools I have found most helpful in thinking through the digital product and distribution strategies of my own startup, Comfy. My hope is that others (especially my future self!) will find this next-step iteration of existing frameworks useful.

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.”

From Ben Thompson’s piece “The Cost of Developers“

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:

Framework to map out demand & supply-side impacts, a la Ben Thompson’s piece “Defining Aggregators“

So… now what? These frameworks are useful because they encourage us to continually ask these 5 questions:

1. Will we maintain connection to the right user as we scale? Are we entrenching access to unique data and/or distribution?

  • Do our plans for scale factor in maintaining the end user relationship (and what does this look like, operationally?) Do we have their trust?
  • Are we positioning ourselves for differentiated access to data/distribution?

2. Where does value accrue?

  • What type of value are we delivering: ROI proof to the customer, direct value exchanged between two sides, or value to reduce friction in getting players onto the platform?
  • Are we maximizing the exchange of the value unit?
  • How do we steer the ship so the right amount of value goes to the relevant constituencies?

3. Are we taking full advantage of network effects?

  • Do we understand the full range of network effects at our disposal?
  • Do we understand what limits prevent us from achieving this? (For example, are there location-specific bounds that impact the reach of network effects, say for Amazon Echo or Google Home?)

4. Are we prioritizing efforts to address our most scale-suppressing bottlenecks?

  • Are we focusing efforts to reduce marginal costs to serve demand-side users?

5. Do our organizational structure and internal communication channels map well to this framework?

  • Strategic efforts break down if organizational structure and communication channels are not aligned. For example, for products serving both customers and end users… are we set up to design, build, market, deliver, and maintain both sides?
  • Do we build in effective feedback loops for each side? For example, do we capture both #voiceofcustomer and also #voiceofuser?

I hope this iteration of frameworks, with my own filters applied, proves useful when considering digital product and distribution strategies for startups.

Something I didn’t mention earlier but feel important to add: Here at Comfy, we actually view our solution as cyberphysical (not just digital) for the built world. This adds additional layers of considerations. But more on those filters later…