🎂 Abhinav Asthana & Nitin Rao Fireside Chat

Hey, everyone, welcome. It's Cloudflare's birthday week, we're celebrating 10 years of helping build a better Internet. And we're speaking with industry leaders we respect who have really built interesting companies and are shaping the future of the Internet. My guest today is a friend of 13 years, Abhinav Asthana, the CEO of Postman. And I think Abhinav is just a has got a fascinating story. And, and, and so I'm so glad to get the chance to chat for 30 minutes. So welcome, Abhinav. Thanks for having me here, Nitin. Good to be talking on this stage after a while. Yeah, yeah. Now, we're, for anyone who isn't familiar, would you mind telling us more about Postman? So I remember Postman as a project that you single handedly started in Bangalore, India, that grew to have a lot of developers signing up for, and you were edging out the most well funded startups left, right and center. It is a fascinating story. Tell us more what what would tell us more about what Postman does and maybe recount the earliest days? Sure. Yeah. So Postman, you know, today, Nitin is an API platform used by more than 11 million developers. As you said, you know, it started off as a side project, actually, for me, you know, I was building it to solve my own pain points of struggling mostly with API's I had experience at Yahoo, which I did an internship at, and a startup that I co founded after college, I, you know, wouldn't say like a single handedly took it to, you know, this point, I had, like, my co founder, Sanket and Abhijit joined in 2013, to help me kind of take that forward. And, you know, it was just kind of one of those things that your personal pain point, if you can kind of transcribe it into a product that resonates, I think, you know, people in the initial days, like I remember developers, you know, from from the Bay Area, including, you know, companies like Box and Google, like kind of loving the product, you got featured on the Chrome Web Store kind of back then. So so it was just like a lot of fun for us to solve, you know, what can be better, you know, solve pain points for yourself, and other people like it. And that became a company through the sheer, I'd say, you know, we wanted it to kind of, you know, brew the project for a while. But, you know, we had a lot of interest from from investors, and everybody who just, you know, came to find find the product. So I think when we started, we had about half a million users to begin with. And since then, it's been pretty, pretty busy. I remember reading somewhere that there are more than half a million companies that use postman to manage their API's. And, and I love also just the diversity of engineering teams across companies, carefully, for example, there's so many different teams use postman in one form or the other. Can you describe the very first product? And we'll maybe follow both the evolution of postman and the evolution of API's on the Internet. And so what was the very first product? And why was it useful for, I guess, yourself and the folks using it? Yeah, the basic thing I recognized, then was that developer was spending like myself a lot of time with API's. And typically, you would use like curl commands or write your own code. And that was just one part of your code base that you just did not know whether you know, the API was at fault, or you were at fault. So postman, and it's like, you know, very early days was just an API debugger, which is just such a fundamental thing that if you look at API's themselves as like a platform to build software on, you know, you need a debugger, just like you need a debugger for your code. So that's what it became. And I added, you know, a few capabilities that, you know, were basically to make my life easier, like no recording and replaying requests, you know, combining them and sharing them with other people. So it kind of had that evolutionary journey that it grew from being like a single developer, you know, product to be something that multiple people could use together. So, so basic use cases of debugging, testing, documenting, you know, I did a JavaScript sandbox in it. So you could like script things together, which is again, kind of very unconventional for like a typical, like no code API tool, because it kind of had those like developer roots. So, you know, essentially, like just with the sheer growth of API's, we saw that, you know, it's developers, testers, ops, like when everything has become API driven, people need something to work with API's, you know, kind of paradoxically, Bozeman is the GUI for API's, which typically don't have UIs. In the first place, it's going to become like this universal UI for everything API related and tons of use cases, like we just discovered new ones, like every every week, like a couple of weeks ago, I met a CFO who uses Bozeman for an API for like machine, you know, fraud detection, and met him, you know, CEO who closes sales deals with Bozeman because they have to demo an API. So it's just fascinating to see all the stuff that has kind of come up from that base developer use case. And for developers, it's just like bread and butter. And for the longest time, Bozeman just stayed at the number one spot, I think in the dev tool section of all the Chrome extensions. At what point in time did you sort of what point in time did the Chrome extension become more than a Chrome extension? Walk us through that thought process. So, you know, it was a mix of push and pull a little bit of push from Google to say that, you know, you should maybe not build Chrome apps anymore, and pull from developers who kind of wanted more capabilities. So we recognize that here's a larger opportunity here to not just make, you know, API debugging or documentation better, but really looking at how API software is built. And we wanted to build, you know, what we now call today a collaborative platform. So you know, we slowly started adding like cloud based services, you know, you could have a postman account, you could share your API collections and stuff with people. So we recognize that we had already split between stuff that ran on the cloud, and stuff that ran inside a Chrome extension, then we thought that why are we limiting ourselves to a Chrome extension. So we launched a desktop apps based off of electron. And this year, we actually launched web apps. So we kind of, you know, span the gamut of like, whatever, you know, postman can be done as an application, it will run as an application, but backed by, you know, powerful like cloud services. We also discovered that there were a lot of features that we could add, like, you know, monitoring mock services, which really needed to be on the cloud. And the key one being, you know, what we call like workspaces that allow developers to collaborate in real time. And that that was kind of the fundamental thing that we discovered was missing in the developer landscape, like you could use repositories for collaboration, but they were not designed for for API's. So in 2014, when we raised our seed round, we realized that that's what customers are asking us for. And postman has traditionally been very developer driven, you know, we talked to developers, we talked to teams, and we asked them, hey, what is the biggest problem we can solve for you. So collaboration became the biggest thing for us. And that's why the platform shift was kind of very key, we still have Chrome apps. And you know, today, we have like, as I said, apps on like anywhere where people would run it. But that that kind of led to that seed of, you know, us evolving out of the Chrome, you know, extension playground. And, and sort of fast forward to today. So the company is based out of San Francisco, it's, it's raised significant capital, what is, can you can you just give us give us sort of more to the extent you can share the sort of more numbers for just the just both the scale and just examples of API's using postman. So it's been a fascinating journey, I think, just in terms of sheer headcount, you know, we grew from like three people at the founding of the company to now I think we'll be touching the 300. This is across more than, I think, seven countries already. So we are headquartered in San Francisco. I moved here in 2017. We have a big hub in Bangalore. So about, I think, 60 odd people in the US right now about 180 in Bangalore, maybe that's that is a little off. But you know, we have people also globally distributed now almost in every kind of continent. I mean, you already covered the scale and we see exponential growth across kind of like all of our metrics and it's our apps get downloaded, like more than you know, 2 million times a month. It's the industry standard for all things API related. I think it's been, you know, going from the Chrome Web Store days where it was kind of focused on developers, you know, like number one on like every rating review site and, you know, anything as you may and as you said, like we have half a million companies using it. I think the most fascinating thing for us has been like how API's have gone from, you know, along with that postman how it's gone from being focused on like a tech industry thing to being a pervasive thing across like all industry sectors. You know, it's like every industry is modernizing, it's bringing their digital assets to they were bringing things on the web before, but now they're also thinking of how they can bring API's and how they can, you know, plug into the API economy as a whole. So our adoption has been in a way faster for our products, especially when it comes to monetization on some of these sectors which are rapidly not opting API's. Yeah, hundreds of I think thousands of, you know, customers across all industries. And so what is what is the how does the experience of for a developer working with API's? How is it different today versus say five years ago, 10 years ago? Like what what has changed? So mostly, you know, what we saw was that developers were using, you know, like, if you look at a typical developer tool stack, it's very focused on writing code and compiling code. And API's were typically like things that you would plug in as part of your stack. And, you know, it would be your code repository, your code editor, and then some other tools that would use that you would use. And now with API's kind of taking more center stage, at least when it comes to your post, when we talk about being API first, and through that you are kind of, you know, designing an API, you're prototyping an API, you are writing integration tests, and not just in, in a typical developer focused way, but you also have your quality engineering team, ops teams, security engineering teams kind of shifting left, and working closely with developers. So you know, we've seen more and more stakeholders, especially when it comes to API design and development, be involved much earlier in the process, as a whole category of new product managers who are solely focused on API design and development, who are also using developer tools. So I think, you know, we see developers adapting to kind of like this new world of API driven development, and also the surrounding job roles, you know, changing their skill sets to map to, you know, API development. So kind of we see a healthy synthesis of all of this. And I think this is a general trend in the industry, where tooling is, you know, much more collaborative in the sense, if you see what's happening with like, you know, Figma, Notion, you know, Atlassian has kind of grown a lot. And I think the same thing kind of applies to API is where, you know, work is much more collaborative in nature, you know, management, good management focuses on how teams work together. So you're seeing kind of a lot of that, rather than just literally be in different, different time zones, different countries. Absolutely, yeah, you know, with the rise of like, especially kind of in this time, you see like distributed work and remote teams, you know, what used to be like meeting handoff email, you know, now you see basically tools acquiring that collaborative power. So what just gets done, you know, faster. I remember you're mentioning, as we were sort of preparing for this chat about their bunch of interesting sort of federal government cases, how should governments be thinking about, about API's as part of their Internet presence, Internet initiatives? Yeah, this is like a fascinating kind of thing that we are seeing across, I'd say, kind of like, you know, all government levels, like, you'd see there's a ton of data that is created by, you know, nonprofits, government agencies, and it's typically sitting in, you know, CSV, JSON file somewhere. And the expectation is that, you know, it'll be updated, like, you know, once every three months, and somebody is going to download it and do some analysis on it. You know, what we see is that all of that is shifting towards, you know, how typically you see API's to work right there, they give you the most up to date data, they give you the most up to date, you know, information, they are actually used by developers, you know, to build applications. And, you know, it's not just, you know, you're building, you know, some some, you know, entertainment app anymore, you know, you're kind of using it for visualizations, you know, cross cutting. So there's like this whole developer demand, you know, for for all of this data. And what we see kind of, you know, the government sector doing is, first of all, they are adopting all the best practices that come from, you know, tech leaders, you know, of scalability, security, reliability, you know, you're not just designing like an application form anymore, you're actually thinking about, you know, what are the privacy rules around this data? Now, how much data can we actually give out in an API call? So there are a lot of these different constructs in which, you know, it leaders did not have to think about but are actively thinking about it. And I think then it kind of goes into like, you know, what are public data sets versus, you know, how I'd say the digitization of government itself is happening. I think we see that across, you know, multiple countries, you know, I mean, India has its own initiative, I think European countries have their own initiatives, where essentially government departments are, you know, kind of becoming API driven, in a sense. So I'm kind of very fascinated about seeing, you know, how that plays up. And so when, when someone who's thinking about, I guess, how open or, or, or less open to make their API and reaches out to you for advice, what what advice do you give them? How do you think about how open to keep your API or not? That's a great question. You know, I think most of the mistakes that have been made in API design have been kind of around this question. And I think more than ever before, engineers and you know, leaders have to now think about this from multiple angles, you know, what's your business model? You know, how do you see privacy and, you know, security implications of your users and customers? Now, what does government regulation look like, you know, now with GDPR and kind of all of these things kind of coming in? So can you share? Can you share examples? So like, I think, I think we all sort of like generically understand the concept of privacy and security. But like, what are examples of things that can go wrong? What are examples of API's that you wouldn't want? More open, less open? Yeah, I mean, you know, basic things around like, you know, permission sharing of, you know, like, take an example of a social network, right? Like you would treat your friend list as your friend list. But, you know, the data of your friend is also in that friend list, right? So when you authorize a third party application to access your friend list, not only are they accessing your data, but they're also accessing somebody else's data. You know, if you look at, let's say, you know, credit card transactions, you know, like, it's not, it's not just the data itself. It's like, you know, what, what is the authorization that you have around it? So I think, you know, API design involves that kind of framework around which data should be accessed, and be used. And I think those would be the, you know, some some examples that we have seen, you know, where people have to think about a lot, like, it's not just, you know, like, developers would need access to it. So let's kind of give it there are other concerns that could come in around it. So people have to be thoughtful about it. I think there is also like basic examples of, you know, do you get, you know, a list of things versus a single entity, you know, like, I think people make a lot of mistakes there when they're designing API is that you wanted your data to be visible for that particular entity. But, you know, you just open up, let's say the list API, and suddenly everybody's data is visible. Like, you know, basic things like this, you know, are I think the more common vulnerabilities that we see. Now, did you happen to have, like, I don't really know the numbers. I know that in the early days of Cloudflare, we used to sort of measure breadth in terms of things like page views, those metrics have become a little more anachronistic because, because of things like API's. Do you have a sense of just the numbers like our API is a bigger portion of the Internet, they feel like a bigger portion? Yeah, consistently, I think getting bigger, I think the exact number would vary depending on, I think the business model of, you know, a particular company, but you know, one could argue like, you know, Amazon Web Services, which drives a big chunk of, you know, traffic in the world is primarily API driven. I think most interaction between, you know, front, I mean, almost all interaction technically is between is happening through API's. So discounting kind of that, I think there are different ways in which I would bucket this, you know, one is purely like API driven, like SaaS companies, you know, like take Stripe or Twilio, for example, you know, massive market caps, driven primarily by, you know, API's as products. I think then there are, you know, SaaS companies which deliver products, but also have platforms of their own, like no slacks API, or Salesforce's API. I think those numbers are definitely in higher like, you know, double digits. I don't have access to, you know, the data of those companies, but it's a it's a pretty big chunk, and it's growing rapidly. Yeah. Just switching gears a little bit, where I continue to be fascinated by, by what your team, your early founding team did, is one of the things that's really interesting. I know you're now headquartered in San Francisco, but the idea that a small team in in Bangalore could build products that Uber and companies around the world start using. Is that in what ways is that? In what ways is that? Is that something we should expect to see more of? Can you like, do you need to be in San Francisco to, to build products for the world? And what was your thought process to move the company to San Francisco? Yeah, so we've heard a lot about it. You know, I think, first of all, you know, for the first question, the environment is absolutely there to, you know, have innovation happen anywhere. I think, just with the sheer growth of, you know, the Internet, you know, bandwidth, access to information, mentorship, and, you know, investment capital is available, you know, everywhere. So I think those starting phases of a company, I mean, I think if one were to look at like Y Combinator data, or, you know, Accelerator data, now that is, I think, going to happen, you know, across the world, I think, I think the key question is, you know, how does those initial, how does that initial product or that initial innovation, you know, go towards, you know, building, or becoming a successful kind of company, you know, so that was kind of the motivation for us to move, like, we knew that, you know, we could continue building, you know, great products out of Bangalore. But, you know, there are certain things that you need when you're establishing a go to market presence, you know, when you're scaling up your, you know, sales team, for example, or, or you want to be also ahead of the curve when it comes to, you know, new technology changes. So I think those are factors with which, even if companies don't, you know, move headquarters here to San Francisco, I think most companies would have a presence here in some ways, I think I'm seeing hybrid models where people are just hiring, you know, small teams here, you know, they're not moving like their entire crew here. So I think, I think we'll see a lot of like you're getting best of best of both worlds, which is which is terrific. Yeah, absolutely. So I think I think we'll see just much more of it. And I think the other thing I would point out right is that customers are more likely to buy, you know, product that is, you know, that works well is highly performant, rather than you know, where it was created from, I think people care less about that. We see companies start by building these sort of really focused solutions and solutions, for example, helping developers like pager duty is now public and we're getting a couple billion dollars. How do you? Okay, how do you? How do you? How do you? How do you think about sort of what's next for like, how do you think about sort of the the expansion of products? And what is what is a, of course, you'll keep growing this, but what is what is a second act for a company like postman? So, I mean, I think most of the things that we started off, right, are still kind of, you know, growing, I mean, the platform is growing, you know, our features are growing. I think every day, we just find more validation for the key hypothesis that the world is now moving towards, you know, being API first, as we as we call it, just because, you know, I think every technology trend over the past, like decade has supported the creation of like more and more API. So I think it's more like, you know, we're trying to kind of keep this, this entropy kind of more control, you know, there are more API's out there, there are more companies want to build API's, I think, and the key issues are still the same. I think, for us, we want to, you know, kind of improve, I think we're still in the early leanings of like, you know, kind of like the collaborative experience that we wanted to offer. I think we've made great leaps with, you know, workspaces that we have put out. And, and you, you know, users continue asking us for more things that I think one key technology trend that we're seeing is, it's not just like REST API's, but multi protocols, like asynchronous API's, you know, WebSockets, GraphQL, gRPC, protobuf, like things that used to be, I'd say, you know, living inside like big tech companies are being adopted kind of more globally. So I think from Postman's perspective, essentially, we'd like to, you know, support anything, any technology that connects like two things together. And there are more and more of those things kind of coming together. So like the need of collaboration, the need for tools is only going to increase because you know, developers like want more and more, I'd say richness in the ecosystem across each of these protocols. So I'm pretty excited about that. How has your relationship changed with, I mean, I guess, to the extent you could share with like, you know, the, you know, the Microsofts and Googles of the word, Microsoft owns GitHub, what, how, how the how those sort of partnerships and relationships changed over the years? I mean, you know, we are, I'd say, we are developer led, you know, we typically would integrate with any product or any solution, you know, that developers would use, I think Microsoft and Google all offer, you know, great developer platforms that we are on. I mean, you know, we run our support tracker on GitHub, you know, we integrate with GitHub with our tooling. And I think, you know, as Google's offerings are expanding, you know, we'd like to integrate with, you know, whatever developers are using, you know, today, we did an integration with AWS a while ago. So, so our stance is, you know, whatever helps like the developer workflow, we'd like to integrate with even better if that integration can be done by API's. So, you know, no humans involved. So, so, so it's basically like we have our API, you know, another vendor would have their API and we just integrate as developers wanted. I think there are interesting opportunities here, you know, as, as the world, you know, just has more and more developers. So I think, you know, kind of looking at interesting ways to partner with lots of companies. What do you so we have a couple minutes left, what are you most excited about the next next several years, you have a pretty unique vantage point, because you see developers in big companies, small companies in the US elsewhere. What's what's what's possible over the next several years that we should be excited about? So I'm personally excited about, you know, kind of creating like net new developers in the world. I think what we are seeing is, you know, there is, you know, every decade, there's a definition of like, what I would say, everybody believes what a good developer does, you know, and like, as people move up, as technology moves up under, you know, and how would I phrase this, you know, the layers of abstraction get richer, you know, and then there are interesting things to build at higher layers of abstraction. So I think what we're seeing is, at least what we believe is that APIs are the ultimate layer of abstraction, you know, they can abstract out, you know, entire companies, they can abstract our government. So what we're interested in is actually seeing, you know, so far, the passive consumers of technology being active contributors of technology, and become builders, and we feel like, you know, API is combined together with curiosity from, you know, people across like every sector in every field of the economy, you know, playing a big role in building, you know, for the future. That's great. What are examples you have seen that really, that really inspire you folks who, I guess, traditionally wouldn't, wouldn't, wouldn't, wouldn't interact, you know, this making it easier for them to get involved. So I think, you know, one study that I would say, you know, we also wrote a blog post about it is in the customer support team at box. I mean, we have similar use cases there. But basically, you know, with with API is themselves becoming products, you know, companies have to support them and what they were challenged with was, you know, people would support would send support queries and saying that please debug my code base because your API is not working, you know, so kind of like it was a funny, like, way of like thinking about a developer's workflow, but now customer support person has to kind of handle it. And what we learned was, you know, they started using Postman as a, you know, common language to communicate about API's, you know, just kind of less about the tool, but you know, solving the problem. And what we saw was that hook that, you know, that empowerment that the, you know, team got allowed them to actually then start contributing more and more, you know, they started becoming, they start becoming active contributors to, you know, docs and, you know, processes internally, and, you know, just was a fundamentally new opportunity, you know, for that team. So similarly, we see, you know, essentially business facing functions, who are very abstracted away from the day to day development processes are also playing a key role in bridging the gap between, you know, development and business functions inside companies. I, how do you, so how do you, how do you spend your time these days? What do you what are you trying to learn more about? So I've been like, interested in, like network theories, and you know, like, how does emergent behavior kind of come up? So I'm like trying to kind of figure out, you know, like I was reading books and like how cities develop and, you know, like, lots of like, I think I've been like a bit disorganized in my reading lately. But that's that was kind of one area of interest. Like I sometimes dig into like programming books and try to kind of figure out like, you know, what's happening, things lowered on the stack. So yeah, those are things that keep me busy. Great, great. Well, well, well, well, thanks so much for joining us. I mean, congratulations on on the business you've worked and, and the hundreds of thousands of businesses you support. And I can keep going and the 10s of millions of developers you support. It's really impressive and very, very excited for the future success of Postman. Thanks so much for coming and spending time with us. Thanks so much. Thanks for having me. Take care.