How To Get Traction With Products For Developers

Ed Anuff —  June 2, 2011 — Leave a comment

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:

  1. Maximally Minimal Sign-up
  2. “Magic” Point Features
  3. 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.

With Widgetbox, at the beginning, we made it as easy as pasting in the URL to a Flash or Javascript widget you’d already built.  Over time, this was expanded to letting you paste in an RSS feed, then Flickr, Twitter, and anything else that could kick off the process.  There are a few interesting things to this that I’ll expand on in my third point about “learning their API” later on.

“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:

  1. One-click Installation
  2. Personalization
  3. Analytics

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.

Personalization referred to the fact that building a widget, in Javascript or Flash, represented one set of challenges, but what was really hard for any but the largest widget publishers, was enabling the user of the widget, meaning the blogger or social network user who installed in on their page, to personalize it before or after installing it.  What made this hard was that it meant the widget developer suddenly needed to build and manage a big data infrastructure for delivering the personalization data to the installed widgets at runtime.  Keep in mind that a successful widget could get millions of views a day, since it might be installed on a number of pages, and each of those pages would get a number of visitors, resulting in a very large number of web service requests from the widget server.  This meant that many widget developers were either foregoing or severely limiting the personalization options they provided to make it more manageable for themselves.  Widgetbox essentially provided a high-scale key-value datastore coupled to a UI form-builder, so that the widget developer could provide their user with a slick way to configure their widget and then the developer could leave the high-scale serving of the configuration data to the widgets to us.

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”).

For installation of widgets, this mean creating our own wrappers that could generate the necessary Javascript or Embed codes to load a Javascript or Flash widget into an existing page in as seemless a way as possible, including automating some of the tricks necessary to get these widgets into MySpace, which at the time had a habit of banning third-party widgets.  We’d later expand this to couple directly to the install API’s of TypePad and Facebook.

For personalization and configuration, it got even more interesting.  We found that widgets were typically configured via either parameters in script tag URLs, flashvars in Flash embed tags, or in local Javascript variables.  We designed our configuration system to make it easy to substitute in values from a configuration form into these at runtime, so the developer didn’t even have to recode their widget to our API, they could just take their existing widget, that perhaps had hard-code configuration options or required the user to hand-edit a URL to configure, and then, using our system, make their widgets dynamically configurable by the end-user.   We later expanded this to make the configuration happen contextually based on the content of the page. so that any widget could suddenly be like Google’s AdSense widgets that display ads related to the page content, so that someone could use Widgetbox to build an Amazon book widget that had similar behavior.

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.

No Comments

Be the first to start the conversation.

Leave a Reply

Text formatting is available via select HTML. <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*