Subscribe: Google Podcasts | Stitcher | TuneIn | RSS

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, John Musser, developed a presentation on all the business strategies you can use for launching APIs. The most important thing to remember is that you’re not selling the API itself,  you’re selling data or functionality. The pricing strategy should match the pricing of whatever industry you’re working in. What’s the value the customer will gain from the API and how do you match your pricing strategy to that?

[23:51] What is your role as an API product manager?

I try to make sure everyone is aligned about what the interface is going to be. Then, everyone can go off and build their parts with the same big picture goals in mind. API product management is still product management at its core — you still have roadmaps and timelines. The big difference with APIs is that you’re not focused on the design like you would be with physical products or technologies. As long as the API does what you want it to, you don’t care as much about what it looks like. You also have to be able to set expectations, keep your target customer in mind, and say no to scope creep when you see it happening.

Useful link:

• Connect with Bryan via his LinkedIn profile
• John Musser’s API Business Models video

Innovation Quote

“Never jerry-rig something so poorly that it can’t be permanent because it probably will be.” – Stephanie Getty, NASA mentor

 

Thanks!

Thank you for being an Everyday Innovator and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help a fellow product manager by sharing it on your favorite social media network.