After 15+ years building products, startups, APIs and SDKs that empower developers in some way (most notably the Uber Developer Platform), I share my tips and tricks for building a great platform that makes developers successful.
Get an audio version of these tips and tricks on my podcast at bumpers.fm/startups
2. Top 3 things to consider
1) Make it easy to use - Developers want to go from 0 to hero quickly
2) Developers need three key things
a) Utility - something they can get from your APIs or SDKs
b) Revenue - cash by using your APIs or SDKs
c) Distribution - more users and more activity by using your APIs or SDKs
3) Be consistent. Thoughtful. Have Empathy
a) Telegraph breaking changes
b) Explain your intention and future roadmap
c) Give new opportunities as you inevitably cannibalize/close off others
3. Product strategy: You must offer at least 2...
1) Utility: Offering users a feature or a data set that’s hard for them to build from scratch.
a) E.g. Facebook login/identity/profile data
2) Distribution - A way for developers get more users or more user engagement from existing users.
You need to be willing to sacrifice primary surface areas.
a) E.g: Apple App Store, Facebook’s news feed, Twitter timeline
3) Revenue - A way for devs to make hard cash by integrating your API and investing in your
platform.
a) E.g. Paid apps, in-app purchases, ads
4. Support Devs with Empathy
● Support Developers Where They Are
a) Twitter, Stock Exchange, etc.
b) Be highly responsive & thoughtful
c) Make sure your tone matches the platform
● Telegraph & Explain Change
a) Give Devs plenty of notice about upcoming breaking changes
b) Maybe even share your high-level roadmap
5. Support Devs with Empathy Cont...
● Embrace the Philosophy of “Give and Take”
a) Platforms evolve, your core product will evolve. Some of the evolution will cannibalize the
white space your developers have enjoyed
b) As you take white space away, add new white space
● Be Patient with Bad Actors
a) There will always be rule breakers- Give them a chance to course correct and do the right
thing
6. Things to Avoid
● DON’T use developers as free distribution or innovation until you get around to filling in gaps in
your product. Try to minimize cannibalization. Be clear about your strengths and create space for
your developers to “play”.
● DON’T expect it to be easy - it will take a lot of time, money, and patience. Years.
● DON’T take all the money/opportunity. Leave enough money on the table for developers to get
rich.
7. Open Vs. Closed Platforms
● Open Platforms: Public docs, broad range of developers allowed to participate with low barrier to
entry. Platforms that are too open, w/o policies or rules, can become like the wild west - do more
harm than good to your business.
● Closed platforms: typically NOT publicly documented, getting access requires permission or an
agreement, in extreme cases, they are only available once you’ve done a high-touch custom
development deal. On the extreme end, this is not really a Dev Platform; it’s really more of an API
simply used to operationalise business deals.
● Usually the best answer: Hybrid Approach : Public docs, low barrier to entry, clear guidelines, best
practices, terms of service, strong enforcement & curation
8. 7 Benefits of Having a (mostly) Open Platform
● Brand: Open Dev Platforms ensure that you, your technology, brand, services, etc. are seen as
inviting & welcoming.
● Recruitment: Devs in their spare time are able to interact with your company at a technical level -
and get excited about joining your mission.
● Alignment of Ecosystem: Companies all over the world will be invited to invest in What YOU Do
and How You Do It. This aligns incentives.
● Surprising Innovation: In, On, Around your company & your core value.
● Network effects: Devs build great stuff for your platform -> get more users/engagement ->
encourages more dev on your platform
9. ● Scale, Coverage, Choice, Speed: When you have 10s, 100s, or 1000s of devs building on/with you:
the scale, coverage, and choices they will offer your users & the speed at which it will go is
unparalleled. There is NO OTHER WAY to achieve this.
● Overall, an open platform mean that you’re able to create a BETTER, DEEPER, BROADER moat
than ANY single feature or set of features your team might build 1st party. This makes your
business MORE DEFENSIBLE in the marketplace!
7 Benefits of Having an Open Platform Cont.
10. Limiting Risk
FEAR will be everywhere! Yours, your team’s, leadership’s, or company’s
1) What if Developers do something you don’t want them to do?
2) What if they make a successful version of YOUR app and disintermediate you from your users?
3) On and on…
SOLUTION: You can build an open platform in a way that allows for surprising generative outcomes, but
also protects the downsides and limits the risks.
11. Limiting Risk Cont. (Tools/Limits You Can Use)
● Start with the design of the API itself: Be thoughtful about the way the API works - the scopes you
make available, the features, data sets involved. (careful not to be too limiting)
● Terms of Service: The click-through legal agreement your developer has to agree to before using
the API that can impose constraints like usage of data, length of data retention, use cases for API,
so forth. Eg: can include that they can’t mention that they partnered w/ your company only that
they integrated your API.
● Best Practices Guides: Can provide strong advice about Branding, UI and UX workflows that
matter to your business and your brand
12. Limiting Risk Cont. (Tools/Limits You Can Use)
● Sample Apps: typically open source starters that devs can use to quickly bootstrap their project;
tend to guide them down certain paths & minimize tendency to go off on a tangent
● Use a big carrot: You can highlight fav. implementations in gallery or blog - great for good actors in
your developer ecosystem!
● Of course, no set of tools is perfect…
You’ll need a team and a process for enforcing your policies. Be sure to send them friendly but firm
cease and desist and defend your rights. Try to offer more carrots than sticks to encourage good
behavior/compliance.
● Relax: The goal of building a great open dev. platform is to ENCOURAGE surprising innovation.
13. A Dev Platform team requires similar roles general cross-functional teams (PM, EM, Eng, Data Science,
Design etc) - the difference is in the special mindset of the people and a few extra roles...
Special mindset
1) Mindset: Platform first thinking: Most PMs and EMs want to build the product first, then
generalize. It takes people who love, bleed, and breath platforms to be able to figure out the
Primitives, patterns, abstractions from day 0.
2) Mindset: “Abundance Thinking”: Everyone on your team should be passionate about creating
space for others to succeed; They should believe deeply in the philosophy “If you want to go fast,
go alone. If you want to go far, go together” (African proverb)
How to Build a Great Dev Platform Team
14. A Dev Platform team requires similar roles general cross-functional teams (PM, EM, Eng, Data Science,
Design etc) - the difference is in the special mindset of the people and a few extra roles...
Extra roles
1) Dev Advocates - 1:many (they create blog posts, webinars, public talks etc), Stateless (they don’t
tend to maintain long-term relationships with customers), Outbound (they travel around the world
and generate interest), Egalitarian (they help everyone - big or small)
2) Partner Eng - 1:few (mainly interact with strategic partners), Stateful (maintain long-lived
relationships over multiple problems/engagements), Inbound (they tend to react to inbound
leads/opportunities/questions), Pre and Post-sales support of strategic partners (they must triage)
How to Build a Great Dev Platform Team