Are You an API Company or a Product Company?

There are two broad types of software companies in the world, API companies and product companies. API companies are those who are focused on providing the best and most useful API’s possible. While they too might build product(s) on top of their own API, it is clear that their API comes first and foremost. Two prime examples of this approach is EchoNest and Amazon Web Services.

On the other hand there are product companies who are solely focused on making their product as good as possible and don’t care about the developer community. While some of these companies go so far as to release an API, it is obvious from their actions that they really don’t care or allow anyone to build anything great on top of it. Examples of companies/products in this realm include tumblr and Google+.

This distinction became clear to me after a recent experience I had with a company named Songkick. Songkick gathers data on upcoming music concerts in the US and UK. They expose this data via a web application at songkick.com along with having a developer API.

I have been kicking around some web app ideas in my head in the music space. After deciding on one I wanted to build in the concert space I headed over to Songkick’s developer page to get API access. I put in my email and a short blurb about my idea and submitted it. I was told I would “receive a decision in a few days.” Arg. It was at that point I should have realized this wasn’t going to end well.

Four days later I received an email from Songkick notifying me that my request had been denied because according to their representative “we're holding off on issuing API keys to services that are that similar to our own functionality.” Seriously?! Did my idea have some overlap with theirs, sure it did. We’re all using the same data from the same API after all, what did you really expect?

After giving it some more thought I realized that the issue isn’t Songkick being extraordinarily picky about who they give API access to, the problem is that they are a product company, that unfortunately happens to have an API. Product companies worry about others taking their API and making something better than what they’ve made with said API. Contrast this with the behavior of an API company, in this example Amazon Web Services. When AWS was first released it was just a set of API which developers could use to launch servers. Shortly thereafter the folks at RightScale and enStratus realized that they could build a nice web console on top of it to make the server creation experience simpler and easier to use. For a few years both of those services spent a lot time taking those APIs and building useful tools on top of them that make them even better.

A few years after the API release, Amazon decided to release their own web-based console. Did they revoke API access for RightScale and enStratus because they provided “similar functionality” to what the AWS Console provide, absolutely not. In fact, AWS Console is just another application built on top of the AWS API, they get no special treatment. As a cautionary tale to those considering making the switch from one to the other, lets talk about Twitter. From the very early days it was clear that Twitter was an API company. They had their flagship web app, but by releasing an API they allowed developers to create tons of different client applications. Web apps, iPhone apps, Andriod apps, and even entire devices dedicated to tweeting. This strategy was working great for Twitter and allowed tweets to be written and consumed from almost any device that was programmable.

Everything was going great until March of 2011 when Twitter “Drop[ped] The Ecosystem Hammer” on its developers. What really happened was that Twitter made the decision to transition from an API company to a product company. Unfortunately that transition was made abruptly and with little warning. Many developers who had spent years developing on their platform were upset and ultimately stopped making applications.

If there is one thing I learned from my experience with SongKick and that you’ve hopefully learned from this post it’s this: the decision between being an API company is an important one and if not done correctly it can cause a tremendous amount of strife between you and your developer community. Make the decision, make it early, and make it obvious to everyone else.

Ship Code When It Is Ready

My previous jobs had what I consider a fairly standard month long release cycle. The first three weeks of the were spend writing code. On the fourth week the code was dropped to QA where they would hammer on it, find bugs, and have developers fix them. At the end of the fourth week the code shipped.

I distinctly recall the final week before every release having an uneasy feeling in my stomach. Even though I had thoroughly tested my code and QA had signed off on it, I always worried that it would break horribly in production. Did I miss a corner-case? Was someone integrating with my code going to break it? Had there been regressions in the mad rush to get fixes in before the release? I’ll never forget that feeling....

That is why I was really surprised when I started working at turntable.fm. I distinctly recall when I finished my first (tiny) feature. After quadruple-checking the code to make sure all the digital i’s were dotted and t’s crossed I sent it off to code review. Another developer took a look and said “Yep, looks good.” I naively asked, “when is the next release?” To which he responded “Right now.” Uh oh, I was getting that feeling again... but just a minute later the code had been deployed and there was my shiny new feature staring me in the face, working just as I had hoped. It was a special moment.

This had a profound effect on how I think about deploying code. I often get asked what is our release process, to which I reply “we ship when the code is ready.” It’s just that simple.

I’ve observed many benefits of this release strategy:

• Instant gratification. There is nothing like the constant positive reinforcement of frequently shipping shiny new features. As a developer this kicks my motivation into overdrive.
• You’re users get a constant stream of new features rather than having to wait for what amounts to a “monthly feature dump.” After you push new features and ask your users if they can spot them, you’ll be surprised at how quick they identify them.
• When each feature is pushed separately it is a lot easier to gauge your users response. Just like with A/B testing, to get a clear response you want to minimize all other factors.
• All the integration and testing is done by the developer shipping the feature. This means if anything goes wrong its obvious who should be investigating the issue.
• If there are problems it is easy to roll-back since your change is that only thing that got pushed.
• Debugging any issues with the code is easier since the code is still fresh in your mind. Getting all of the code you wrote a week (or a month) ago back in your brain can take longer then you would expect.

Do you ship code when it's ready?