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?

Managing Talent: A Running Metaphor

When I first joined the cross-country team in high school I naively thought that running was all the same, you just ran. Then came the first day we ran hills. It was then that I realized that running has a lot more technique and skills then were initially apparent. One of the most important things I learned was how run down hill.

On that first day of running hills our coach told us to “really work it going up the hill and recover on the way down.” After reaching the top of the hill I began my “recovery” back down the hill (i.e. jogging slowly). However, I noticed that everyone else was flying passed me on the way down the hill. Not only that, but when they reached the bottom they seemed even more rested and recovered than I was.

After practice I asked one of the guys on the varsity team why everyone’s “recovery” speed was so much faster than mine. In true Southern California surfer fashion he said “Dude, you just got to learn how to let your legs go.” Let my legs go, what the hell does that mean? Is that some sort of weird surfer zen thing?

What he meant was, when running uphill you really have to churn your legs to keep moving. However, when you reach the top and start going down, your legs are already churning. With the help of gravity, your legs will keep churning unless you actively try to stop them. See also: Newtons first law. It is the same effect you get as when you drive down hill and put your car in neutral.

Once you figure out how to “let your legs go” you just have two things to worry about. The first is that you regulate your speed. Your legs can take you far faster than you can safely go, so you should constantly be regulating your speed to go as fast as is safely possible. The second thing is avoiding obstacles. It only takes a small rock or divot to catch you off guard and send you tumbling down a hill. The further away you see the obstacle the easier it is to avoid.

Managing talented people fundamentally uses the same technique as running down hill. Imagine your team as the legs and you, as the manager, are the head. When you have a talented team, they should be able to move incredibly quickly. While their ability to move fast is a good thing, it is your job as the manager to make sure that your team is going as fast as they can while still being safe. If you allow the team to move too fast they will eventually trip and fall. Hopefully its just a scrape or a bruise and they can get back at it. But sometimes the injury can be really serious and the recovery process is a long and painful one.

Avoiding obstacles is the second skill you need to master. As the manager you are the vision. You see whats coming both short and long term, it is your job to steer the team appropriately. You have to make sure you are tracking what is right in front of you as well as what is on the horizon. Its important to remember that the further away you see an obstacle, the more smoothly you can steer the team around it. If you are really good, your team wont even notice the small course correction you made a while back that let you “effortlessly” avoid the giant bolder that would have eventually blocked their way.

If there is one piece of advice I can give you about managing a talented team it is: “let your team go.”

Eatability Testing: Why don’t more restaurants do it?

Two things I’ve observed about people in New York is that everyone jaywalks and no one cooks. Everyone eats out all the time. However, since most people are busy, a large amount of food is served via takeout and delivery (as opposed to eating in). This presents a challenge that few restaurants seem to realize: the long delay between when the food is prepared and when it is actually eaten.

How many times has this happened to you, it is late on Sunday evening and you call one of your favorite restaurants for a little delivery. You pick your favorite item off the menu, place your order, and wait in anticipation. Thirty minutes and a cash exchange later and food is on your dinner table. You pop open the styrofoam container, grab a bite, and yuck, it’s cold.

Across the street from where I work at there is a fantastic Vietnamese sandwich shop called Num Pang. Their menu is filled with tons of delicious sandwiches like ginger barbecue brisket and hoisin veal meatballs. The trick with eating Num Pang is that you have to eat it immediately. In the 10 short minutes it takes to get your order and walk back to the office, the bread has already started to become soggy. If someone happens to catch you in the hallway you might as well say goodbye to your sandwich and hello to a (not so) hot mess.

This begs the question: why don’t more restaurants and takeout joints test the experience of eating food from their establishment? Prepare an order, put it on the counter for 20 minutes, and then have the chef eat it. Better yet, have the delivery person take it out with an order and then bring it back. I’d imagine most chefs would be surprised at the “presentation” and taste of their food after it has taken a bike ride through NYC in the winter. What was once a nice pad thai dinner will likely have turned into a cold ball of yuck.

Why don’t more restaurants do this? I think many restaurants are in for a rude awakening when they start eatability testing their menu.

Here are some of the most common missteps I’ve seen:

• If you are serving something on bread (hamburgers, sandwiches, etc) then any sort of sauce or liquid on it is going to make the bread soggy within 5 minutes. If you can, just put the sauce in a container on the side. I’m sure some health-conscience customers would appreciate it as well.
• If you have to serve it with sauce, make sure to put the sauce as far away from the edges of the bread as possible. Otherwise, the sauce leaks out of the sides and make the top and bottom of the bread soggy as well.
• Separate hot and cold, just like you would at the grocery store. Styrofoam insulates surprisingly poorly, so packing a cold dessert on top of a hot soup is a bad idea. Account for leakage. Some well placed napkins can go a long way.
• Account for the cooking and cool down that happen during travel. Talk to any chef in a food competition and they will tell you that residual heat can have a large effect on the taste of a meal. Account for the 10-20 minutes of delivery time for all to-go orders.
• Test & iterate. There will always be surprises, so eatability test with different items on the menu to make sure that it is as good as you expect it to be.