API Product Management 101 | Kamal Kannan | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

API Product Management 101

teacher avatar Kamal Kannan, Product Manager

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

30 Lessons (52m)
    • 1. Introduction

    • 2. The Case for API Products

    • 3. Examples of API Products

    • 4. What&why a product manager should know about APIs

    • 5. What is an API

    • 6. How do APIs work

    • 7. What are webservices

    • 8. What is a REST API

    • 9. Elements of an API

    • 10. HTTP Methods

    • 11. API Request and Response

    • 12. Data(Payload)

    • 13. API Header

    • 14. Bonus lesson - Webhooks

    • 15. The API Product Mindset

    • 16. API First and API Lifecycle

    • 17. Building a Minimum Viable Product

    • 18. API Product Design, Development and Release

    • 19. Driving adoption through intuitive developer experience

    • 20. Metrics that matter

    • 21. API Versioning

    • 22. Pitfalls of a poorly designed API

    • 23. The value of a well thought out API

    • 24. Who form the API team

    • 25. Introduction to API Pricing Strategies

    • 26. API Pricing Options

    • 27. API Economy Stakeholders

    • 28. API Pricing Free

    • 29. API Pricing Developer Pays

    • 30. API Pricing Developer gets paid

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

I have been a Managing Products for nearly a decade now. More recently I have been managing API products for the transit industry.

As Product Managers, it is often not easy to understand technology and for those getting started it might even be a little over whelming. If not anything you should at least be really comfortable with the world of APIs. Because you might either be consuming an API for your product or exposing you API for third party consumption.

Through this class, I intend to deconstruct the world of APIs for Product Managers.  you'll learn the basics of APIs, the technology behind it, Product Management for API products and Pricing strategies. 

Even if you're completely new to Product Management Concepts, you’ll find these simple and effective concepts and techniques easy to understand and apply in your path towards a career in API Product Management!

Meet Your Teacher

Teacher Profile Image

Kamal Kannan

Product Manager


Hey there! I'm am an experienced Product Manager who has managed products for companies based out of India, the USA and the UK. 

