Chris Dixon

A platform is a technology or product upon which many other technologies or products are built. Some platforms are controlled by a single corporation: e.g. Windows, iOS, and Facebook. Some are controlled by standards committees or groups of companies: e.g. the web (html/http), RSS, and email (smtp).

Platforms succeed when they are 1) financially sustainable, and 2) have a sufficient number of developers that are financially sustainable. Fostering a successful developer community means convincing developers (and, possibly, investors in developers) that the platform is a worthwhile investment of time and money.

Developers who create applications for platforms take on all the usual risks related to launching a new product, but in addition take on platform-specific risks, namely:

1. Platform decline: the platform will decline or go away entirely.
2. Subsumption risk: the platform will subsume the functionality of the developer’s application.

The most successful platforms try to mitigate these risks for developers (not just the appearance of these risks). One way to mitigate platform decline risk is to launch the platform after the platform’s core product is already successful, as Facebook did with its app platform and Apple did with its iOS platform. Platforms that are not yet launched or established can use other methods to reassure developers; for example, when Microsoft launched the first Xbox they very publicly announced they would invest $1B in the platform.

To mitigate subsumption risk, the platform should give developers predictability around the platform’s feature roadmap. Platforms can do this explicitly by divulging their product roadmap but more often do it implicitly by demonstrating predictable patterns of feature development. Developers and investors are willing to invest in the iOS platform because – although Apple will take 30% of the revenue – it is highly unlikely that Apple will, say, create games to compete with Angry Birds or news to compete with The New York Times. Similarly, Facebook has thus far stuck to “utility” features and not competed with game makers, dating apps, etc.

Platforms that are controlled by for-profit businesses that don’t yet have established business models have special challenges. These companies are usually in highly experimental modes and therefore probably themselves don’t know their future core features. The best they can do to mitigate developers’ risks are 1) provide as much guidance as possible on future features, and 2) when developer subsumption is necessary, do so in a way that keeps the developer ecosystem financially healthy – for example, by acquiring the subsumed products.

The least risky platforms to develop on are successful open platforms like the web, email, and Linux. These platforms tend to change slowly and have very public development roadmaps. In the rare case where a technology is subsumed by an open platform, it is usually apparent far in advance. For example, Adobe Flash might be subsumed by the canvas element in HTML5, but Adobe had years to see HTML5 approaching and adjust its strategy accordingly. The predictability of open platforms is the main reason that vast amounts of wealth have been created on top of them and investment around them continues unabated.

Establishing relationships with new users is the hardest part of growing a startup.  For consumer products establishing relationships can mean many things: installs, registrations, purchases, or even just getting users to think of your website as a place to go for certain purposes.  For B2B products, establishing relationships means getting internal users or testers and eventually contracts and payments. For business development partners – for example API/widget partners – establishing relationships usually means getting functionality embedded in partners’ products (e.g. a widget on their website).

One common strategy for establishing this initial relationship is what is sometimes known as the “thin edge of the wedge” strategy (aka the “tip of the spear” strategy).  This strategy is analogous to the bowling pin strategy: both are about attacking a smaller problem first and then expanding out.  The difference is that the wedge strategy is about product tactics while the bowling pin strategy is about marketing tactics.

Sometimes the wedge can be a simple feature that existing companies overlooked or saw as inconsequential. The ability to share photos on social networks was (strangely) missing from the default iPhone camera app (and sharing was missing from many third-party camera apps like Hipstimatic that have popular features like lo-fi camera filters), so Instagram and Picplz filled the void. Presumably, these startups are going to try to use mobile photo sharing as the wedge into larger products (perhaps full-fledged social networks?).

Sometimes the wedge is a “single player mode” – a famous example is early adopters who used Delicious to store browser bookmarks in the cloud and then only later – once the user base hit critical mass – used its social bookmarking features. Other times the wedge lies on one side of a two-sided market, in which case the wedge strategy could be thought of as a variant of the “ladies night” strategy. I’m told that OpenTable initially used the wedge strategy by providing restaurants with terminals that acted like simple, single-player CRM systems. Once they acquired a critical mass of restaurants in key cities (judiciously chosen using the bowling pin strategy), opentable.com had sufficient inventory to become useful as a one-stop shop for consumers.

