Your Internal API Can Drive Internal Innovation
Shiny. That's what your API is. Brand new. Every facet of your business is exposed through it. Developers can search your catalog, get your reviews, post orders or comments, everything. You even have a dev portal setup with a message board, documentation and test console. Now, you just need someone to hit your API. Where do you look for those developers? Do you take out advertising somewhere, sponsor contests or conventions? Try looking at your own staff. The early adopters and drivers of your API will be the developers who work with it every day. By encouraging them to spend time with your public API you will be able to drive internal innovation.
A great way to encourage your own developers to use your API is by giving them the time to do it. Yes, yes, I know. Tickets, roadmaps, ROI, etc are all very important words to managers and can get in the way of giving your developers free time to work on their own projects. You don't have to jump straight into the Google 80/20 model. Start with a an internal Hackathon. Here at Zappos we have quarterly Hackathons - beer and pizza fueled coding frenzies to complete a project in 36 hours. The public API makes it possible for Hackathon teams to finish more advanced projects. Instead of having to hack a SQL script and service layer into a new branch of code for their demos, teams can leverage the API to access our products, orders, customer information and search indexes.
Basing a Hackathon project off public APIs help them get pushed to production faster as well, because they are built on a system that has already gone through your QA cyles and is in production. If a project relies on a new query written against your database then the time to go live with the feature goes up considerably depending on your release and QA cycle. But if a developer writes an app over the weekend or during a Hackathon that hits your API, it can be pushed live with minimal QA time because you already know your public API is rock solid through your standard release cycle.
As your developers hit your API for Hackathon and personal projects, they will find bugs missed in QA. Don't blame your QA engineers. And don't blame your API engineers. This happens. They will also find documentation that needs to be clarified and mistakes in your sample code. This is a good thing, giving you a chance to make your API and community features an even better asset to developers who aren't as familiar with your own business as your people are.
Which brings us to the most important reason to give your developers time and incentive to have fun with your API. Your developers already know your business model and needs. Using your API they will be able to solve problems that business owners might not even know exist. Using your API your developers can drive innovation on both internal features and external apps. Using our API, our developers have created things like a map, and tools to help our customer service team provide even more WoW to our customers on the phone, and most of these projects start during our quarterly Hackathons or over a weekend and turn into full fledged products or features.
Encouraging developers within your company to use your public API not only for roadmap projects but for fun will pay dividends in both happiness and innovative tools.