Deepa Goyal, PayPal

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes, we explore the world of APIs through the lens of business and engineering leadership. Joining me today we have Deepa Goyal, product manager at PayPal. Deepa’s consumer-driven view of the API lifecycle, the maturity of our APIs, and her approach to analytics in service of product management, I found very educational.

Who are you, absolutely, what are you doing?

So I’m Deepa, and I’m currently product manager for API experiences at PayPal. My background, I started my career, I studied computer science engineering, and I went into data engineering. During engineering I discovered that I was very passionate about data, so I very consciously shaped most of my career in the data space, from data engineering to analytics and then eventually data science. Once I started doing data science and platforming with product managers to build more data products, eventually I decided to transition into product management. I was working at a fintech startup at the time, and data is a very core part of products in fintech, so it was a very nice, smooth transition for me. I was actually attending coding conferences with my developers just out of curiosity, and that’s how I got interested in APIs. I discovered how APIs got developers really excited, and I started looking into it and playing around with them, and eventually I joined Twilio, where I got to work on APIs as a product manager. And to now, where I’m shaping PayPal’s API experiences and looking into how we can make them better.

Wow, that’s quite a journey. To go straight to Twilio from your previous work, I think you can’t think of a better API to go join, in my opinion, as far as to learn how things are, because they’re one of the gods, the API gods I would say, as far as doing APIs in the mind of a developer. It’s one of the most useful, innovative. Jeff Lawson, as a CEO and a leader, I always thought it’s just a great company, and everyone I’ve ever known that worked there enjoys APIs and gets APIs.

Absolutely. I think Twilio has always been such a thought leader, and they have so much participation in the developer community. I think it was really interesting to learn how they do it and how they think about it. So I got to learn a lot from that experience. They’re very innovative about their approach towards shaping APIs as products.

I was just talking to you about some other issues where you could work, partnering and working on PayPal and Postman related stuff, and then I just kind of fell into your journey and how you got here. But the depth of your experience, I was fascinated by how you learned about APIs, because you were working with them in fintech, but how you just immersed yourself in the world of APIs and APIs as a product and all of these concepts. You had an interesting story about how you got here and the lack of information that was available to you. So can you recap for us how, where did you go to get all your knowledge and information? Was it at Twilio, or were there other places that you went to get it?

So yeah, absolutely. There was, I think even at Twilio when I joined there, there was so much information I wish I had before I joined. I realized that there isn’t much information or learning material around how to think about APIs as products. There are a lot of fun projects, and I used to play around with them to do little things, build little bots, little applications. But nearly all the content is geared towards engineers on how to build APIs, the technical side of it, how to scale them, how to make them more robust and scalable. But things like, how do you monetize an API? It’s just not really there. Are there any standards to monetizing APIs? A lot of times, when big large enterprises are using other large enterprise APIs to build products, only they know how the bills are getting paid. It’s not something that’s openly available to somebody trying to learn about APIs, like, how does Twilio make money exactly? How did they figure out how to make money from APIs? And all these other companies, they’re so innovative, there’s such a variety of APIs, but there just wasn’t information on how they shape the pricing strategies, or how do you start to define an MVP for an API product, for example. So as a product manager, I really did not have any reference. So I was leaning heavily on mentors in the industry and just really asking people, looking for insights from developers, and trying to understand, if they were to build an API from scratch, how would they go about thinking about it. A lot of times just asking them to try out an API and share feedback. So that was my way of figuring out, a little bit of user research and a little bit of just ad hoc analysis.

We focus on the consumption of APIs pretty heavily, and how to build on APIs, and that world of developers. And then there’s quite a bit of information about producing APIs from vendors, telling you how you should be doing APIs. And then there’s Gartner and analysts. And then I would say there’s a handful of us, and I include myself in this bucket, we’re kind of the pundits or the analysts, and we write books and we talk about how you should do APIs. And this is actually why I’m at Postman, because I was an API pundit or personality for a decade and told lots of stories about doing APIs, where I mentioned, hey, you should do APIs as a product, a lot, but I never tell you how to do it, or I never give you the instructions on how to do it. So this is very much why I’m at Postman, I want to start showing and demonstrating how you do things. But I found it fascinating, your point that there’s not a lot of books on APIs as a product, there’s not a lot of really foundational information for product managers to start their careers.