Critics sometimes confuse wedge features with final products. For example, some argue that mobile photo sharing is “just a feature,” or that game mechanics on geo apps like Foursquare are just faddish “toys.” Some go so far as to argue that the tech startup world as a whole is going through a phase of just building “dinky” features and companies. Perhaps some startups have no plan and really are just building features, likely with the hope of flipping themselves to larger companies. Good startups, however, think about the whole wedge from the start. They build an initial user base with simple features and then quickly iterate to create products that are enduringly useful, thereby creating companies that have stand-alone, defensible value.

Google recently added a caustic warning message when users attempt to export their Google Contacts to Facebook:

Hold on a second. Are you super sure you want to import your contact information for your friends into a service that won’t let you get it out?

Facebook allows users to download their personal information (photos, profile info, etc) but has been fiercely protective of the social graph (you can’t download friends, etc). The downloaded data arrives in a .zip file – hardly a serious attempt to interoperate using modern APIs (update: Facebook employee corrects me/clarifies in comments here). In contrast, Google has taken an aggressively open posture with respect to the social graph, calling Facebook’s policy “data protectionism.”

The economic logic behind these positions is a straightforward application of Metcalf’s law, which states that the value of a network is the square of the number of nodes in the network*.  A corollary to Metcalf’s law is that when two networks connect or interoperate the smaller network benefits more than the larger network does. If network A has 10 users then according to Metcalf’s law its “value” is 100 (10*10).   If network B has 20 users than it’s value is 400 (20*20). If they interoperate, network A gains 400 in value but network B only gains 100 in value. Interoperating is generally good for end users, but assuming the two networks are directly competitive – one’s gain is the other’s loss – the larger network loses.

A similar network interoperability battle happened last decade among Instant Messaging networks. AIM was the dominant network for many years and refused to interoperate with other networks. Google Chat adopted open standards (Jabber) and MSN and Yahoo were much more open to interoperating. Eventually this battle ended in a whimper — AIM never generated much revenue, and capitulated to aggregators and openness.  (Capitulating was probably a big mistake – they had the opportunity to be as financially successful as Skype or Tencent).

Google might very well genuinely believe in openness. But it is also strategically wise for them to be open in layers that are not strategic (mobile OS, social graph, Google docs) while remaining closed in layers that are strategic (search ranking algorithm, virtually all of their advertising services).

When Google releases their long-awaited new social network, Google Me, expect an emphasis on openness. This could create a rich ecosystem around their social platform that could put pressure on Facebook to interoperate. True interoperability would be great for startups, innovation, and – most importantly – end users.

* Metcalf’s law assumes that every node is connected to every node and each connection is equally valuable. Real world networks are normally not like this. In particular, social networks are much more clustered and therefore have somewhere between linear and exponential utility growth with each additional user.

Many singles bars have “ladies’ night” where women are offered price discounts. Singles bars do this for women but not for men because (heterosexually-focused) bars are what economists call two-sided markets – platforms that have two distinct user groups and that get more valuable to each group the more the other group joins the platform - and women are apparently harder to attract to singles bars than men.

Businesses that target two-sided markets are extremely hard to build but also extremely hard to compete against once they reach scale. Tech businesses that have created successful two-sided markets include Ebay (sellers and buyers), Google (advertisers and publishers), Paypal (buyers and merchants), and Microsoft (Windows users and developers). In some cases individuals/institutions are consistently on one side (buyers and merchants) while in other cases they fluctuate between sides (Ebay sellers are also often buyers).

In almost every two-sided market, one side is harder to acquire than the other. The most common way to attract the hard side is the ladies’ night strategy: reduce prices for the hard side, even to zero (e.g. Adobe Flash & PDF for end-users), or below zero (e.g. party promotors paying celebrities to attend). Rarer ways to attract the hard side is 1) getting them to invest the platform itself (e.g. Visa & Mastercard), and 2) interoperating with existing hard sides (e.g. Playstation 3 running Playstation 2 games).

If you are starting a company that targets a two-sided market you need to figure out which side is the hard side and then focus your efforts on marketing to that side. Generally, the more asymmetric your market the better, as it allows you to market to each side more in serial than in parallel.

