Considerations in Designing a Developer Platform


The meteoric rise of developer platforms over the last seven years has been impressive to watch and a major boon to the social and mobile ecosystems. Twitter (API launched in 2006), Facebook (2007), and Apple iOS (2008) alone have spurred developers to build massive businesses on top of their platforms and simultaneously driven significant user growth for the platforms themselves.

Despite these successes, designing a successful platform today remains an elusive challenge for new entrants. Through my work of building Microsoft Visual Studio's extensibility platform as well as imeem's Media Platform, I know first hand how difficult it can be to get the equation just right. In addition, Connected is in many ways the ultimate mashup, leveraging over 30 different third-party APIs to give you a consolidated view of your contacts and conversations. In developing Connected, I saw some third-party APIs that had well functioning API ecosystems, while many certainly did not.

The biggest challenge in designing a platform is creating a win-win-win ecosystem for developer, platform, and end user alike. The careful orchestration of each of these constituent's interests is necessary to properly align each party's incentives and make a platform thrive.

Let's take a look at each parties interests in turn:

Developers want fame or fortune.
Much of my understanding of platforms comes from my experience at Microsoft, which prior to the rise of the Internet, built the most successful developer platform in the form of the Windows desktop ecosystem. At Microsoft we often talked developer motivation being fundamentally about fame or fortune. The hobbyist developers are motivated by fame: the opportunity to get their creations in front of a massive audience and build their personal cred. The professional developers are seeking fortune by leveraging the platform to get in front of a massive audience as well as build a meaningful business. So for both audiences it's important to offer compelling opportunities for distribution, often through app store, feed, notification, and marketing channels. At the same time, allowing and encouraging monetization on top of your platform will attract the professional developers. For example, decreasing payment friction through a platform-wide transaction system would encourage further developer monetization.

The platform wants user acquisition, engagement, and monetization.
By enabling app developers to expand upon the platform's core offering, the platform provider hopes to build a more compelling overall offering for end users to attract new users to join, give existing users more reasons to engage, and drive further monetization with their user base.

End users want apps to fill holes in the platform's offering.
End users are typically motivated by finding solutions to holes they've experienced with the platform and enjoy applications that expand upon the core product offering.

While aligning interests may not seem difficult, let me detail five common issues that have emerged with existing platforms due to competing interests of each party that illustrate why platform design is so difficult.

1. Platform competes directly with existing applications.
Twitter's platform is best known for the about-face of it's initial strategy of encouraging developers to build Twitter clients to extend it's reach to all devices, but then suddenly competing with each of these developers with Twitter's own clients, which ultimately resulted in Twitter effectively banning such applications from being built. All the popular mobile and social platforms have found themselves in similar situations. While one cannot always foresee all such scenarios, one should certainly detail what areas of innovation should be encouraged with developers to steer them in directions that do not compete with the underlying platform's own product ambitions.

2. End users find the notifications they receive from applications excessively spammy.
Facebook has dealt with a lot of backlash from users who have found the application invites and notifications they've received to be spammy. And they have had to significantly tune their platform to curtail the usage of notifications in this way, which has ultimately decreased the distribution opportunities for developers. While Facebook certainly made the right trade-off, the platform ultimately may have not been as successful if they didn't initially start with aggressive opportunities for distribution as they did.

3. In an effort to monetize it's platform, the platform imposes a significant tax on all transactions.
While Apple certainly encouraged monetization through it's simple transaction system built into iOS, it at the same time has imposed a hefty tax on all transactions happening on it's device, requiring 30% of the revenue to be given to Apple. It has even required that applications always pay that tax, regardless of whether they leverage the Apple transaction channel. This has discouraged certain interesting scenarios that would benefit end users from being developed on the platform, given the prohibitive tax imposed by Apple.

4. Developers breach the privacy expectations of end users through the platform's APIs.
One of the more recent examples of this was developers who leveraged the Apple Address Book to help end users build their social graph without first asking end user permission to access such data. While the platform is incented to enable opportunities for developers to deeply integrate on top of their platform, doing so sometimes comes at the cost of the end user's privacy. This creates a significant burden for the platform to understand user's expectations with their data and prevent unintended privacy breaches through their APIs.

5. Platform fails to create sufficient incentive for developers.
While most of my above examples have covered the most successful mobile and social platforms, it turns out there are hundreds of additional platforms that have not fared nearly as well. And the #1 reason is they have failed to create sufficient incentives for developers to build on top of their platform. Usually this is because the platform itself doesn't have a large enough user base to offer distribution developers seek. Or beyond that, the platforms don't offer sufficient distribution channels to those end users. Or they simply create too much friction for end users to install applications on their platform. All of these issues fail to create sufficient incentives for developers to invest in building on top of these platforms.

As you can see, platform design is like any design problem: full of competing trade-offs that need to be balanced to encourage the desired behavior. Make sure when building your platform, you thoughtfully consider these trade-offs in your platform design.
Want to accelerate your product career?
I've finally distilled my 15+ years of product experience into a course designed to help PMs master their craft. Join me for the next cohort of Mastering Product Management.
Are you building a new product?
Learn how to leverage the Deliberate Startup methodology, a modern approach to finding product/market fit. Join me for the next cohort of Finding Product/Market Fit.
Enjoyed this essay?
Get my monthly essays on product management & entrepreneurship delivered to your inbox.