TEI 180: Why and how APIs should be managed as a product – with Bryan Hicks

A different type of product, but traditional product management still applies. Today’s topic is the product management of APIs — application program interfaces that enable software systems to share information and interact. In the past I have thought of APIs as a part of a software system. It’s another activity on a project schedule to complete in the process of creating a software system that needs or provides an API. Our guest convinced me to think differently about APIs–to think of them as a product and to manage them as such. He has been involved in a few API projects, currently working for Ford and creating an API for Lyft (and others) that will be used by autonomous vehicles. Our guest is Bryan Hicks, senior product manager at Ford Motor Company. He has also worked at SAP, AT&T, and has been an innovation consultant. Even if you are not a software product manager, I expect you’ll find the discussion valuable, particularly in examining the different categories of customers for a product. Summary of some concepts discussed for product managers [2:16] Tell us about the work you are doing with Ford and Lyft on autonomous vehicles The plan is that Ford will own a fleet of autonomous vehicles. We could try to build our own applications and customer networks, but Lyft already has both of those. We’re using APIs to connect to Lyft’s network and fulfill their rider requests with our vehicles. We’re also leveraging partnerships with Postmates and Domino’s. [4:02] What are APIs and why are they important? APIs allow different pieces of software to talk to each other. It’s a contract between two applications for information sharing. [6:09] When you treat APIs as a product to be managed, who are the customers? There are three distinct customers: The developers who code with it, the person who pays for the developers to use API, and the end users of the applications using the API. Product managers need to think about all three customers or else the integration will not be successful. The developers need be interested in using it, the people paying for it need to see the value, and it needs to be valuable to the customer. In the case of Lyft, they want a self-driving vehicle and the API is how they get it. [9:40] How do you respond to change requests in a way that works for you developers? You have to think of an API like a contract and avoid changing it as much as possible. Machines don’t readjust when you change the API. Instead, we focus in incremental capability and adding new features that don’t require additional coding. The more versions you have out, the more you have to support. If you do create a new version, you need to communicate that the new version is not being supported so people aren’t caught off guard when their app doesn’t work. [13:50] How do you balance solving your customer’s needs while encouraging open innovation? There are internal APIs, private APIs, and public APIs. You typically start internal, then move to private, then move to public. This allows you to understand what your customer wants without breaking that contract. For example, Twitter’s API was public but they saw people were using it to build better apps to access the platform, which drove people away from Twitter’s website. This lead them to pull back the API and they received a lot of criticism for it. [18:45] What are the advantages of thinking about APIs as products? APIs allow each of the companies involved to focus on their core competencies. For example, Lyft is not a vehicle manufacturer and Ford is not a ride-hailing company. APIs allow us to connect our individual strengths to achieve a shared goal. They’re the SaaS equivalent for people who are building applications. [20:45] How do you distribute an API? My boss,