One of the most important developments of the web 2.0 era is the proliferation of full featured, bidirectional APIs.  APIs provide a way to “federate” web services from a single website to a distributed network of 3rd party sites. Another important web 2.0 development is the proliferation of web Apps (e.g. Facebook Apps). Apps provide a way to make websites “extensible.”

The next step in this evolution is to create web services that are both federated (APIs) and extensible (Apps).

In my ideal world, the social graph would not be controlled by a private company. That said, Facebook, to its credit, has aggressively promoted a fairly open API through Facebook Connect. Facebook has also been a leader in promoting Apps. For Facebook, creating extensible, federated services would mean providing a framework for Facebook Connect Apps – apps that extend Facebook functionality but reside on non-Facebook.com websites.

Consider the following scenario.  Imagine that in the future a geolocation data/algorithm provider like SimpleGeo takes Facebook Places check-in data and, using algorithms and non-Facebook data, produces new data sets, for example: map directions, venue recommendations, and location-based coupons. The combination of Facebook’s data (social graph and check-ins) and SimpleGeo data/algorithms would create much more advanced feature possibilities than either service acting alone.

With today’s APIs, if, say, Gowalla wanted to integrate Facebook plus SimpleGeo into their app*, they would basically have 3 choices:

1) Embed Facebook widgets in Gowalla.  These are simple iframes (effectively separate little websites) that don’t interact with SimpleGeo.  Gowalla would just have to sit and wait and hope that Facebook decided to bake in SimpleGeo-like functionality.

2) Pre-import SimpleGeo data. This significantly limits the size and dynamism of the SimpleGeo data sets and doesn’t incorporate SimpleGeo algorithms, thus severely limiting functionality.

3) Host an instance of SimpleGeo’s servers internally.  This requires heavy technical integration, undermining the main benefit of APIs.

In a world of extensible APIs (or “API Apps”), Gowalla could instead send Facebook data back to SimpleGeo.  The data flow would look something like this:

(Note how there are three parties involved – @peretti calls this a “data threesome”). This configuration is much simpler to integrate – and potentially much more powerful and dynamic – than the other configurations listed above.  You could implement this today, but it would create user experience challenges.  For example, Gowalla would be sending Facebook data to a 3rd party (step 3), which might (depending on the data sent) require explicit user opt-in. Things become more onerous if SimpleGeo wanted to share its own user data with Gowalla. That would require an additional oAuth to SimpleGeo (authorizing step 4).

Allowing websites to be federated and extensible will open up a whole new wave of innovation.  Ideally some spec like oAuth could include the multiple authorizations in a single authorization screen.  Facebook could also do this by allowing 3rd parties to be part of the Facebook Connect authorization process.  Inasmuch as Facebook’s seems to be trying to embed their social graph as deeply as possible into the core experiences of other websites, allowing extensible APIs would seem to be a smart move.

* I have no connection to any of these companies (Facebook, Gowalla, SimpleGeo) and have no knowledge of their product plans beyond their public websites.  I am imagining functionality that Gowalla and SimpleGeo might include someday but for all I know they have no interest in these features – I just picked them somewhat arbitrarily as examples.

A few successful websites were built almost entirely through viral growth. The vast majority, however, started off by partnering with other, already successful websites. Even Google began by partnering with Yahoo. As superior as Google’s search algorithm was, it was very hard to get the masses to switch to a new search engine.

In the web 1.0 world (approximately pre-2004), integrating two web services involved lots of manual work, such as negotiating legal contracts and custom technical integration. Creating these kinds of partnerships is usually referred to as “business development” or “BizDev” (personally, I usually just call it “BD”). In the web 2.0 world, it became common for websites to create fully functional, self-service API’s with standardized legal terms. This made it possible to drastically reduce the friction of integrating services. My Hunch cofounder Caterina Fake coined the term “BizDev 2.0″ to refer to this idea (and of course Flickr was a pioneer of super robust APIs).

