 Hello everyone. Welcome to this product school webinar about building products that developers love. My name is Abhijeet Natha. I'm a principal technical product manager at Impala and I'll talk a little bit about myself in a bit. Today we're going to spend time talking about what developer products are, what does developer experience mean, and how do we think about developer experience for those developer products but more specifically about API products. A little bit about myself. For those who were in my previous webinar, you will notice a change now. I have recently changed over jobs. But yeah, as a quick background, I had an engineering background for about a decade, performed different roles in various engineering functions. And from there I moved over to technical pre-sales at Twilio helping the customers and developers in IMEA build their products using Twilio APIs. And then I moved over to the product management at Twilio, worked on Twilio Flex and some products on the customer engagement at Twilio. Off lately, I have moved over from Twilio to join a startup here in the UK. The company is called Impala and I'm a principal technical product manager there. A bit about Impala. At Impala, we think that we are going to empower the developers and travel innovators across the world to enable them build incredible travel experiences. We build API-first products and augment them with dashboards and other related tools. So if you think about building a travel experience, you can go and quickly start building the travel experiences there. All right, so going to the topic for today. Products that developers would love. For doing that, we need to first understand what developer products are. What does it mean to build a developer product? So we'll spend a bit of time understanding that. Please feel free to add questions to the chat. I will try to answer them towards the end of this webinar as much as possible. Let's keep this interactive, keep your comments and thoughts flowing through. Put them in the chat and I promise I'll get to them. Okay, so developer products. If you think about products in general, when you create product, basically you are creating value for someone, a consumer, let's say. If you create directly a product that a consumer can consume, then it's straightforward there, right? Like if I build this iPad, which the end user is going to use at to see video, that's a consumer product. But there are a category of products which cannot directly be consumed by the consumer. It requires someone in the middle, a developer to consume and create something out of it that a consumer can eventually consume and get value out of your product there. So that's what developer product means. Now, the definition might be a little confusing if you're not familiar with this. So I'm going to give you some examples. Throughout this presentation, I'm going to talk about developer products through my previous organization Twilio and examples from my current organization Impala. I will also be bringing examples from some of the other developer first companies like Stripe or Played. So none of these are meant to talk about those companies, these are examples of how companies are creating incredible developer experiences through developer first products. Let's take Stripe for example. If you're building an e-commerce website, you might want to use Stripe for the checkout and payment flow. So the product that Stripe is building is a checkout and payment APIs and HDGAs and UIs, which you as a developer of e-commerce company would want to use so that your consumers can take value out of it. In this case, if you were an employee and a developer at Stripe, you are building the developer products here. Those APIs are developer products. If we take example of Twilio, if you are building products that someone in the e-commerce company is going to consume to create customer support, to take incoming calls, to send SMS, then these products at Twilio are developer first products, APIs and HDGAs and programmable apps. Talking about my current organization Impala, here we create APIs that someone could use and create hotel room booking in minutes and create those travel experiences. So the Impala products in this case, the APIs at Impala are developer first products. Hopefully this gives you an idea about what a developer product would be. Now when we talk about developer products, developer experience is a key because your consumer and your users are developers. So let's look at this first before we talk about developer experience. Let's say you're writing creator of a programming language and you create a programming language and you write a bucket documentation and your code looks like this. I'm sure this can be readable and a developer can understand. But this is not a great experience. You're going to put in a lot of effort and it might take a longer time to learn and then understand what this means. On the alternate, if you were to write something like this, looking and reading this is much more simpler. You can actually quickly understand that what this piece of code is trying to tell you is that if your consumer or your user is a developer, then the experience of them is called as developer experience. This is all to say that developer experience is about the developers who are consuming your APIs, your SDKs, your UI components and whatnot. Let's look at the definition. What does it mean? What do we mean when we talk about developer experience? And simply put, if you want to think on a very abstract level, interactions and feelings that a developer has when working with a body of code to meet a specific object. Now if you are the creator of that piece of code and APIs, then the experience and the interactions that developer will have while consuming your code to build their own applications. That's what developer experience is. Here is a slightly different but very good definition as well. What is developer experience about? Why does it matter? It is about minimizing friction from idea to code. How can a developer land at your product, your developer product with some idea and how quickly they can take that idea by using your product, turn it into something that discovers and delivers a business value. So that's what developer experience is. These are like pretty good way to think about developer experience. I've mentioned the source of these definitions. I've not created this, but I really like this way of defining the developer experience. So before we go and talk about how do we create developer experiences, let's look at and understand who is your customer. As a product company, as an organization building developer products, how do you think about your customer? I think in my head, when I'm working as a product manager of a developer product, I think of consumer or end user as the person who would consume the actual end value of whatever will be created using my APIs. But I think of developers as the users and the consumer of my APIs. And with that definition, actually you could be creating a developer product at various layers. You could be creating something at the storage. MongoDB, for example, right? You could be creating API that abstracts away the physical world complexities. We talked about examples earlier, Twilio abstracts away the complexity of telecom infrastructure and exposes that as an API. Impala, my current organization abstracts away the complexity of connecting to a hotel, creating data relationships and exposes that to an API. On top of APIs, there is another layer, which are SDKs. SDKs, just to define, are a layer on top of your pure API layer with embedded session management logging. Like this is the whole software development kit. This will have declarative interfaces. And then you could ultimately have a UI based developer experience in a developer product. UI components, a programmable app, and running across all of these there could be developer tools. The way to deploy a developer product into production. Netlify is a good example that lie in this category where you could write a piece of code and it has tools that you could use to quickly deploy each of your comments and test it. So developer products could lie in various, like each of these areas. The core and the principle, at least in my opinion, area where a lot of developer products are being built today are the API. That's the base. Like you start with that layer, whether you are building any of these. So today we're going to focus a lot about API developer products. So base principles for creating good, great developer experience when building an API products. As you build your API products, you should keep these high level things in mind. So every API product that you're creating should be consistent. Developers should not be required to learn all the new conversations, all the new conventions when moving between products. It should be consistent in its form, in its structure, its reporting, its error. It should be, all those API products should look like they belong to one set of product suite. It should be self-serve. It's very important. Developers prefer helping themselves. I've been a developer for a decade myself, and the first thing as a developer I would want to be able to try something out. So this should be self-serve. You shouldn't have friction to start using and validating your API before a developer can be confident about that. So don't start bringing in your, in my opinion, sales right in the beginning before someone can try and play with your API products. Ungated, similar. When protecting the functionality behind an API, it's okay to protect parts of that, but the functional part of your API, the thing that it should be doing should be ungated so that they can go and validate the idea. It should always be updated. Nothing would put a developer programmer off if while building their piece of code they're using a library API product and they realize that this is out of date. So make sure this is up to date. When they go into your API product, start reading about it, a good developer experience requires that there should be a visible and feasible path to deployment. So bring things into your product that will help them pave through that path and be honest. It does what it says. Product documentation, release notes, change log, read me. They're all consistent with the actual product behavior. So keeping these base principles in mind will enable you create developer API products that have great developer experience. We're going to go into each of these areas in more detail and look at some examples now. So consistent APIs. The examples of how you can think about making your API consistent is mentioned on the right-hand side. The request and the response structures, the error codes, the definitions of the attributes, what it means, the pagination structure, any metadata along with the actual output and the full functionality. These are things, if you treat this as a checklist and you are able to take all of these, you can be pretty confident that your APIs are being liked by the developers who are consuming it. Some examples you would see here. I'm going to show a quick example. There are these two products. One is about messaging. The other one is about voice. And if you look carefully at these two, the structure of them are pretty common. So if I'm a developer and my organization wants to start with sending SMSs and later on add voicemail, I think of moving from a voice product or from a messaging product to voice is going to be relatively smaller. And that's about one of the examples of how your APIs are consistent. API playground. So as you're thinking about developer experience, it is very important that a developer can go into your documentation and be able to play with it somewhat without writing a piece of code as well. So if you are able to create a mechanism when they can go and get an API key rather quickly and try an API right with that key without having to write code, that is an awesome experience. It helps the developer understand and grasp your API rather quick. And some of the example here are Twilio's and Invales dashboard. You can sign up in like two minutes, get API key and try it out right either in the documentation itself. Or in a simple way, you can actually export the APIs in post-minute try. The experience of trying the API right in the documentation is amazing. It just removes a lot of friction. So for example, I mentioned, if you were trying Impala APIs, you can actually paste the API key right there. You've got the parameters there and you can directly try the API in less than a minute. So having an API playground to try your API product is an awesome experience. Debugging. So as you build, I think this is all of us who have developed products would know that as you build API products, also as you build products, you might, you will most likely have some errors. Anything that can help the developer debug quickly is going to be very key in how they like and perceive your product. So think about clear and accurate error codes. Think how they, how can they subscribe errors? Not necessarily in the code, but generally getting information about error. It could be something that is long running or running automatically and there is an error and there should be a way to subscribe it. And if you're giving an error code, I think it helps a lot if your error message has a pointer to the docs, which can talk about what this error code is and what is a potential solution. So think about that whole error mechanism and the debugging experience as a part of the developer experience you're building as well. So as now, now we moved from the ability to build a product and debug it and now thinking about how do, how do you keep your developers informed, informed about changes that's going to happen in your product, right? So status pages, release notes, change logs, alerts, programmatic way of subscribing to warnings, maybe through webbooks. So let's say my simple example, I pay to your API products per API usage and my account balance gets low. Now, this is a clear example where you could actually have information being sent programmatically, maybe they have what to reach out they could set. Maybe there is your quota of API consumption is crossed and then you have webhooks telling them that now you have consumed all the APIs and now developer can do something about it. So making sure that these updates are available, either to the code itself or to the runtime running of the code is very, very important. I'll go to show some examples. Here's status page of various companies. Impala, Twilio, Stripe, Played. A developer can at any point go and look at the status, live status of the systems there and be confident that the products they are consuming is up and running and is adhering to the SLAs. Talked about change logs. So as you introduce new features, as you change anything in the product, having a change log is also very, very, very important. It is a way for a developer to go and see if you've added new functionality, they can consume it. If you're going to change something, that should also appear there as well. So think about change logs and publishing it closer to your product launch is a very good developer experience parameter. Various tools. If you are able to embed tools in your product suite, command line interface, tools for observability and monitoring for deployment. For example, if there's a piece of code that can be customized and directly deployed through a serverless mechanism, that is a very good developer experience and enables and removes the friction for developer to deploy that functionality. So think about these parameters as well. So this is an area which is often overlooked, but it's very important. Developer products with a community around it have more adoption than any other which don't. There are various ways to build this community, write blogs, webinars, YouTube videos, tutorials there, Stack Overflow is a great place for developer, Reddit as well, where developers would go and talk about and solve each other's problem. And when you create this community, you'll realize that your products and the queries for your products are actually solved between the communities as well. And that brings this whole set of developers who are working on your product together and creates a community. Similarly, Meetups, Hackathons, Conferences are a great way to create those community feeling too. So not something every organization can start with, but keep this in mind and as you build your developer products, think about this as a part of your developer experience without ignoring the value it brings. Some of the examples you'll see here, mostly from Twilio in this case, a YouTube channel where you'll see lots of quick stars, how to do things in two minutes and that kind of thing. And then there are Twitch telecasts as well. Now last but not the least is the documentation. This is like the heart of whole developer experience. So making sure that you have detailed documentation. Talk about everything that a developer would need to know in that documentation. Think of it as something you want to write without assuming that the end user knows about it. So be as descriptive as possible. Organize it in the right way though. And so it's easier to go and find and consume that information. Similarly, adding quick starts and step-wise tutorials of how to do a certain thing. If there are like 10 different use cases that your product solves, write those out in detail step. This could include also how do you integrate some other API products, but go and show them the path of taking an idea to a production version of the code. And if you can put the code samples with quick deploy options, that is just amazing. It gives a huge acceleration for any code to be written on your developer product. You'll see some examples there. Impala, my current organization, if you want to go and book a hotel using an API, you can just do that in five minutes. You'll see step-wise instructions there on how you can do that. You'll see similar kind of tutorials, lots of them on Stripes, on Twilio, and some of the other great developer product companies. And in general, keep it self-serve. Make sure that it is functionally complete and that functionality is accessible to the developers without lots of gates and friction level there. Coming back to this diagram where we saw that there are various types of developer products. So today we talked about APIs, but you could have developer products on each of these or any of these or all of these layers. So if it is of interest, let me know in the chat and we can have follow-up webinars about other layers. But today's time was about API products. Hope this was useful. Let me know if you found anything interesting, if you want to discuss anything, put it in the chat and I'll come to it. That's about it today. Thank you for listening to me. Here's my LinkedIn profile. So if you want to reach out to me, scan this code and we'll take you to my LinkedIn profile. All right, thanks again. Hopefully this was useful to you and see you soon.