Ten years ago, if two companies wanted to work together, they would need to get their technical teams in the same room and figure out how to mate their two technologies. Then came the API.
API stands for Application Programming Interface and is a specification of how some software components should interact with each other in order to marry two technologies. Once a company builds an API, other companies are able to plug in their technology (whether it be for maps, SMS, or something else).
Why You Need An API
There are typically two use cases for APIs. The first is building a developer community to extend the ability of your platform--these are usually free to use. The second is building a service that other people can use and pay you for; sometimes APIs as a service are free and monetized by other means. Both use cases make it much easier for a company to get functionality they need and/or partner with another company without the heavy lifting of custom integrations for each partnership.
I?ve worked for two companies in a business development role emphasizing the API platform: first at Aviary, a photo editing API platform for web and mobile, and now at Dwolla, a payment network, helping companies plug in a cheap and secure way to send and receive money. The two companies have different offerings in their API and I have learned a great deal about how to successfully manage these relationships to further each startup and build the business side of building your API platform.
At Aviary, we made it easy for any developer to plug in photo editing to their website or mobile app. They now power the editing and filters ability for a slew of apps, including Walgreens, Twitter, Flickr, Squarespace, Box, Edmodo, MailChimp, and more. When I left the company in April 2012, they had around 6M MAU; in May they announced 50M MAU. They have one of the best scalable APIs, and helping to work on the infrastructure for its growth taught me a lot. We are still in the infancy of the API at Dwolla, but there are some big things in the works and the rest of the year should be very exciting.
Below are a few things I have learned about building the business side of an API and dealing with getting companies to use your API.
Got An API? You Need A Dev Portal
One of the first things a company must think about when developing an API is a website dedicated to the use of that product; most people call it a developer portal. A big misconception about developer portals is that they are only for developers. This is not always the case! More often than not, it is a business or non-technical founder who stumbles upon the API section of the website, looking to see if that company might have specific functionality and be the right fit for their company. If all that exists are documentation, sample code, and helper libraries, you will probably lose this type of lead. You need to cater to both technical and non-technical people alike.
At Dwolla, we thought of it as a decision tree. When you get to the developer portal you are asked if you can or cannot code. If you code, you go directly to the documentation. If not, you head over to the side of the portal that tells you why you should use Dwolla, how you can use Dwolla, who else is using it, and FAQs. We have had a lot of success with this.
One of my favorite API-focused companies is Twilio. Twilio lets you build voice, VoIP, and SMS applications. They fall into the second bucket of use cases (API as a service). They?ve built a great website that is very simple and clear to find exactly what you need, whether you are a business/product person or developer looking to build SMS, voice, or VoIP into your application.
Your API?s Rocket Fuel: Hackathons
I am often asked about sponsoring and participating in hackathons in relation to a company?s API. I?ve been involved, organized, and attended more hackathons then I can count on two hands. I?ve been on all sides of the table and seen it all.
From the outset I should say that hackathons are useful for jump-starting platforms. Coming from the business standpoint, I?ve had the most success when organizing the event. When you and your company are the center of attention, it is very easy to get all your targets in the same room for 24 hours so you can build a meaningful relationship with each one. I think if you are looking to make a name for yourself in a specific vertical, organizing a hackathon is a great way to do it.
Another thing to mention is that it is very rare to see a return on investment for a sponsorship at a hackathon. If you?re hoping that whatever developers build that weekend will end up going the distance, think again. For me, the most beneficial thing that comes out of a hackathon, as a sponsor, is meeting the other companies who are sponsoring. I have met many eventual partners for the first time at a hackathon.
If you are not organizing, my advice is to participate at the lowest sponsorship level and offer a slick prize for people to use your API. This usually has the best results in terms of engagement with developers. On top of that, hackathons are a great opportunity to talk to developers about your offering and get honest feedback to make it better. A lot of companies use hackathons to release early versions of their API or features in their API so they can get this key developer input.
Validate Your Endpoints With Partners Before Designing An API
When building out an API platform, one of the first things to do (even before building the API offering or a specific feature set) is to talk to prospective partners about different functionalities they might use from a hypothetical API.
Talking to prospective clients/users seems obvious, but until you actually figure out their problems and needs, you may be building something that nobody wants or cares about. For example, when I was at Aviary, Avi Muchnick, the cofounder, would always have the business team liaise with potential API integrators before he would pull the trigger on building a new product. Every time we launched something, we had already garnered interest and attention from several companies who were ready to use the product from day 1.
Getting a lay of the land not only helps figure out what to build, it also helps launch the API with partners who will publicize.
Work With Your Partners To Launch Killer Integrations
Hopefully you?ve built something other companies really want. The best way to get usage of your API is to initially launch it in conjunction with a few other companies as partners.
In my experience, if you deliver the right product and have a few great use cases to point to, there is typically a compounding effect that takes place. At Aviary, we launched our web API around Thanksgiving 2010 with 12 companies, and then a mobile SDK in September 2011 with 30 companies. You can see on the Aviary homepage that they now have 4,500 integrations.
I?ve also seen scenarios where you follow this formula and the opposite occurs. It?s usually when the product doesn?t match what people actually want or there is a scaling problem (i.e., the product is meant for a niche group but you want it to work for everyone). A surefire way to fail with your API (as a service) is to go build it without ever talking to any prospective integrators.
It shouldn?t be a surprise, but if you don?t talk to anyone, have no pipeline of companies waiting to use it, your expectations should be zero. The harsh reality is that by the time you get the API ready to use, you will have internal expectations that will be nearly impossible to hit unless you get insanely lucky. That?s no way to run a business and should be a cautionary tale for anyone looking to build a business around an API as a service.
Plan For Your API?s Next Horizon
Everything in this article will put you on the right direction when thinking about the business side of your API platform. While every piece is important, just remember to listen to what companies really want. If you listen and come back with a product that solves the issues for them, you will be in a great position to build and scale the business side of your API.
The final thing you should consider when opening up an API to the outside world is how well those endpoints will serve your business as it grows. Many companies only open up API access to functionality or data that is not core to the platform, and which doesn?t dilute the brand. The danger, of course, is that you don?t want third parties competing with you on your own platform. Closing down API access can create developer backlash, so think carefully before you build, and keep your dev community happy.
[Image: Flickr user Archibald2002]
Source: http://www.fastcolabs.com/3014493/open-company/the-business-side-of-building-your-api-platform
ash wednesday Zero Hour Funny Valentines Chris Kyle Russian meteor Meteor Hits Russia Dorner Manifesto
No comments:
Post a Comment