Building an API that Developers Love "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 7 June 2017 True Api, Business Model, Documentation, Sdk, Mind the Product Mind the Product Ltd 689 Maxime Prades explains how to build an API that developers love at ProductTank SF Product Management 2.756
· 3 minute read

Building an API that Developers Love

Maxime Prades (Director of Product at Zendesk) takes you through the experience of building a platform at Zendesk and being part of an API-first company. He opens his talk by describing the clear value that Zendesk’s APIs are providing to their customer accounts and the business. For example, customer accounts using the rest API during their 30 day trial period were converting twice as much. Similarly, the average number of “seats” held by accounts that don’t use APIs is 6. If accounts are using the rest API this increases to 32 average seats. Maxime describes the basics of what an API is, why it is so powerful and what he learnt along the way.

How you would describe an API to a child?

Maxime says he asks this question to everyone from business development to API experts! His favourite description was that an API is essentially a language that everyone understands. I speak French, someone else might speak German. The API builds the frame of reference and lets us understand each other. It’s at the core of every single product decision you’ll make. Similarly, you could also describe it as a bridge that connects two different islands.

Why have an API?

Bridges and translators make things faster. At Zendesk, the first API was provided free by Ruby on Rails and the developers included it as a little bonus without much thought. It was put on the public website and for 6 years this was the API. They then got to the point at which it didn’t scale and wasn’t working.

Instead of scrapping or maintaining it as it is, they rebuilt all of their structure onto a restAPI- becoming an API-first company. They use exactly the same API as their customers and it has become one of their main products. Being an API-first company made Zendesk faster in multiple ways:

  • Microservices, with things like caching webpages, respond to each other faster
  • Zendesk can be wherever their customers are and answer future needs dynamically or customers can self-service their own needs via the API
  • By using their own API internally Zendesk can identify and fix bugs before their customers spot it
  • Developing the API first for any feature forces them to avoid clutter by letting them configure and manage complexity

Maxime gives plenty of valuable advice for product managers building APIs such as:

  • Have a business goal in mind. Maxime describes how they knew the Zendesk API was doing something to useful to the business but they didn’t know what until they looked at the stats. Once they did this they could identify what exact benefits it provided and create a business model around this.
  • Remember that the API will be sniffed. People will be able to find out about it even if you try to hide it. Maxime warns to ignore all the things you’ve read about protecting your API. All the hacks that have happened on major companies have been on private APIs. So even if you decide to keep your API private, make sure you secure your business as you would if it was public.
  • Make it usable. Without standards APIs become extremely painful to use and integrate. Without documentation developers will have no clue where to start. For this purpose, they have developed Double Doc- a library that allows users to write the documentation in the code. This means that every time developers update the code, they’re prompted to document it immediately.
  • Try not to break it. Maxime describes a public API as an implicit contract with your customers and you will damage business relationships if you change it without telling them. He recommends using a developer newsletter and to remember that over communicating is better than the angry emails or account cancellations you’ll receive if they only find out about it when something breaks.
  • Go the extra mile: build SDKs, wrappers, developer tools, a console so they can test API calls, etc. It’s the role of a product manager to think about the end user and how to answer their immediate needs. Don’t build the API and then forget about making the developer’s life easier.

Comments 1

Join the community

Sign up for free to share your thoughts