I often talk to people who are grappling with the question of how to get their products, particularly cloud services, adopted by developers. If you ask people to name companies that are really good at getting developers to use their products, you typically hear companies like Facebook, Google, or Apple listed. These companies, as successful as they are, don’t really provide a lot of useful hints on how to do this, because, in truth, it’s not that they’re good at getting developers, it’s that they’re “not not good” at it. What I mean by that is that the reason people are interested in learning the API of Facebook or figuring out how to develop for iPhone has everything to do with the market that can be tapped into by creating products for that market. So, people would have made the effort if those were the most difficult platforms to learn, and. in fact, at the beginning, they were none too easy although the situation has changed considerably over time. When we started Widgetbox back at the end of 2005, the idea was that we’d provide a platform for developers to build and deliver widgets and that we’d also create a destination site, essentially an “app store”, for users to find widgets.
We didn’t initially succeed as well as we’d hoped in being a consumer destination, but we did manage to get an impressive number of widgets built on the platform, literally thousands of them in the first six months. We didn’t have any market clout to make this happen. Although we’d hoped to have partnerships with social networks to aid in distribution of widgets built using our service, these didn’t really kick in until much later.
So, what accounted for the early developer traction at Widgetbox?
There were really three key things that moved the needle, all surprisingly started with product functionality:
- Maximally Minimal Sign-up
- “Magic” Point Features
- Learning their API, not making them learn ours
Getting Self-Service Right
This is such a “Mom and Apple Pie” thing on the Internet that it seems silly to even bring it up. However, developer or professional-oriented products often have implicit or explicit business terms associated with them that are beyond the usual no-commitments consumer terms of service. It probably starts with the goal to maximize the value of the “lead gen” at the expense of making it too easy. In fact, some schools of thought actually want to introduce friction here to make the lead more “qualified” – just don’t forget the maxim “all attempts to limit the size of the market for your product will ultimately succeed”. There’s also the desire to impress the customer with a range of account options, show off that you have corporate accounts and pricing available, and so on. And once you get through all that, you want to awe them with your massively powerful dashboard or command console. Yes, the developer is essentially a “business customer”, but business customers are just like any other user on the net, you put too much process and pomp and circumstance into getting started and you’ve lost them. We instrumented this whole thing as goals in Google Analytics and we could see it first hand.
So, even though it should be obvious, it seems like it always bears repeating, and most companies only get it half right. For example, Apple is both bad and good about this with their Developer Program. Bad in that they’re really a pain in doing things like setting up a business account, you have to be prepared to fax documents proving your company status, and getting your account set up can be a week long process. Good in that they do have a lot of things in their developer portal that you can ignore until you need to, and they’ll remind you when you do. But, overall, it’s a safe assumption that if you were anyone but Apple, you wouldn’t succeed with this approach unless you made it a whole lot easier for your developers. GitHub is a much more pleasing experience. It’s extremely easy to get started and only starts to get a little more complicated when you try to figure out whether you should go to a business account or not.
“Magic” Point Features
Sometimes this gets confused with Minimum Viable Product, and although it’s a similar concept, there are a few differences. The idea here is that there’s going to be a small set of “quick win” standalone or “point” features that a developer will make use of because they’re quick to integrate in relation to the value they provide and which serve as a hook to getting more usage from the developer over time.
At Widgetbox, we had three things that immediately added value with a couple of minutes of work on the part of a widget developer. These were:
- One-click Installation
Installation refers to the fact that we made it very easy for you to make your widget one-click installable into any website, blog, or social network. Even if you got no other value from us, this was probably of enough use that you’d at least sign up for our free tier.
Analytics was the final piece of the equation, and isn’t too hard to see the value of. Since we were managing the installs and the per-user configuration information, we were able to provide very useful analytics of all key metrics for widget use such as where it was installed, how many pages on a site were carrying it, how many people were seeing it, how many people who saw the widget decided to install it themselves on their own site (virality).
Any of these three features would be reason enough to make use of Widgetbox, and we knew that the key to success wasn’t in getting developers to make use of every single feature of the platform on day one, it was in getting a toehold that we could then build on over time. So, with each of these features, the challenge was to really focus on making sure the features were found, utilized, and benefited from immediately.
Learning Their API, Not Making Them Learn Ours
This last point was really the most interesting from a technical standpoint, and was something that we tried to make as invisible to the developer as possible. The goal was that the system was just smoother and easier, but it was critical in making all of the point features we listed above actually work. What “learning their API” means is that we spent a lot of time investigating how existing widgets actually were installed, configured, and measured, and we designed our service to couple seamlessly to these, to the degree that a lot of developers who made use of Widgetbox might not have fully appreciated what we had done (for the hardcore programmers, think of it as “dependency injection for web widgets”, for the rest of us, just think “magic”).
Finally, for analytics, while we would encourage the widget developer to more deeply instrument the widget to get better data, our efforts into understanding the usage lifecycle of widgets, from installation to usage to viral distribution, allowed us to automatically know what events in usage to pay attention to, log, and analyze to make the analytics reporting as immediately valuable to the widget developer without them having to make any modifications to their widgets to take advantage of our system.
So, it wasn’t just knowing what the high-value point features were, it was learning enough about how these needs were already being addressed that we could be easily substituted for the existing makeshift solutions and immediately start proving our value.
Now, of course, it’s not to say that we didn’t make use of buying AdWords to make people aware of our service and that we didn’t have PR and marketing efforts going on all the time. We also spent a lot of time in evangelism and outreach, figuring out how to get to widget developers both one by one and en masse. However, these could only go so far as to deliver the developer to our doorstep. From that point on, we had to figure out how to get the widget developer to start realizing value from the platform as quickly as possible.
Hope this is of help to people who are thinking about bringing a developer-oriented product to market. There are a lot of folks who get very intimidated by this type of business and tend to shy away from it, but, as I’m fond of saying, the largest software companies in the world today got their start in products that almost exclusively served developers.