Exactly. And lately I have been spending a lot of time thinking about, what is API experience and what are the key components? For example, developers are now used to seeing an API status page when they are using APIs of some company, but there isn’t really a book that says you must publish an API status page. So as a product manager, when I’m thinking about, what are the fundamental pieces that developers expect there to be, what do these pieces do for them, what is the value that is delivered, and of course going into how do I measure it, that’s where I spend most of my time thinking about.

So you mentioned analytics, just a little bit in there, and understanding. There’s a lot of talk around API management and having analytics at the API management layer, that you should measure how people are consuming APIs, because this helps you drive your roadmap and drive your features, drive what you’re going to be adding into the API based on how people are using it. But really, beyond just what APIs people are using and errors, there’s not a lot of guidance on what else I should be thinking about. I mean, yes, up, down, errors, but as a product manager, what do I need to know at that layer? What type of analytics are going to be critical to my success as a product manager?

Absolutely. I think of analytics in a couple of different dimensions, because at different stages of the product maturity there’s different metrics that matter, at different stages of the customer journey there’s different metrics that matter. So it’s a pretty multi-dimensional aspect of developing products. For example, there is a pretty big piece of discovery for APIs. How do developers find out about an API? There’s so many different ways that they can discover an API. The same way that in marketing we have advertising channels, marketing channels, did a customer discover it through Instagram or through Facebook, and marketing experts would spend so much time optimizing that budget. The same way in APIs, there are a couple of different steps, a couple of different channels. Developers can come to know about an API through some blog, through a YouTube channel, through our documentation. I think of those things the same way somebody would think of marketing channels. In terms of developer journey, that’s when developers are kind of learning about it, trying to figure out if this API would be valuable to them. And there are of course a lot of different ways that people can learn things. So there is also this aspect of how people learn, because not everybody just reads a long docs page to learn. Some people prefer to learn from an audiobook, some people prefer to learn from a video, some people like those infographic videos. It’s just such a vast variety of ways people learn. So combining that with channels, and then as a product manager I’m trying to understand my customer base, developers, what do they like, what serves them best.

That’s an important distinction, because it’s not just people who are, it’s me as a product manager understanding how people discover, what matters to them, what’s important, and kind of the frequency or the way their brain works, how they’re going to want to understand. Do they want to play with it, seeing sample applications, seeing a live stream, reading the blog, watching videos? Based upon that, that’s a wealth of data about who they are and what they’re going to want as far as the capabilities of the API. Am I correct?

Yeah, absolutely.

So now, how do I gather that? I’m creating this experience, I’m putting out these aspects of that experience, and then I’m measuring as that comes in. Do I leave that into my feedback loop with these users? What else do I do to measure and understand what’s going on at this layer so that I can build the best next version of the API for them?

So from a measuring perspective, there is a lot of the discovery metrics that we think of in terms of like time to first hello world, is probably like the best starting point. The time between somebody creating their account and getting their API keys to making their first API call is like a great way to measure. We can get information around how many people are essentially viewing our documentation, of that what percentage are actually ending up in their first API calls, and try to measure various aspects of various pages that are performing better, or various pages that are driving more traffic. So I also broke that down a little bit. From an analytics standpoint, there are all these metrics that we can build around just the documentation and how that impacts discovery, and all these other metrics that we measure in terms of the API usage itself. Because after making discovery, the conversion is essentially the first API call. You have discovered the API, you may have come from a YouTube video or a blog, or you’ve seen the documentation, you made the first API call, and then it’s the next step in the user journey where you’re scaling your usage. That has sort of its own set of things. Does a customer go from one API call to 500 in a day or a week or a month? How long does it take for customers who scale to scale, and what is the reason, what are the pain points that take them longer when it does. So there’s a whole set of things that we can discover just measuring those times, time to scale.

And does this apply similarly to, I mean, you said it’s multi-dimensional, so does it apply internally as well as public APIs? Because if I’ve got, or beta APIs, like if I just put, the maturity you talked about, if I put out a beta API, am I going to measure in the same ways, or am I going to have a different set, or are those data points going to mean different things?

