I seems like every self-respecting entrepreneur these days is building a platform, not a product.
Many (but certainly not all) of these “platform” aspirants are smart enough to understand that most true platforms (think Facebook, iOS, Android) didn’t start out that way.
Platforms tend to emerge in one of two ways:
EITHER: a disruptive new service (e.g. Facebook, Twitter) achieves massive adoption by end-users, and then opens itself to developers to accelerate innovation on behalf of its users.
OR: An incumbent player with a massive existing installed base (e.g., Apple with iTunes, Google with Gmail, Maps + Search, Amazon with its services architecture) leverages that base to offer developers instant distribution via a new platform technology (e.g., iOS, Android, AWS).
But there are just enough exceptions to this rule — think Heroku for Rails developers, Urban Airship for mobile messaging, Twilio in telephony, GitHub for software development, Etsy for e-commerce — where a startup actually succeeds in becoming a platform worthy of the name, feeding the dreams of ambitious entrepreneurs who believe they can beat the odds.
Platforms + Reference Apps
Unlike the incumbent players that start out with a big installed base, these aspiring platforms start out empty of both users and applications. Bootstrapping a customer community is brutally hard, and many entrepreneurs are too aggressive, and too impatient, to wait for adoption to come.
To demonstrate the capabilities of their new platform, the founders often choose to create one or more “reference apps” — specific (vertical) implementations that shine a light on the platform’s general (horizontal) capabilities. If the team doesn’t handle this well, their “reference app” effort can create dangerous confusion among customers, core team members and potential investors.
Startups are resource-constrained at the best of times, never more so than when they’re just starting out. The more “real” their reference app is, the more resources it consumes — resources that aren’t being invested in extending the core platform.
In the most extreme cases, the company finds itself “competing at right angles” — trying to win on both the vertical (app) and horizontal (platform) axes simultaneously.
Instead of focusing on the big bet, the team is forced to fight on two fronts. This rarely turns out well.
This predicament resolves itself in one of three ways:
- Company fails — instead of nailing one important thing, the team fragments its efforts and underperforms at two, with predictable results. (This is the default case whenever a team’s attention is split)
- Platform wins — the team keeps the reference app in perspective (a demo, not a product) and leans in on delighting platform users. (Twilio provided a set of open-source demo apps at launch, but was crystal clear about not putting itself in competition with its developer community).
- App wins — in a few examples I can think of (Z2Live here in Seattle is a notable one), the reference app becomes the business, and the platform effort is abandoned in favor of the surprise hit.
- Over-communicate — make it abundantly clear to team members, platform customers and investors that your reference apps are that and nothing more, so no reasonable person can misinterpret your intent.
- Under-resource — Don’t let your reference designs take on the status of “real” products or you’ll undermine credibility (and mis-allocate scarce resources).
- Open-source — the best way to prove that your reference designs are nothing more is to give away the source code to your developer community.
- Partner with customers — instead of creating your own reference apps, work with a few early-adopter customers to create showcase apps that demonstrate the capabilities of the platform, but aren’t controlled or maintained by your team.