There is no question that removing legal and technical hurdles is a win for everyone (except lawyers). However, unless your service is extremely high profile and its value is easily understood, it still needs to be marketed to potential partners. Many websites won’t consider using a self-service API until they’ve seen it working on other sites with measurable results. So how do you overcome this particular kind of chicken-and-egg problem?

During his interview process, Hunch’s Shaival Shah, said something that struck a chord with me: he didn’t want to be called “VP BizDev” because, he said, a good BizDev person makes BizDev irrelevant. The idea is to create a number of BizDev 1.0 partnerships while simultaneously building and marketing a full service API.  If you can do BizDev 1.0 with some number of (ideally high profile) websites and demonstrate that it is valuable to them (ideally quantitatively), you can then scale your service BizDev 2.0 style. Maybe this could be called BizDev 1.5.

Shaival wrote up a much more detailed post on self-cannibalizing BizDev that is well worth reading.

A huge challenge for user-generated websites is overcoming the chicken-and-egg problem: attracting users and contributors when you are starting with zero content. One way to approach this challenge is to use what Geoffrey Moore calls the bowling pin strategy: find a niche where the chicken-and-egg problem is more easily overcome and then find ways to hop from that niche to other niches and eventually to the broader market.

Facebook executed the bowling pin strategy brilliantly by starting at Harvard and then spreading out to other colleges and eventually the general public.  If Facebook started out with, say, 1000 users spread randomly across the world, it wouldn’t have been very useful to anyone.  But having the first 1000 users at Harvard made it extremely useful to Harvard students.  Those students in turn had friends at other colleges, allowing Facebook to hop from one school to another.

Yelp also used a bowling pin strategy by focusing first on getting critical mass in one location – San Francisco – and then expanding out from there.  They also focused on activities that (at the time) social networking users favored: dining out, clubbing and shopping. Contrast this to their direct competitors that were started around the same time, were equally well funded, yet have been far less successful.

How do you identify a good initial niche?  First, it has to be a true community – people who have shared interests and frequently interact with one another.  They should also have a particularly strong need for your product to be willing to put up with an initial lack of content. Stack Overflow chose programmers as their first niche, presumably because that’s a community where the Stack Overflow founders were influential and where the competing websites weren’t satisfying demand. Quora chose technology investors and entrepreneurs, presumably also because that’s where the founders were influential and well connected. Both of these niches tend to be very active online and are likely to have have many other interests, hence the spillover potential into other niches is high. (Stack Overflow’s cooking site is growing nicely – many of the initial users are programmers who crossed over).

Location based services like Foursquare started out focused primarily on dense cities like New York City where users are more likely to serendipitously bump into friends or use tips to discover new things. Facebook has such massive scale that it is able to roll out its LBS product (Places) to 500M users at once and not bother with a niche strategy.  Presumably certain groups are more likely to use Facebook check-ins than others, but with Facebook’s scale they can let the users figure this out instead of having to plan it deliberately. That said, history suggests that big companies who rely on this “carpet bombing strategy” are often upended by focused startups who take over one niche at a time.

Your #1 competitor starting out will always be the BACK button, nothing else. – Garry Tan

Suppose you have an idea for a startup, and then do some research only to discover there are already similar products on the market. You become disheartened and wonder if you should abandon your idea.

In fact, the existence of competing products is a meaningful signal, but not necessarily a negative one.  Here are some things to consider.

1) Almost every good idea has already been built. Sometimes new ideas are just ahead of their time. There were probably 50 companies that tried to do viral video sharing before YouTube. Before 2005, when YouTube was founded, relatively few users had broadband and video cameras. YouTube also took advantage of the latest version of Flash that could play videos seamlessly.

Other times existing companies simply didn’t execute well. Google and Facebook launched long after their competitors, but executed incredibly well and focused on the right things. When Google launched, other search engines like Yahoo, Excite, and Lycos were focused on becoming multipurpose “portals” and had de-prioritized search (Yahoo even outsourced their search technology).

2) The fact that other entrepreneurs thought the idea was good enough to build can be a positive signal. They probably went through some kind of vetting process like talking to target users and doing some market research. By launching later, you can piggyback off the work they’ve already done. That said, you do need to be careful not to get sucked into groupthink. For example, many techies follow the dictum “build something you would use yourself,” which leads to a glut of techie-centric products. There are tons Delicious and Digg clones even though it’s not clear those sites have appeal beyond their core techie audience.