I think the data points might mean the same thing, but I think what differentiates a beta API versus a GA API, and I can talk about that terminology a little bit more, is really the customer expectation. It’s really interesting, I was really thinking about what defines a beta API versus the general availability API, how do we make that distinction. And I kind of looked to the documentation of a lot of different companies. Of course, I’m more familiar with Twilio, having worked there, but also looked at things like Okta, Shopify, Microsoft, and I really noticed that there isn’t a very standard terminology around what is a beta API, what is a GA. It’s really every company kind of defines their own, and that really stood out to me. But I think in general, at a high level, what everybody’s trying to do is set customer expectations. As a customer, if I’m using a beta API, then I’m building a dependency on a product that may not be mature, that might undergo changes. So it’s really a business decision, do I really trust using a product that might change, might break my application. And another interesting thing I’ve seen is the difference in SLAs. A lot of times these API companies would actually lay out clearly the different SLAs that they define for a beta product versus a general availability product. So I think the maturity level is really driving transparency and trust for the end customer trying to build applications using these APIs.

So from a product perspective, if I’m managing a beta product, then to some degree I know what customers expect, that it is not completely a mature product. From a product standpoint, I might be engaging more with those customers, getting more interaction and more one-to-one inputs from them as I shape the product into a general availability product. And if I’m product managing a general availability product, I can expect that the customers expect a very high bar for quality, and they also expect that the API shouldn’t change in a way that breaks their application. So I think the expectations change at every level of maturity of APIs.

Do you feel that there should be a standardized vocabulary for how we describe what is GA and what is beta, and how that applies to each API parameter, path, pricing, SLA? Is there a standard framework we should be considering there?

I think it would be really helpful in quite a few different ways. I think it would be great, for example, to get more product managers to be able to enter the API product management space. It’s definitely going to, if we had this kind of standardized vocabulary that can be shared with new entrants and APIs in general, I think it would be helpful also for engineers. I think it might potentially make some kind of standardization help them take that knowledge across as they use a variety of APIs, because a lot of developers are using a lot of different APIs, so having to learn each API’s own standard, it might actually help to have a standardized definition. So the answer is yes, absolutely.

Interesting, because I’m part of a working group that is working on an SLA standard for the OpenAPI specification. So how do you describe an API? You have this API that has this path, these parameters, this request and response, and you can get, post, put, it’s got a handful of methods. Now what’s our pricing, what are we charging for that, what’s our uptime, the promise of threshold performance as well as the overall availability, and then how do we, what’s the standard for monitoring, that status page you talked about, and then how do we reconcile that, and then do we give you a discount? It seems like, I haven’t seen anything that says, here’s what GA is, here’s what beta is, that maybe we could add a property to the top of the OpenAPI specification that would let’s say, here’s beta, here’s this API. It’s not just the version of the API, because we have a place to put the version, but if we had a place to write maturity and then say it’s GA, beta, or alpha, then that would set, then you go, okay, here’s the configuration for the SLA, here’s the configuration for the monitoring and uptime, and it would adjust that for you.

Yeah, very interesting. I hadn’t even, and even extend that. I think standardizing it across the lifecycle of the API in terms of how mature it is and just overall, I think it would really help to evolve the API space. I think we have reached a point where there are enough companies and people who are aware of APIs that I think it is the right time to arrive at this standard.

Yeah. And I mean, I’ve actually encountered several conversations lately about, how do we define the product manager, the API product manager role, and how do we onboard them and equip them with as much knowledge and information and enablement, not just like here, go read all of these books or anything, but how do we give them specifications and standards to work with in their job, as well as the tooling, the API management, Postman, different things that they can use. So this is very much trying to stabilize that world so we can scale it. We need more product managers, we need more API product managers, competent ones. There’s definitely a shortage. So that’s what really stood out when I was talking to you the other day, this conversation, is your view of, hey, there’s not enough knowledge on, well, what is API as a product, how do you do this, let alone all the way to standards and specifications that would help with this and help us figure it out. But you also talked about the trust. It’s going to increase the trust and the confidence of the product manager, but it’s going to create trust with the consumers as well, if they know if those expectations are set. Do you think it also should govern how we communicate, or how support tickets and that feedback loop as well between producer and consumer?