Early on in my career, I got exposed to the concepts of Design Thinking as a part of Intellect Design Arena, who are pioneers in Design Thinking in India. Since then, I have successfully applied design thinking concepts in solving complex problems and coming up with innovative product solutions.

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Introduction: Hi everyone, I'm coming. I'm a product manager based in the UK. Of all the products that are managed in my career. The most challenging of them have been API products. And more and more companies are starting to look at APIs as products. For example, if you visit a company in the world, be PayPal stripe, Facebook, Twitter, or any company. You would find rules for API product managers or developer experienced product managers. But how do you prepare yourself for these roles? What was challenging for me as I was starting out was the lack of a centralized resource which talked about APIs specifically for product managers. Now this course, my attempt at simplifying APIs and make it more understandable for anyone starting out newly in the world of APIs and product management. So how, how I structured this course? We'll first start by understanding a few examples of API products. Then we'll get into the fundamentals of APIs. How do APIs really work? What is the technology behind APIs? We'll also look at an example of using an API and through Postman. And then we'll get into product managing an API. How to get into the API product mindset. What is the lifecycle of an API? How to go ahead and build, measure, and grow API products. And then we'll get into the roles and responsibilities of the API team as well as the API product manager. And finally, we'll look at the business model. How should APIs be priced? What are the different pricing options available for us? So hopefully at the end of this course, you'll have a fairly good understanding of what APIs are, why they should be looked at as products, and how to go about managing them as products. Thank you for listening and hope to see you on the other side. 2. The Case for API Products: Hi everyone. By now hopefully you would have a fair enough understanding of what is an API and what does IT technology behind it, and what are the different types of APIs and so on. Let's now look at the case for an API product. Why should you start looking at APIs as a product early on as the software industry was evolving traditionally applications and built a standard rule applications. You might have a system for human resources. You might have a system for managing payroll. You might have a system for managing sales. You might have a system for managing marketing and so on. So each of these systems where essentially siloed applications, but eventually there was a need for these applications to talk to each other, and therefore, interfaces were being developed. And then teams realized that instead of building the applications first and then thinking about interfaces later, they should start with an API first approach, we'll try to build microservices that can be consumed by other applications and so on. Therefore, you had private APIs where the different teams within the company within consume these APIs so that the systems can request for information from other applications easily. Now, eventually, smarter companies figured out that APIs are much more than theirs. And APIs can be looked at as products themselves. For example, you can use your Google Maps as a standalone application in your browser or in your mobile phone. However, Google also has an API, Maps API, which is available for public developers can use this map to API and then create innovative products around them. For example, your ride-sharing applications like the Uber and Ola has used the Google Maps API to provide intuitive customer experiences. Another good example is PayPal. You can use PayPal for sending money, receiving payments and so on. But people also has API which businesses can use to integrate PayPal payments into their website through using which users can start purchasing the left side. And PayPal makes a lot of money through these APIs themselves. Companies like Expedia are said to make at least 90 percent of the revenue just from APIs. Ebay set to make about 60 percent of its revenue from APIs. So APIs need to be looked at as products in themselves where you understand the specific customer need and build APIs that can serve that customer journey. So that's where APIs need to be looked at as products. And APA product management comes into picture. Thank you for listening and hope to see you in the next class. 3. Examples of API Products: Hi everyone and welcome to this class and pull, I want to give you a quick overview of what is an API product. I won't do that by showing you a few examples of popular API product. And obviously we're going to talk about the technology behind the API. What is an API and how does it work? And what is API product management and so on in the coming classes. But before we actually get into the details of that, I think it is important for all of us to have a shared understanding of what is an API product. So let's look at PayPal for example. So what is PayPal? Paypal is a product that helps us make payments or receive payments from somebody. So they have a beautiful UI based product that many of you might have used. Also have APIs. So they provide, so she'd look at their website. There is a section called developer, and if you click into that, that provides all of the APIs that third party developers can use to integrate into paid, paid off. So if you click, so it has documentation for the different APIs. And if you click at API, you can look at what are the different APIs at the how, how do you actually log into the dashboard? How do you get the credentials to access the token? How do you make the API calls? They have a sandbox, essentially it's a test environment where you can test the API and they have a few examples. So all of this is meant to help third-party developers understand more about the APIs, the capabilities of the APIs, and then start consuming the APIs. So that's one example. The another great example is Twilio. Twilio is very well known for their API based products. Again, any popular application Pablo product that you see these days would have a section specifically meant for developers. And Twilio also has a section for Delta Force and it has some of its popular APIs. For example, it has a WhatsApp API. Let's click and see what it actually has. So again, it's a documentation. It has neatly tells how do you get started as a developer? How can you get started with this API? What are the reference, what are the guides and tutorials for you to start using this API? And it essentially helps us start consuming the API easy. Likewise, they have multiple products which have all been exposed to as APIs. They also have software development kits. Again, these are libraries that as a developer you could easily use and start building the applications. And only they have separate development kits for Android, iOS, and so on. So let's continue and look at Google's API. So as you might know, Google Maps, for example, is a product that anybody can use for free. So you install the app in your phone or you can open the Google Maps application in your browser and then start using the Maps application. However, Google also provides an API for third party developers to start using them. For example, ride-sharing apps like Ola, Uber use the Google Maps API to provide Maps integration as part of their own application. So anybody can start using this KPI. So they have a website called developers dot google.com. Then that is specifically meant for developers. We want to use Google products specific use case. And now let's look at the documentation here. And again, this also tells us how easily you can start with using the API. How do you set up your project? How do you enable the API or SDK? How do you get the API key, and so on and so forth. And then they also tell how, how to choose an API. So if you wanted to add a map to an Android app, then you use the Maps SDK for Android. Similarly, they have different use cases and the specific APIs that you can actually use for these different use cases. Let's also look at a specific API and d, d, let's say you have the Roads API. Let's look at nearest API. So this is one API endpoint and the nearest roads this API will, this is the endpoint that you will hit. These are the query parameters that you will use to actually filter your results based on what your need. And this is the API key which you will send. So this is the specific API that you'll use. And this documentation tells us what are they different examples. If you wanted to use this through Java, Python, Ruby, Go and postmen and so on, can also run this in postmen, which is a very popular application for testing your APIs. We'll see how to do that in the later classes. So this is how the response looks like and so on. So essentially what we've seen across these three different products is that even though each of these companies have very successful products in themselves, they also take extreme great care into exposing APIs to third party developers. Therefore, often these companies would have dedicated product managers who manage these experiences around these APIs. Because the developers who are going to be using this API are the real users of this product. Product managers need to really understand what is it that the developers want? What are their pain points? What are the specific use cases for which they could use an API? Built not, and not just build APIs, but also build the developer experience and object. Essentially coming up with documentation, coming up with examples, coming up with sandbox environments, essentially come up with all of the supporting details to help developers get up and running quickly. So that's what API product is. Essentially is it's not just the API, but also the developer experience around it. Hopefully that's given you a fairly good understanding of what api products are. Don't worry if you're still not fully confident. Don't worry if you still feel a little lot as we move through the course. So you'd have a much better understanding of APIs and API product management. Thank you for listening and hope to see you in the next class. 4. What&why a product manager should know about APIs: As a product manager, you're going to be invariably involved in the usage of APIs from one real mother. The following are the three different scenarios in which you could be involved in the usage of APIs. Firstly, you could be dealing with internal APIs that different teams within your organization use for shared use cases. Secondly, you could be consuming a third party API as part of your product experience. For example, if you're an Uber product manager, you could be using Google Maps API for your own use cases. Thirdly, alternatively, if you are a Google product manager, you might be exposing a Maps API so that it can be consumed by third party developers like Uber in order to use own use cases. So it is important for product managers to understand more about APIs. And more and more companies are looking at APIs as products and they're constantly on the lookout for API product managers. So what is it about the APIs that you need to really know about? Firstly, you need to know about the request and response to various HTTP methods. The end point, what elements constitute a message? What is a header, what is authentication? What is a payload? What is a RESTful API, and so on. So in the coming lectures we're going to look at exactly this so that by the end of this section, so you'll have a fairly good understanding of an API. Thank you for listening and hope to see you in the next class. 5. What is an API: Let's start with the fundamental question. What is an API? Api stands for application programming interface. And in its simplest form, it is basically a technology that helps connect to different systems. And API makes it lives of developers simpler and easier. It, it helps them connect to a third party systems and utilize their functionality. Instead of building the functionality from scratch, it helps companies go to market faster. It helps companies leverage existing services and so on. Very popular example that I have quoted earlier is the use of ride-sharing apps. And ride-sharing apps. You need maps to help the writers, as well as the consumers, easily know where a particular way colors and how to reach a destination a certain amount of time. And therefore, instead of building a maps application from scratch, they consuming API from a third party provider, for example, Google, so that they can use the Maps application is part of the existing user journey. Thank you for listening and hope to see you in the next class. 6. How do APIs work: So how APIs work? A popular analogy that is used to explain APIs is the restaurant analogy. Let's say you are hungry, you go to a restaurant and you want to order your favorite food. So you start looking at the menu for the various options available to you. Then you pick a specific option that you really need. The request to. The greater, the waiter then goes to the backend, tells your request to the kitchen, and the kitchen processes all of your food, and then it gives it back to the waiter, who then comes and gives the food back to you and you're happy and start eating. Apis, in a sense, work based on this request and response architecture. So if you want to see your favorite video, what do you do? You go to YouTube and give a request to YouTube to play your favorite video. Youtube then goes back to the database, fetches the video that you actually requested for and response to you back with that video. So there's a request and a response in the restaurant analogy, a menu is equal to the API documentation that tells you clearly what the API is capable of. Then the request is what you give to the system, and then the response from the greater is equal to the response of YouTube. So essentially, at its fundamental level and API consists of request and a response. What does each request contain and what does each response contain? What are you going to look at in the coming lectures? Thank you for listening. 7. What are webservices: Now if you heard about APIs, you might also have heard about web services. What are web services? Are they different from APIs? Let's look at them. Now, web service is an API that you can access over the Internet. But an API can also be an interface between two systems which are not connected over the Internet. All web services or APIs, but all APIs need not necessarily be web services. Now, when it comes to web services, there are majorly a few different types of web services. Soap, JSON, RPC, XML, RPC RESTful API. Now, instead of looking at all of these different services in detail, what I'd rather do is focus on RESTful API because that's more common and that's something that you would have heard over and over again. And if you really understand the RESTful API, you'd probably be able to pick up any different kind of API in future as well easily in so in the following classes, Let's look at RESTful API in more detail. 8. What is a REST API: Now let's look at what a RESTful API is. Now rest stands for Representational State Transfer. It's an architectural style that guides developers into building APIs. So it's a set of rules that help developers build APIs. Now. And its simplest level of arrest architecture in was a request to be sent over the Internet using HTTP methods to get a response. You've seen this using various examples before. For example, if you're making a request to you, the YouTube app, you made that request through the internet and you get a response as a video. Now, what elements constitute request message? What are the different types of HTTP methods, and how does a response looks like? These are the things that we're going to look at incoming sections. 9. Elements of an API: Let's now understand what constituted the elements of an API. And there are five different elements of an API, which is a request response method, header and a body. Now what do each of these elements mean? We're looking at an incoming class. 10. HTTP Methods: Now let's look at the different HTTP methods. So when you make a request or the Internet, you use HTTP methods to get the relevant response. Now let's look at the restaurant analogy. You've gone to the restaurant and the first thing that you do is get the menu from the waiter. Now, the act of getting is a method. Similarly use different methods to get the appropriate response from the web service. So the common HTTP methods are post, GET, PUT, and delete. Now if you're familiar with database, you would be familiar with crowd analogy where c stands for create our four R3, you for update, D for delete. Now similarly, each of these HTTP methods perform these functions. For example, if you use the GET method, you are requesting for information from the server, if you're using the post method, you are essentially creating a new entry in the silver. If you're using the put method, you are either updating or creating a new resource on the server. And if you're using the delete method, essentially deleting an entry from the southern. These are the different methods that you can use through the rest API architecture. Thank you for listening and hope to see you next class. 11. API Request and Response: Now let's understand about the request. Now, like we saw earlier, you make a request using the HTTP method to get a response. So how did you send a request? You sent a request to a URL and you also send the method that you wanna do. You wanna get, put a post or delete doesn't send the header and body information as part of that message. And whenever you talk about URL, what does the URL class you do? You already constitutes the protocol. In our case, it's heterotopic protocol. We are sending it through the Internet. Now. The second one is the domain, the website where the resources are hosted. And third one is the path. And finally is the endpoint that we actually want to hit that are going to be multiple different endpoints which return different responses. So typically a URL consists of these things. So request is made to a URL with a specific method, with a body and a header. Now let's look at a response. Let's say you made a request, you may request and you're gonna get a response from the API now request and a response of pretty much the same, except a response does not have a URL or a method. Instead it has status codes header, and the body, when you make a request, what you need to know is, has requests being successful, did you get what you're looking for or has there been any error? So they're undefined statuses that you will get in the response from which you can know whether your request has been successful or not. And then it will have a header and a body. Let's look at that in the next sections. 12. Data(Payload): We've seen that body forms a part of the request and response. What do we mean by body? By body, we essentially mean the data that you send to the API and also get from the API. It's also called the payload. So if you're a developer says to you that what does it appeal or look like? Essentially what they mean is they want you to look at what's the data that you've ever sent or received from the API. Why do you need to send data through your API? Let's say you're logging into your web application. The username and password is the data that you send in order for the application to recognize you and authenticate and log you into the application. So the data is typically sent in either JSON or XML format. Now, these are ways of representing your payload. So what does JSON mean? Json means JavaScript Object Notation essentially uses objects to define the data within them. In the day-to-day is defined using key value pairs like this. And it can also represent arrays using square brackets like this. Alternatively, you can also represent data in the form XML. Xml uses opening and closing tags and then values within that, and it uses nesting to represent arrays. So these are two popular formats in which requests a centrum response I've got from your API. I'll provide links to resources to know more about JSON and XML for the purposes of this course to be good for you to know that request and response are sent using the body is also called the payload and the format in which the ascent, typically our JSON and XML. 13. API Header: Welcome to the last part which is the headers. But when you send your request to the API, can be API give the response to her is asking. So it shouldn't be so a check if you have the right to request for information. So that's what authentication is all about. So you can send a few additional information using the header of the message. So we're going to discuss about two important information that you send. One is authentication, the other one is Content-Type. Let's first talk about authentication. There are a few different authentication schemes that are available are popular ones are basic authentication, which is essentially using your username and login to authenticate. The other one is API key, where you send unique API key along with your request. And third one is for now discussing about how these different authentication mechanisms work is beyond the scope of this course. These authentication mechanisms allow the server to check your credentials and confirm whether they can actually respond with the requested data or not. The next one is the content type. So we saw earlier that you can send a payload in different formats, for example, JSON and XML when the client sends a request, it can also tell the server what kind of data you can accept that. So we can also use the header to mention what kind of content type the data is in. The header can be used for supplying additional information like this as well. So that forms all of the key elements of an API. Thank you for listening and hope to see you next class. 14. Bonus lesson - Webhooks: Hi everyone. In this bonus section, let's look at what is a webhook. So webhooks behaves slightly different than what traditional APIs behave. They are sometimes called as a reverse API. And as a product manager, it's important for you to understand what web hooks are and where you might actually use them. So let's look at that using a scenario. Let's say one integrated with PayPal. Every time someone makes a payment to you in paper, you want PayPal to notify you so that you can ship the product. Now there is two ways you can do that. One as you can keep checking PayPal, if a payment has been received or not. Paypal has APIs. You can subscribe, you can hit that API, get the list of responses and see if there is any new payment that has been recovered. Now, you could do that multiple times and whenever you find a new payment in the response, you could then trigger your own internal process in order to ship that product. But the process of checking the API, requesting a response to the API multiple times is a waste of bandwidth, as well as your system and sources. And not just that, many of the API providers are going to have limits on the number of times you can actually hit the API. So every time you're going to be hitting the API, you're consuming your limits. So that's not an ideal way, would actually be better if PayPal can itself tell you where a payment has been received so that you can then make sure that the delivery of the products. Here though, you are the third party who's dependent on PayPal. Paypal has so many different consumers. How can they then efficiently notify and specific consumer often event. So that's where their hooks come into picture where books are very useful when there is a change in status or changing event. And a notification is expected from a specific provider based on which you want to kick off your own process. So PayPal would have a webhook interface where you would tell which URL that PayPal has to send the specific event notification to so that you can then wait until the notification has been received and then kickoff your own process. So unlike an API where you request and then get a response in a web hook, that is an event and then based on which response is then provided. So typically it will be a post message that PayPal would do to specification HTTP endpoint. And that's what I hope it was all about. To further read more about web hooks. I have attached a few resources in the lessons. Please feel free to check them out. 15. The API Product Mindset: And this glass, we're going to understand why it is important to get into the mindset of looking at APIs as products and sort of projects. Now before we do that, let's start with looking at how APIs generally a wall in the company. Now, take an example of the Hilton hotels. They have a bunch of hotels all across the world. Typically what might have happened is a customer might reach out and ask the hotel employee if, if they can book one of the rooms for a certain period of time. So what the person at the end of the counter would, might do is get a list of all available rooms, give their pricing information, make a reservation, and then get the payment from the customer. Now, as technology would have evolved, you have multiple different channels evolving like web application for Hilton Hotels and by application. Now, instead of replicating the same process for each of these different systems, what they might have done is a platform api identified four different APIs and API for getting the list of all available rooms and API for getting the pricing information for the rooms and API for making a reservation and then getting the payment from the user. So these four APIs could have been consumed by these different channels. And therefore, there is a benefit of creating internal APIs for the Hilton group of hotels business. And someone smart from within the company might now have figured out there are other companies who could leverage the APIs for Hilton Hotels and then book rooms for Hilton through that applications. Now companies like Expedia consume these APIs and then allow users to book hotels through their application. So it hasn't has more revenue through a new business opportunity. Now I'm further more creative developers and they could possibly be looking at allowing users to use Amazon Echo or Google wise assistance to make a hotel reservations through using zippy. And so there's a new channel and the business opportunities are exploring manifold. So that's the benefit, exposing APIs to wider market. And that's why, because APIs, so all of the specific needs of a specific set of end-users and also provide the opportunity to drive business growth. They should be looked at products and not projects. Traditionally, how APIs have evolved, because they are built for internal audiences. Most of the time, they are looked at as projects. You know, the business need, your use cases are pretty much fixed. So you start building the APIs with a specific end goal in mind. So you always look at building them as projects. You're not thinking about a 100 different customers with multiple use cases. However, that's typically what's going to happen once you expose these APIs to the end-user. If you don't, this product mindset, what might happen is you might build out an API as a project, and then you expose all of the APIs to the third party developers. But you might find that none of them have actually used it because they really didn't have a need for it. And therefore all your efforts has gone down the drain. So therefore, it's important to look at APIs as products. So you need to start from understanding the users. What kind of problems do these developers have? How could my API is actually helped them and then come up with a small MVP of an API, launch it into the market, validated, test it and the nitrate and keep improving it. So you need to get into the product minds it to truly be successful in launching your API product. 16. API First and API Lifecycle: In this class, let's understand what is meant by API first strategy and also look at a typical life-cycle of an API product. And what is API first? Now we've all agreed in the previous class that you need to get out of the project mindset. I'm getting to the product mindset when it comes to building APIs for third party users. So if you have 20 internal APIs, you can't just expose all 20 of them to the end-user. So they may go unused because the end users might not really have a need for these APIs. So API first strategy essentially means that start with designing and API contract before actually implementing the API. And then try and validate if this API is actually going to be useful to our end users. What this means is you're going to get early feedback. You're going to identify gaps in your business processes or your technical details. And you'll be able to fix them fast before you actually implement the API. And because you're starting with understanding the users and looking at it as an API for end-user first, you more often than not, you'll have an API that will actually be used and adopted by an end-user. So with that understanding, how does the typical API product life cycle look like? So let's start with design. Then you'll go ahead and implement an MVP. So you'll build IT, security, tested, release it, monitor it, and then I trade on it, and the whole process repeats again. So you might see that how it's pretty much similar to how a traditional product lifecycle also is in an agile world. 17. Building a Minimum Viable Product: Now let's look at the importance of MVP when it comes to API products, when it comes to managing traditional products, the importance of MSPs, well understood. I don't think API products and any different when you're going to the market the first time with an API is important to look at it in terms of MVP, because it's important for you to go to market fast with a value proposition that developers would love to adopt and then learn from it, and then I trade upon it as early as possible. For example, if your L, you might have so many business processes backend. For example, you could have APIs, internal APIs for getting the list of all restaurants in a specific location. You might get list of all restaurants which are five-star and above, get list of restaurants with the user reviews in a specific location and so on. But is it important to expose an API with all of that complexity? Or is it important to go to market with less complex solution, but we shouldn't really be valuable. For example, if you're gonna expose an API which provides a list of restaurants by location, is it important to give all of the various query parameters that important to give all of the responses in the payload, perhaps not. So it's important for you to look at what is an MVP so that you can go to market faster and how developers adopt it and then learn from it and test nitrate on it. Remember all of these are experiments and not all of your experiments are going to succeed. Some of your MVPs may fade. But remember that MVP with succeeds could open up entirely new business opportunities and policy a go to market and get data, the better will be an argument to give business justification for additional investments, right? Reading on that part. 18. API Product Design, Development and Release: And now that we have looked at the importance of an MVP for an API product, Let's look at how you actually design something and launch an API product. The steps involved are slightly different when compared to traditional product. Traditionally, what would you do if it's possible you would want to build a clickable prototype using something like in revision of a frontend application and then show it to some of your users or use it, review it before you actually go ahead and build the application. So when it comes to APIs, you might wanna do something similar to that. So the design document, the API specification document, is what helps with us to design the API first Hand, where you can tell what the specifications of the API will be, what will be the request and response? What will be the endpoint that you will hit? What are the various query parameters that you will support and so on. Now, with the design document ready, you could then have it reviewed to ensure that it will provide uniform Databricks prevents it does does an API conform to our previous APIs is odd naming conventions, the versioning, everything consistent with our standards. Are you using any jargons? What kind of naming are we actually doing? Are we using nested structures for future extensibility? I'll be using enums, two Booleans for new properties. For example, if the response has a status column which says a yes or no as a binary state is, you'd rather wanted to be success or failure if needed in the future at an intermediary state is calling frog in progress, so, so on and so forth. So the review process is going to be very helpful to actually iterate on the API designed to get it wide before it's actually implement. And once you've done that, the next step would be to do user testing, where you will use this to test with a select set of groups to check if the API is actually going to be usable. You might also want to build an API and expose the first version for experimental usage. A typical way of using this would be dog fooding. You might want to release it to your internal users. For example, your staff first, ask all of your staff employees to start using the API and provide feedback. And we also set up interviews some other third party developers with whom you have trade relationships. Third party developers to really understand the API is missing something. Once you had all of these and I iterated build the API, you might go on with an early release beta released to all of the users. Or you could do gated release where you put the API behind a gate and allow access to specific set of users to understand more about how they actually using it. If you really want to make any further changes before actually going for a general availability release. So that's pretty much the lifecycle. And that's something that you need to keep in mind. Whenever we start building a new API. 19. Driving adoption through intuitive developer experience: Once you've got an MVP out there, the next step in the API product lifecycle is to drive adoption, measure. It is usage, and then I trade on it. And how do you drive adoption? It's the first key step for driving adoption is to have a great developer portal. Because your end-user for the API at least is your third party developer. So it's important for them to be able to understand everything about the API easily by looking at the documentation. So you need to have great documentation, great user guides, a sandbox environment for them to test it. Example, use cases, maybe forums. There are so many different ways that you need to think about it as to how you can make the life of your developer easy. So developers typically not going to spend a lot of time in your developer portal initially when he's researching about the API. It means to be very simple and easy and intuitive to understand so that they can get up and running as soon as possible, maybe even 30 minutes. So it's important to invest a lot of time in making the developer experience great. So you need to have a great developer portal Thanks to you next year olds and need to focus on evangelizing your API. What do I mean by that? If you think that you're going to just build out an API, put it out there, and people are just going to come in and adopt it. It's not going to happen. You need to send the value proposition appropriately tool the dashboards so that DID can, they'd be really interested in using the API. It doesn't matter. The API has an internal API or an external API. Even if your developers, even if there are internal users for the API that you're building within the organization is important to sell the value proposition, right? So they can adopt it. So join conferences, conduct webinars, take the message out to sell the value proposition in the right way to your users. And once you have enough adoption, measure, how people are using it. Are we actually meeting the needs of the user? Is it secure enough? So trying to understand and supply to measure metrics. So how do you measure metrics and how do you know what to measure? So you need to define the key performance indicators. And that's what we're going to look at in the next section. 20. Metrics that matter: So the next step in managing a VM products effectively is measuring metrics that really matter. So to do that, you need to identify the key performance indicators of API. So first, think about what is the purpose of your API really? This is your API meant to drive direct revenue to your business. For example, people make purchases through the API so you expect your monthly revenue to actually increase, or is it about driving direct revenue? Where by exposing an API that provides the reviews of a specific restaurant, you expect more customer visits to the restaurant page on your website, and therefore, more reservations to the restaurant from your website, and therefore the revenue increases. So here the metric could be a number of new users registered through the API or number of restaurant use through the API and so on. What is the purpose of your API to drive new business opportunities? Or is it about increasing your size of developer users or increasing the size of your partner ecosystem. So it's important for you to really understand what's your key business driver for this API and therefore, and then determine the appropriate not Star metric. And the other one could be to also track the usage of the API. For example, our developers using the API the way it is intended, how many times they are calling the API, what query parameters are they using the most? And do they get the response that they're looking for more often than not? And also track the developer experience through the portal. They it will get register and get the API key fast. Are they able to get up and running faster? So tracking all of these metrics is going give you the feedback that you really need to do one, identify the APIs that really achieved a business metric and therefore focus iterating and improving the API to also look at the developer experience. How can you make the developer experience more enjoyable? What part of the journey define more friction? And then it'll also help you with your monetization strategies. So it's important to get early feedback so that you can track these metrics for a new API, it's going to be important. It's going to be difficult to get that feedback that they need. So you need to use your connections to get those early developers on board. So that's where the API evangelism really comes into picture. Organizing hackathons conferences, reaching out to your partners and so on are ways you can actually get the API adoption started. 21. API Versioning: Hi everyone. Let's now look at API versioning. Now, when it comes to Versioning, it's pretty much straightforward for traditional products. And many times whenever you release a new version to the end users, they may not even notice that aversion has been made because versions are often small and frequent. So one of the key principles of Vijay's to make frequent and small releases so that you can learn from the users. Apis would be very difficult for you to make newer versions of APIs. This is because think of how APIs work. You release an API to the third party and third party one or more third parties would have integrated into the API if you're making a new version of the API, which means that all of the existing third-party users would have to make code changes so that they can now point to the new version of the API. So, so careful thought process should be paid. Before releasing a new version of an API. You could pick enhancements to an existing API as long as none of them are breaking changes. So when should you consider a new version? So it would be when there is a breaking change to your consumers of the API because of enhancements to the API. What do I mean by breaking changes? So you're sending a few details in your API response. Now you'll finding the payload to be too bloated and you're thinking that maybe you need to remove some of the responses. If you're removing that, there could be a lot of the QBI, lot of third party developers who might be expecting the response very available in the API. If you're removing it, then dare process could actually get affected. Or let's say you did a change to the URI. So all of these are breaking changes. And if you had to do them, you have to release a new version of the API. Before you do a new version of the API, you also need to think, how long are you going to support the previous version of the API. Because each version is going to have maintenance costs associated with it. So, so you need to, you need to then look at data to see how many consumers are using the previous version of the API and are they willing to transition to the new API? So you need to provide a sufficient timeline how long you'll be supporting that previous version on the APA so that they have enough information upfront to choose to migrate to the new version or not. And so considering the importance of versioning and API, it is also important to communicate upfront and clearly to all of your consumers. Whenever you reason you're washing, you should use your developer portal and all the other channels that are available to you, to the third party developers. So at they're all sufficiently aware, the other important thing that you need to think about is how do you name the version? Now, there are different standards that different API developers follow. Some of them would like to have the version number as part of the URI, say it's version 2 or version 20. Some of them would like to have a date as part of the URI. Some of them would like to provide the version information as part of the header. So there is no one way or right way to do it. But the most common way, the most easiest way would be to provide the actual version number as part of the URI. So whatever format that, whatever standard that you actually follow, you need to have the consistency across all of the APIs from all of the APIs that you actually manage. Because developers will get used to certain way. And if you're following, providing different kinds of warning and they would not know how to look for the latest version and how to consume them. 22. Pitfalls of a poorly designed API: Let's now look at the pitfalls of a poorly designed and developed API. Many companies launch APIs without truly understanding the user needs of the developer needs in the market, what this leads to is a poorly-designed API that is either less adopted or there is no adoption tall. So a lot of the effort and cost that was spent in designing the API, exposing the API goes down the drain. The way to fix it will be for developers to start designing and developing a new API and wiring it back to a back-end system and launching a new version of the API, which is a costly exercise. What would make it worse is if you had some adoption for the earlier version of the API, that might mean that you might either have to move some of these users to the new version of the API, or you might decide to support the previous version of the API, all of which are going to add to your pain and costs. Now another common pitfall is exposing an API with a poorly designed back-end system. Back-end system could have legacy architecture business processes that have evolved over time and have not been optimized for efficiencies. So if you are going to be exposing an API which is going to be less easily understandable and adoptable and scalable. And then it is going to lead to very poor adoption. So the only way to fix this is to start with understanding the user needs and then designing well-defined API upfront. 23. The value of a well thought out API: What are the values of well-defined API? Now, API is if you go to market with a well-defined API and that is greatly adopted, it will lead to new business opportunities for your company now created a third party developers could use your APIs in ways that you never imagined was possible. For example, when the Maps API was exposed, they wouldn't really have thought about a use case of a restaurant delivery application using maps to actually showcase when the delivery is going on right? Now. That is a new business opportunity for the Maps Developers and it creates increased revenue. And another thing is a well-defined, easily understandable API is going to have networking effects. Additional third party developers are going to look at successful adoption of one use case and then come in, create multiple other use cases. So you're going to have increase in revenue, new business opportunities developed, and your business is gonna grow that much more. 24. Who form the API team: Hi everyone. In this section, let's look at the importance of the API team and who forms the API team. So the API team typically consists of the API product manager, the API architect, API developers, and APA evangelist. Now in many organizations they may not be a dedicated API team, but increasingly, organizations are understanding the importance of having a dedicated API team, having the product mindset and building APIs as products. So APA product managers are key piece of this team. In the following few lectures, you learned that you understand specifically about the roles and responsibilities of an API product manager, the architects, developers, and the APA valueless. Thank you for listening and hope to see you in the next class. 25. Introduction to API Pricing Strategies: Now let's turn to a very important part of API product management, which is APA pricing strategies. How do you monetize your API? Firstly, what is monetization? To put it simply, it's about making money through your API. And the way you make money, it could be very different. It could be that every time someone has to use your API, they need to pay you and therefore you make money. So it's a dyadic revenue. Or it could be that every time they use an API and make a purchase of your product or service, you actually make money. So there could be direct revenue implications for the API. That's one business model. The other one could be, you could offer an API for free because it's going to indirectly benefit your business. For example, Google and Facebook might offer usage of their APIs because they get more customer data, which isn't directly going to help them provide more personalized services to their customers. So likewise, it could be several other indirect ways in which API usage could affect your business. So essentially that's what monetization is saying. The coming sections, we're going to discuss some of the popular pricing strategies for APIs. 26. API Pricing Options: When it comes to monetization strategies for APIs are essentially four. So there are typically four different ways that companies price APIs. One is free, there is no price for use in job the API. The next is the developer pays for the API. The third one is the developer gets paid for using the API. And the last one is indirect business opportunities. 27. API Economy Stakeholders: So before we look at the specific pricing strategies for an API, let's first understand who are the stakeholders in the API economy. So first, this is the API provider. Essentially this is the business has decided to expose a bunch of APIs to third-party users, and the stakeholder actually determines the price. And next come, the API developers who actually consume this API and build something out of it and offer it to their end users. So finally, it's actually the end-users who benefited from the API. They don't necessarily see the API, but are really the actual beneficiaries of the functionality offered by the API. In order for your monetization strategy to be truly successful, it's important for the API to be beneficial to all three of these different stakeholders. So what are the price you determined for the API should not only be beneficial to your business, but it should also be sustainable for the API developer so that he's able to provide a value to this end users. So if you say your API is going to cost X amount, but the real value that the third party developers actually getting is less than X amount that is actually paying you. It is not as sustainable monetization strategy. So keep these three different stakeholders in mind when you think about the various pricing options in front of you for your API. 28. API Pricing Free: Now let's look at the first option which is free. Why would a company offer an API for free? So you would offer an API for free for variety of reasons. One could be you want to increase adoption. So near growing new to the market, there wouldn't be anyone who might see the value in the API enough. So you might want to prove the use case for the API and therefore you offer a tree initially, or you could want to retain consumers that is increased competition. So you want to offer API services so that more and more partners that actually partnering with you rather than competition. Or it could be that you're getting something dag benefit. For example, social logins that are available, like go, you can log in through Facebook, sign up through Google and so on. These APIs are often offered for free. But what the benefit that these companies get is more customer usage data. What this benefits the third-party developers is because it offers a very easy way of identifying the user and simplifying the login process. So it's a win-win for all three parties within the API economy. So there are legitimate use cases for when you might consider offering your API for free. 29. API Pricing Developer Pays: The next monetization model is where the developer actually pays for the usage of the API. In order for this model just succeed devalue that the developer gets by usage of the API should actually be more than what the APA is actually being priced for. That's only then the developers that actually consider paying for the API. There are again, different ways in which you can price and API. For example, this could be a pay-as-you-go model, could be a freemium model, it could be a tiered model, or it could be a transaction fee based model. So when you say pay-as-you-go model is developed only pays for when they actually use the API. So every time they using API that actually paste in the mount, a good example for this can be a credit check application. So when you apply for a loan for the bank, bank actually makes a call to the credit check agency and they pay a certain fee for that specific credit check. The other one could be a freemium business model where you offer a sudden a low valued API functionalities for free. While if they want to actual premium functionalities are different endpoints which are of higher value. They will have to actually pay for that API. This is similar to how traditional applications offer Freemium models. This is to get people to adopt their specific API onto used to it and like, and they actually go for a paid version. The third one is a tiered model where, where you might set it here saying that every for 10 thousand hits per day, you actually can pay this much. If you use it between ten thousand, fifteen thousand hits per day, you'll actually have a paid this much. Or if you exceed the tiers that you actually subscribed for, you'll have to pay a really high amount. So, so you can tear the price in a way. And developers could actually pick and choose the deal that they think would be what their actual usage fee. Now the last one is a transaction fee based model. Where will you get a commission for the transaction? Paypal or Stripe or any of the payments application. A good example. So every time you hit a Payments API and made a transaction and you get a certain percentage of fee for the transaction. So these are the different models in which you can price the API. And they are not the only ways you can actually price them, but these are some of the popular ways. 30. API Pricing Developer gets paid: The next monetization model is where the developer is paid for using the API. So this model might be used where you as the API provider are actually benefited the most by the API is being used by third party developer. So you need to incentivize the developers into using the API and therefore you pay the API. So some examples for this is to travel aggregators of flight aggregators or hotel aggregators are actually benefit from this pricing model. For example, every time a sales is done through the specific API IS a hotel operate them and actually provide a commission. Developers because they're essentially acting as agents driving more sales to my hotel. So another popular model is the referral or affiliate model. You might be aware it could be an Amazon affiliate user can drive purchases for products in Amazon, you get a fee for every reference. Similarly, if there is more traffic or more purchases done on your website through affiliate websites, you could incentivize the developers by paying them. Some of the popular examples are, you know, Google and Google AdWords, insurance companies and agents, or in a job sites like Monster.com and so on.