3) That other people tried your idea without success could imply it’s a bad idea or simply that the timing or execution was wrong. Distinguishing between these cases is hard and where you should apply serious thought. If you think your competitors executed poorly, you should develop a theory of what they did wrong and how you’ll do better. Group buying had been tried a hundred times, but Groupon was the first to succeed, specifically by using coupons to track sales and by acquiring the local merchants first and then getting users instead of vice versa. If you think your competitor’s timing was off, you should have a thesis about what’s changed to make now the right time. These changes could come in a variety of forms: for example, it could be that users have become more sophisticated, the prices of key inputs have dropped, or that prerequisite technologies have become widely adopted.

Startups are primarly competing against indifference, lack of awareness, and lack of understanding — not other startups. For web startups this means you should worry about users simply not coming to your site, or when they do come, hitting the BACK button.

With the introduction of the iPhone, Steve Jobs achieved something that might be unique in the history of business: he single-handedly upended the power structure of a major industry.  In the US, before the iPhone, the carriers (Verizon, AT&T, Sprint, T-Mobile) had an ironclad grip on the rest of the value chain – particularly, handset makers and app makers.

Ask anyone who ran or invested in a mobile app startup pre-iPhone (I invested in one myself). Since the carriers had all the power, getting any distribution (which usually meant getting on the handset “deck”) meant doing a business development deal with the carriers. Business development in this case meant finding the right people at those companies, sending them iPods, taking them to baseball games, and basically figuring out ways to convince them to work with you instead of the 5,000 other people sending them iPods and baseball tickets.  The basis of competition was salesmanship and capital, not innovation or quality.

The carriers had so much power because consumers made their purchasing decisions by choosing a carrier first and a handset second. Post-iPhone, tens of millions of people started choosing handsets over carriers. People like me suffer through AT&T’s poor service and aggressive pricing because I love the iPhone so much.

I’ve talked to a number of mobile app startups lately who say their former contacts at the carriers are shell shocked: no one is knocking on their doors anymore. I guess they have to buy their own iPods and baseball tickets now.

Yes, Apple has rejected some apps for seemingly arbtrary or selfish reasons and imposed aggressive controls on developers. But the iPhone also paved the way for Android and a new wave of handset development. The people griping about Apple’s “closed system” are generally people who are new to the industry and didn’t realize how bad it was before.

The brewing fight between Facebook and Zynga is what is known in economic strategy circles as “buyer-supplier hold up.” The classic framework for analyzing a firm’s strategic position is Michael Porter’s Five Forces. In Porter’s framework, Zynga’s strategic weakness is extreme supplier concentration – they get almost all their traffic from Facebook.

It is in Facebook’s economic interest to extract most of Zynga’s profits, leaving them just enough to keep investing in games and advertising. Last year’s reduced notification change seemed like one move in this direction as it forced game makers to buy more ads instead of getting traffic organically. This probably hurt Zynga’s profitability but also helped them fend off less well-capitalized rivals. Facebook could also hold up Zynga by entering the games business itself, but this seemed unlikely since thus far Facebook has kept its features limited to things that are “utility like.”

The way Facebook now seems to be holding up Zynga – requiring Zynga to use their payments system –  is particularly clever.  First, payments are still very much a “utility like” feature, and arguably one that benefits the platform, so it doesn’t come across as flagrant hold up. It is also clever because – assuming Facebook has insight into Zynga’s profitability – Facebook can charge whatever percentage gets them an optimal share of Zynga’s profits.

The risk for Zynga is obvious — if they don’t diversify their traffic sources very soon, they are left with a choice between losing profits and losing their entire business.  But there is a risk for Facebook as well. If buyers of traffic (e.g. app makers) fear future hold up, they are less likely to make investments in the platform. The biggest mistake platforms make isn’t charging fees (Facebook) or competing with complements (Twitter), it’s being inconsistent.  Apple also charges 30% fees but they’ve been mostly consistent about it. App makers feel comfortable investing in the Apple platform and even having most of their business depend on them in a way they don’t on Facebook or Twitter.