Absolutely. I was just going to say that it should really drive how a product is supported, because the beta API may not need the same level of support as a general availability API. So from a product manager standpoint, I do actually monitor how many tickets we’re getting at any point on a weekly basis, and I think the expectation is that at some point your product is mature enough that people are not running into foundational issues, like getting set up or things like that. So I think supportability of APIs definitely should be tied into the maturity of the APIs, and as it matures, it’s actually a great way to measure how mature an API is, if a lot of people are just able to self-serve, get started without any help.

Yeah, and that time to first call. I think a lot of product managers or the developers building can say, oh, we’re not adding any more features, or it’s reached a maturity level based on our gut feeling. But this is actually saying, hey, let’s actually have a measure and actually quantify how mature it is based upon the number of error tickets, how many people can self-serve and actually get on board. And not just one track, like documentation, like you said, they should be able to come from different directions and be able to onboard with an API without any help, and then activate, and then start increasing the number of calls. But then also activate across APIs, so the number of APIs they’re using and the maturity of that as well.

Another interesting metric that is very useful is actually not just time to first API call, but time to first transaction. And a transaction, for example in fintech, could be the first actual money movement. That might take a few calls for a customer to get to, but that’s really success, when they have made their first payment. It could be different things for different APIs, of course, but first transaction is very valuable. The other thing that I find very useful is number of API calls for every transaction. How many API calls does it take to make a successful transaction? Because that really helps me understand if our API is too complicated and maybe we can optimize it.

That’s funny, that reminds me of, 2012 I think it was, it was at a Mashery API conference. So Mashery is an API management provider, that’s, I think TIBCO now owns them. They used to have the billionaires club is what they called it, the number of APIs that have over a billion API calls. And then my friend Daniel from Netflix at the time, he’s now at New York Times, he came and said, and they opened up and said, hey, one of the billionaires club is Netflix, they’re customers, they’re in the billionaires club. And Daniel said, why do we want to be in the billionaires club? We don’t want chatty APIs. We want meaningful volume, if it’s meaningful billions of API calls. But with this club, you’re kind of incentivizing me and my developers to make chatty APIs. So what you’re talking about is actually being able to see that and measure the meaning of those APIs, of that value being generated.

Absolutely. I mean, that way the billion is essentially a vanity metric. And how do we get out of that to see if you’re actually delivering customer value?

So how do I incentivize API developers to care about business metrics? They care about the pain points they have as far as what they need. The API has to be up, it’s got to be performant, those very technical details. How do we get development teams, how do we incentivize them to care about business metrics?

I think that’s where APIs as products are very different from all other products. Because what I’ve seen is, because APIs are used by developers, developers are actually quite engaged and passionate about how the API is evolving and how it’s being used. So in my experience, developers have been very active partners to me as a product manager, to actually shape the experience. I think that’s the aspect of API products that is very different from all other products out there.

But I would say they already have opinions.

Yeah, and I would say they have opinions, and they’re probably not being tapped properly and understood properly, because you have to kind of drag things out of developers a lot of times. If you don’t ask, they’re probably not going to volunteer it. So it takes a confident product manager and someone who’s aware to be able to start talking about API operations at the business level and establish what those metrics should be, and then developers are going to care, and they’ll think about them and they’ll contribute to them. They’re just not being engaged as part of the process. They’re just expected to deliver the API and keep it up, from an operational standpoint.

Exactly. It’s like people are not asking the developers for their inputs. I think there’s also an aspect of, when I present some of the metrics I’m following from a product standpoint to my developers, they inevitably ask me what that means and why it’s important. That’s a great way to start thinking about how the work that they are doing is having a business impact, and from there working into, how do we improve these metrics, because this is why it matters.

Yeah. I’m always fascinated by the classic IT and business divide that has been around for a long time. I have a 30-year career, and this divide has always existed. If you talk to business folks, this divide exists because of IT and technical folks and developers saying, oh, stay away, this is tech, this is wizardry, you don’t need to understand this. And then developers are saying, the business folks don’t come over here and engage with us. I think there’s various reasons for why that exists, but it feels like, that’s what we need, that balance, in API spaces. We need product managers, more business domain experts involved in the design process and developing these products. But we have to have developers there, and we don’t need just developers just to develop. We need them to understand the business and have a feedback, be part of that feedback, adapt, be part of what we measure, and have a stake in that. They don’t need to be ignorant of it. So I think that’s the process that you outline here, it’s a process for all stakeholders that are involved.

