Driving developer adoption

One of the investment themes we are pursuing here at Flybridge within our Dynamic Computing (which my partner David Aronoff covered in detail here) is the rise of developer driven business models.

Ten years ago architectural standards in large or mid sized companies were set by the CIO or Architecture review boards and the choices were fairly limited (Solaris, Linux or Windows for the OS; Oracle, DB2 or mySQL for the database; Weblogic, Websphere or jBoss for the app server, Java or .Net for languages, etc).  In today's world, on the other hand, the choices have expanded by a couple of orders of magnitude with the rise of open APIS (what Ross Mason calls the ninja slicing of the application stack) open source, virtualization, cloud computing and dynamic scripting languages.  This has empowered the developer to experiment, prototype and ultimately drive the adoption of new technologies in ways that were not previously practical.

As a result many companies are seeing great success in infiltrating large customers not with a top down approach marked by expensive sales people, but rather on with a bottoms up, developer led approach that demonstrates value on a project by project basis before the CIO even knows what is happening.  So what are the keys to success in driving this grassroots adoption?

The most important point is the simple one: your product needs to work and have a clear value proposition.  In other words the age old better, faster, cheaper still applies.  But assuming that, here are ten concrete suggestions for getting the developer driven business model to work for your company:

1. Rapid time to value: Developers are always stretched and have more to do than time to do it.  Your product needs to show value fast.  Traditionally this meant less than 30 minutes to be up and running, although today this is compressing even further (one of our companies has a 5 minute register, download, install, integrate and run goal).
2. Free to start: Have a fully functional, high value, free product that allows experimentation.  If your developer customer needs to pay to do anything useful, they wont adopt.
3. Superior documentation and support: Related to point one, your documentation needs to be clear, easily searched and any support issues need to be addressed quickly and thoroughly.  Get everyone in your company into your support forums providing high value assistance.
4. Leverage existing communities of interest: As an early stage company it is hard to create a movement on your own.  Tap into existing communities with momentum and where your potential customers can be found.  NewRelic, which out of the gates latched on to the growing Ruby community, has always struck me as one company that did this well.
5. Buy your engineers plane tickets (or at least subway passes): Find where your developer customers congregate and get your team into the community to attend meet-ups, show off your product and explain what it does and why it solves real problems.  Overtime, generic meet-ups can become more targeted around your specific solution as we have seen withour portfolio company 10gen, and the highly successful events they put together for the mongoDB community.
6. Facilitate word of mouth: Get your customers to speak on your behalf, either live or via their own blogs.  Share presentations and use cases via slideshare.  Contribute positively to HackerNews & Stackoverflow.  Work twitter.
7. Have a CEO that can code: Street cred matters both externally and internally and respect in the community will build if the leader of your company has walked in the shoes of your customers.  If you are a CEO and are not a hard-core developer, fix some bugs, work on the front end code, and resolve support issues. 
8. Don't market:  Developers are smart and cynical.  Slick marketing wont work.  Speak their language, solve their problems, add value first.  That gives your credibility to expand usage and ultimately get paid.
9. Have a clear pricing model:  Historically people think developers don't pay for anything.  This is true, but their bosses will.  If you are adding value, people will want to pay (and in fact a company with out clear revenue model may actually see slower uptake as Sean Ellis wrote about here), but they will need to know on what basis they will be charged so they can understand the longer-term implications of working with you.
10. Help your early adopters sell internally: Once you have some champions at a customer, especially in larger organizations they may need to convince their bosses that what they want to do is the right idea.  Be ready to arm them with information on security, performance, integration points and other similar implementations to make this easy for them.  

This is my top ten list, would love to hear other thoughts on what works, or does not work, for you.

Comments

[Scott Barnett]

Chip I think you nailed it. The other thing we tried was instant chat - if a developer was "stuck" on something, poring through the online help is good, but sometimes not immediate enough. As you mention, their time is precious, so if a few minutes chat gets them over the hump, that's a huge plus.

[Alex Salazar]

Great article Chip! I particularly love #10. Even the most die hard developer-centric company can sometimes forget that the developer still has to convince someone to budget and approve a significant purchase.

Thanks for capturing all this in one place.

[Claire Hunsaker]

Thanks, Chip - this is prescient and helpful. I love thinking of "Time to Value" both as an internal goal and a market differentiator. I would push back on #8 - ultimately the other bullets describe savvy marketing activities (says the marketer). "Speak their language, solve their problems, add value first" - these are the first steps in being an valuable community member, which is where grassroots marketing starts, but not where it ends. I can think of companies in this space who regretted not bringing in a marketer earlier; engineers are swamped, and coordinating all these activities is a lot of work.

[Lhazlewood]

Great stuff! #8 is super important for today's connected and savvy developers. Add value first, and trust and business can follow.

[Michael Campbell]

Great post Chip.