Back in 2005 when the “mashup” craze was really taking off, we were getting reports at Yahoo! about how many developers were using our Maps API. The report was broken down into technologies, web sites, and how many API calls were made from each. Sites like programmableweb.com were busy cataloging platforms and counting how many web sites and developers mashed them up (known today as integrating/extending APIs). Up until recently, many thought successful evangelism meant attracting as many developers to your platform community as possible. The more apps, the more API calls, and the more developers were using your service – extending your brand – calling attention to your service – bringing folks into your domain, and so on.
In some cases, you could see where companies were looking more at their developer totals than the number of quality apps being built on their platform. Not to say this wasn’t a valuable practice. For companies considering developers as customers, the sole purpose of the platform may have been attracting users directly rather than indirectly — through the apps developers built.
But for many companies, this approach ultimately failed. It costs big money to (properly) evangelize to developers, appear at worthwhile conferences, support SDKs in multiple development languages, and adequately power a good performing platform to deliver your service to countless apps and developers.
In advising many companies, I’ve referred to this approach of going out and marketing/evangelizing your platform to any developer as the “butterfly net” strategy. That is, you are going out with a big net to catch as many developers, no matter their ability, specialty or value, and hoping they’ll sign up, download your SDK and use your platform.
Eventually, of potentially thousands of developers, only a few valuable apps emerge. And while the service platform may provide for a nice weekend challenge, the platform may be no match for something out there that can better provide a developer with visibility and even a somewhat easy-to-achieve revenue stream.
There’s been a major shift in the last few years. Developers have become much more savvy in how they spend their time adopting new platforms and respective platform technologies (languages, frameworks, etc). The biggest and most obvious catalyst for this change is the success of device-based platforms like iOS and Android. While structurally different than more prolific service-based platforms (SDKs extending enhancing apps like geo-location, virtual currency, communication, etc), device-based platforms take even more time for a developer to adopt, in principal, and offer a proven incentive to developers — direct sale and monetization of an app. And so, service platforms not only have to be more discoverable to a developer, but they have to present a value proposition that competes with other platforms in a way that almost compliments them.
Many platforms, particularly the abundant and smaller service-based ones, can grow much more valuably now by moving away from the butterfly-net strategy, and align themselves more with traditional business development approach. This can be achieved in a more direct and even cost-effective approach. Instead of showing up with a booth at a conference and trying to ‘recruit’ developers point-blank, platform companies should seek out developers who may have already built apps that will benefit from their SDK. I find it’s easier to answer the question “how can I build this into my app?” over “how can I build an app around this platform?”. The other benefit is knowing the developer is already familiar with — and maybe even a master of — the coding language your platform supports. This, too, saves incredible time in supporting adoption.
I’m not suggesting you abandon the old-fashioned conference appearance. Platforms stories of technology and success still need to be told in front of interested developers. Again, don’t always try and push the platform to a new breed of developers. Try targeting audiences that may be already familiar with your platform, or even developers you’ve already presented to before. And after the presentation, webinar or meeting, listen a little more to those really interested in your service. Schedule time to walk them through docs and examples. See them through the integration of your service and you’ll see an app launched that brings more value to you platform than takes away from it.