Absolutely. I really like the fact that you brought up domain knowledge, because one of the things that I have seen, of course, the bigger aspect of the divide between IT and business, but there is also this aspect specifically in the API space, where if as a developer I’m trying to work with a fintech API, a business person would assume that I know what disputes mean, or I know what invoices mean. Or if I’m working with any marketing or any other domain-specific APIs, most of the business people creating those products kind of assume that I know those domain terminologies that the APIs were designed around. So one of the things that we’re trying to do at PayPal actually is trying to create some kind of payments 101 that is geared towards developers, so that they don’t have to feel like they don’t have the domain expertise. Because a lot of times developers are individuals. I’ve seen a lot of times these are like CEOs bootstrapping their application, or these are developers who had an idea and they’re building an application. So it’s not always one or the other. How do we give them the domain expertise, or at least the key terms for them to get started? It actually does help them get started with APIs. So I think there’s a lot of opportunity to bridge the gap. I don’t think, both developers can learn a little bit of domain knowledge and business people can try to learn a little bit about technology. I often end up just being very honest, and I tell my developers I have no idea what they’re talking about. I think we all just have to have those conversations.

Yeah, no, I like it. It’s so important, it’s how we’re going to fix all of this, most of the API illness. Because APIs drive so many applications, there’s a lot of illness behind the applications they power, and most of these are because of this divide, this lack of communication, and honestly the lack of business stakeholders involved in the process. The really last five years that got me the most excited about APIs is because of OpenAPI being available in YAML, more tooling out there to allow non-developers to get involved in the API lifecycle. I’m seeing more folks involved in the conversation, and I’m seeing more diverse folks. It’s not just your usual class of developers involved in the conversation. I think those voices, having a lot of different voices, domain experts but also business, involved in the conversation is important. That levels the playing field a little bit and helps us deliver more meaningful, more purposeful APIs, less waste, and we’re able to move forward faster, and the world’s just a better place if we all work together to do this.

So I feel now I’m looking around everywhere, like, where are we missing information to get people up to speed on being an API product manager? Is there a career path to become a product manager for an API? How, if you had to explain how to get here to someone else, how would you explain to them how they should onboard with the role?

I think it shouldn’t be a barrier to entry that you have to be a developer to be an API product manager. I think a lot of people who don’t have developer background can also make it as API product managers. I think everybody should really lean on their strengths. So if somebody has good domain expertise, for example if somebody had a great knowledge of marketing, then they just have to learn a little bit about APIs and they might make a great API product manager for a marketing API. So I think just fill in the gaps, and nobody knows everything, so we always keep learning. I think a learning mindset combined with knowing your strengths and weaknesses, and trying to work on those weaknesses to grow, I think anybody can be a product manager or an API product manager.

Okay. One of the interviews I did last week was someone who started out as a technical writer, and they were kind of the front line of problems with the design of the API trickling downstream. They were affected, and customers and users were hitting them, and then they ended up having the opportunity to become a product manager and jump in and change things and make them better, and they took the opportunity. So I think I want to spend a lot more time illuminating these paths for people to find their way and realize. And I appreciate you saying you don’t have to be a developer, because I think that’s really important. Like we said, it’s not just, we need more business users involved in the lifecycle, we need more business users owning the product and defining the product and shaping the process, and then shaping the knowledge we put out there. So how do you get your knowledge and information from the space? What do you do? You touched on it a little bit, you read books about APIs that clearly don’t have enough on APIs as a product in them, but what else do you do? What other practices do you use to gather information and knowledge?

I think YouTube is a great platform. I watch videos on APIs. I constantly search for things, and also search the same things over and over. A lot of times there’s new content coming up over time, so if I searched for something three months ago, it’s actually possible that somebody made something about it more recently. So a lot of times I search for the same things over and over on different platforms. When I was looking into API maturity, I kept looking for it, and every few weeks I go back and I search again, like, is there anything new? I also follow a lot of people on Twitter. I try to spend at least a few minutes on Twitter every day. That’s why I have a more API and developer focused Twitter handle, and that’s the information I’m looking for, just to see how the developer community is talking about APIs, or any kind of knowledge. A lot of times I’m learning about cool projects people are doing, not necessarily dependent on APIs. So YouTube, I also spend some time on Udemy occasionally, I really like Udemy, and books and Twitter, those are my platforms.

