How Zappos Drives Internal Innovation With Its Public API

Guest Author, July 19th, 2011

Comments(1)

This guest post comes from Jimmy Jacobson, a developer and advocate with Zappos IP, Inc’s API team.

Shiny. That’s what your API is. Brand new. Developers can: search your catalog, get your reviews, post orders or comments, and everything! Now, you just need someone to hit your API. Where do you look for those developers? Try looking at your own team. 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.

Hackathon Demo Open House

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 an internal Hackathon like Facebook, LinkedIn, Dropbox and TokBox do. Here at Zappos, we have Hackathons every quarter – beer and pizza fueled coding frenzies to complete a project in 36 hours. What kind of benefits will you see by encouraging your devs to hack against your Public API?

• Faster Path to Production for Projects: Basing a Hackathon project off public APIs help it get pushed to production fast because it is built on a system that has already gone through your QA process, is in production, and backed by your entire monitoring team. A project with a new query written against your database has to go through your entire QA process. I’m just sayin’.
• More Developer Friendly API: As your developers hit your API for Hackathons and personal projects, they will find bugs and errors in your documentation. Don’t blame QA, your developers or your tech writers. This happens. This is a good thing and it gives 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.
• Fix Old Problems, Create New Features: 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. They will be able to solve problems that business owners might not even know exist and 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.

Encouraging developers within your company to use your public API not only for roadmap projects but also for fun will pay dividends in both happiness and innovative tools. And when outside developers see the results and that you are committed to your public API, then they will be more confident in coding against it as well.

Executive Editor Adam DuVander interviewed the author about internal API usage at Future of Web Apps. The video interview is embedded below.