8 Things I Learned Building a Developer Community For Software Platforms

1. Platforms in their early lives need to prove that they can drag an ecosystem in order to build a successful one.

The iPhone is the canonical example of this lesson. The iPhone was a phone that people wanted as a standalone device before it became a huge platform for application developers. Then people started buying the iPhone (the platform) because of the apps (the ecosystem). In other words the ecosystem started dragging the platform in terms of sales. The same applies to other software products. For the most part I think it's very difficult to build a new product that depends on early developer adoption to build an ecosystem as a requisite for customer purchases without having standalone value. This doesn't apply to products that are exclusively developer focused though.

2. Developer mindshare is zero sum.

Developers, both consumer and enterprise focused, have a great deal of products and platforms vying for their attention. Why should your product be one of them? The answer needs to be compelling, differentiated, and should measurably move the needle.

3. Developers will do least common denominator integrations with products in a given category.

One of the patterns that I noticed when helping to build the developer ecosystem for a large software platform was that developers would build integrations in their products for nearly all leading products in a category. This resulted in doing the minimal viable integrations that effectively ignored any unique features of a given platform. So your special feature that you thought developers would broadly adopt? Maybe not given the tendency to do a least common denominator integration.

4. The competing alternatives need to be more than just good enough.

How would a customer solve their problem if they didn't have your product or any direct competitors? What's that competing alternative and is it good enough? Does your product and perhaps the ecosystem of developers provide 10X more efficiency, cost savings, security, etc? If the competing alternatives are good enough then there's a fundamental problem.

5. Traditional marketing to developers is hard, expensive, and perhaps a big waste of time.

Developers don't like to be the target of marketing. Organic reach and peer affirmation are far more effective. In other words companies should attend meetups, create useful content, and most importantly: build a product that solves a developer problem elegantly, efficiently, without a significant amount of effort.

6. A developer's onboarding process needs to be amazing.

MongoDb is considered to be the gold standard of developer onboarding and seemingly every company with a software platform wants to model their process in the hopes of repeating their success. One can replicate the MongoDb software developer experience in terms of documentation on the website, code examples, wrappers, but Mongo excels at the entire process including a fundamentally easy to install and use product. Great documentation can't make up for a product with a competing alterntative that's good enough.

7. Big companies may waste your time. Identify this early and cut it off if necessary.

Being able to evaluate an opportunity quickly and saying no is hard. It's easy to accept and follow through with every inbound request which can result in time not well spent. Beware of "rock fetching exercises."

8. Partnering is a game of engineering to sales arbitrage.

Developers who are the most effective at making partnering decisions are coin operated. They understand that they're exchanging valuable engineering cycles for product sales. Developers spend engineering time building apps for iOS because they get a large sales channel of prospects. If the benefit of spending engineering cycles isn't obvious a sophisticated developer won't spend the effort.