I like it. I would say it reflects mine, I would say except for the videos. I produce a lot of videos, maybe that’s part of my problem, I don’t consume as much as I should. And if it is, it’s usually a shorter video, that I don’t have a lot of time in my day, and I wish I had more time. What’s the ideal length video for you to be able to watch? Does it matter if it’s based upon the content or no?

I think there’s definitely an ideal length. Depending on the information, I think anywhere from three minutes to 20 minutes. I think 20 minutes is the ceiling for me, especially because videos that are very dense in information, at 20 minutes, because it is a one-sided communication, 20 minutes tends to be the ceiling. At 20 minutes you kind of lose attention. So even if there is a longer video, I watch it in pieces.

So I agree, that’s a nice sweet spot, especially with TikTok. The statistics that we are seeing with TikTok, the length of video that people can have attention for is reducing day by day. On TikTok the ideal length of a video is actually seven seconds, which is so short. It’s kind of interesting to see. I’ve been thinking a lot about, there’s so much technology and coding people actually teach on TikTok, and I’ve been thinking about, like, if I were to explain my PayPal APIs on a TikTok video, can I actually do that in one minute? I don’t have an answer yet, but it’s something that we have to think about. Because going back to what I said around how people learn, if we want people to learn about our product, we have to understand how they learn so that we can present that information in a format that works for them.

Agreed. One of my missions at Postman right now with my team is, everything we do has got to be demonstratable and hands-on, something you can do. And I have what I call API blueprints. So I distill a lot of different learnings down into these seemingly short texts. They’re text, so it’s like a one-page outline. How do you do API testing, how do you do API documentation, just a one sheet on it. And I shared it with someone from my sales team, and she was looking through it, I have like 40 or 50 of these blueprints, and she’s like, all these are great, the content is nice and dense, so I need each one as a 60-second video. And I was like, oh, okay, I will get to work on that. Because she’s in LinkedIn, she’s like, everybody I’m targeting, you know what, your content is great, it’s great to read, you know, two percent will read it, the rest just want a 60-second video, here’s the concept, give it to me, all right, let me go on my way. So I want to check back in with you on what your overall developer experience toolbox looks like, distilled down to a 30 or 60 second video. Is it possible?

Yeah, there’s a few different ways that I have thought about it, because I’ve been thinking about how to have some standard checklist of building a great API experience. One of the things I was thinking about was, what if every page for an API had a small video that kind of runs with the documentation? Like maybe a short, you cannot make a short video about all of the APIs, but you could potentially make 30-second videos for each endpoint potentially.

Could you do it for each parameter and header too for an endpoint, so that I can understand what the headers are?

That might be overkill, but the reason I’ve been thinking about it is actually, I was looking into, I’m very curious about how much text there is in the API space. Documentations are just so vast, and I was really curious about how many people have reading disabilities, and are there developers who have reading disabilities, how do they learn APIs, because everything is text.

I really appreciate you talking through this with me. I look forward to your work on maturity and analytics and that cracking open of it. The overall product manager stuff, I think it needs to be addressed, there’s a lot of great stuff there. But your cracking open of maturity and analytics, and that multi-dimension that exists there, I think is worth exploring more. So please, if you publish anything else, share anything else, share it with me, I would love to share it with the audience and help do some storytelling around it. But then some of these other areas, this is going to be a full episode, but we have these TLDR episodes which are the short little content pieces, and there’s a couple other areas I would like to revisit with you there. So we’ll definitely be in touch. Thank you for being with me, I really appreciate your time today and coming.

Absolutely, this was really fun. I think we got to talk about a lot of various different things, so I’m really glad we could look at such a variety of different topics. It was really fun, thanks for having me.

Thanks again to Deepa for stopping by. For more on Deepa, you can find her on Twitter at OneSprintAtATime, or on LinkedIn, but you can also visit developer.paypal.com. You can subscribe to the Breaking Changes podcast on postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.