David Brown

Welcome to Episode 75 of the Coding Over Cocktails podcast, my name is David Brown, CEO and Founder of Toro Cloud.

She is a Product Strategy leader at Postman. She brings a wealth of experience in data science and APIs. She has been part of product development at startups as well as Fortune500s, PayPal and Twilio. She is a champion for applying product thinking to building API products, women in tech and data-driven decision-making.

She is about to publish her first book API Analytics for Product Managers that comes out February 2023.
Joining us today for a round of cocktails is Deepa Goyal. Hi Deepa, great to have you on the show!

Deepa Goyal

Thanks for having me, David, very excited to be here

David Brown

Excellent! Well, tell us what exactly does an API Product Manager do?

Deepa Goyal

Good question. I think “API Product Manager” is a very, very specific niche within the product manager space. And what makes it unique is really thinking of APIs as a product and building APIs with customer empathy, and trying to apply product thinking to APIs and building and commercialising them. So, the API Product Manager is like any other product manager but they're working on specifically API products.

David Brown

Yes, and I'm always interested in the distinction between a product manager and the technical side of it. And so, should a product manager have deep expertise in the product and solution that they're designing the API for, or should they be a technical guy or girl who understands APIs and their implementations, or should it be a blend of the two?

Deepa Goyal

It should definitely be a blend. I don't think that it's necessary to be like architect-level technical to be an API Product Manager. But, you do need to have at least user-level understanding of the technicality, because the product does happen to be very technical. So, if you think about APIs, it's a product that you're building for other people to build with. So your customer is essentially a developer who is building other products for their customers and that removes you from the end-customer by a degree of separation.

Your customers are very technical, so if you're not a certain level of technical, I think being an API Product Manager can be a bit of struggle. Again, I do believe in people's ability to learn. So I think it is great when people get excited, I think everything can be learned. But definitely having that technical understanding sets you up for success in the API space.

David Brown

All they need is a book called API Analytics for Product Managers to learn. How is the book coming along?

Deepa Goyal

It's going great. I'm actually finishing writing it in the next couple of weeks and then it's going to go into technical review and I'm hoping that I can speed it up and get it out there later this year instead of early next year. But I'm working on it.

David Brown

This is your first book.

Deepa Goyal

Yes.

David Brown

What prompted you to write the book?

Deepa Goyal

My own experience as an API Product Manager. When I joined Twilio, [it] was my real [experience] being an API Product Manager. I noticed that there isn't really much information out there on how to do API Product Management. I heard of being a product manager in the consumer space and the Fintech space. And knowing the craft of product management is one thing, but understanding the domain and the product and how B2C can  be very different from B2B products, even in terms of day to day can look really different. I felt that there just weren't enough resources.

And as I worked through it over the years, I actually have really detailed notes on things I learned along the way and some things were like, “This is so cool,” like you know the way Twilio organises their teams and I was really impressed by how their support teams and support operations work. And I learned a lot about how sales deals with products like API and just how much technical knowledge those functions also hold and we always think that developers are the most technical. So, learning about all these different personas as part of doing the user research. Being in Paypal, I learned a lot about developer experience and designing for a better developer experience. 
So I kept detailed notes and I felt like I really wanted to share it with anybody who is trying to get into this space and enable more people to be API Product Managers and enable more API products in general.

David Brown

And so that experience in Twilio, was that your first experience as an API product manager?

Deepa Goyal

Yes. I had been a product manager for internal APIs, built a few APIs internally but as a commercial API, that was the first.

David Brown

Okay, so that sort of brings me back to my earlier question as to the skill sets required to bring onto that role. So how did that role come about for you? What were you doing at Twilio before then?

Deepa Goyal

So, before Twilio I was at a Fintech company called Prosper Marketplace. And I had been a product manager there for about five years. I had been a payments product manager. I worked as a growth product manager and also I helped them build their partner APIs. So prosper is an online lending company. They have a double sided marketplace for lenders and borrowers. And for lenders, we build APIs that would help enable reporting for them and enable quicker decision making using these APIs, because previously they used to have all these file transfers and it was really slow and building analytical products on top of those APIs for investors to look at. 
So there's a couple different ways I came upon Twilio. One was the work itself. I had scoped and built and shipped APIs for different use cases. So that helped. And the other thing was I actually attended a few developer conferences with my team and the developers on my team and I started exploring Twilio APIs. It's just small projects and things that people presented and I found it really fascinating. That's how I learned about how the API itself is the product instead of being a supporting infrastructure aspect to the product. So that's really what got me excited about the API being the product.

David Brown

Yeah, what does it mean? What does it mean for an API to be a product? So you had deep product management expertise before you took on that role. So, what was the distinction for you for the API as a product?

Deepa Goyal

So I think the distinction is really whenever we think about any product and we try to describe it in very simple terms; like for example at Paypal, we are trying to enable more people to accept payments. And in order to do that we have APIs that people can integrate on their platforms or on their stores in order to accept more payments. So there is the “what they're trying to do” and there is the “how they're trying to do it.” 
And the same with Twilio, we're trying to enable people to build really advanced communication flows and communication experiences. In order to do that they can use Twilio’s many, many API offerings. And the “how” is an API, versus when we think about a commercial product or consumer product which is more like what I was doing, which is an online lending company for people to invest on the Prosper platform or like a lending club or a startup or any of these, they go to a UI. So the enablement, the “how” happens through a UI versus in a lot of these products, that “how” is happening through APIs.

David Brown

And so you came into that role, and were basically thrown into an API product management responsibility. You had deep expertise in product management. How did you transition to liaising with developers and stakeholders and leadership teams and all the rest of it? What approach do you suggest people take to that?

Deepa Goyal

So I think it's very important to first understand the product and understand the business side of the product and why this product exists. As product managers, we’re not always working on 0-to-1 opportunities. A lot of times, the product's already there and you come in at a certain lifecycle of the product. In this case, I was PM for their serverless tools and it was in beta at the time. And my goal as the PM was to find the right opportunities for that product to grow and mature, and set a long-term strategy and a growth path for that set of products. This is [for] Twilio Functions and Twilio Studio. 
And the interesting thing was the way I came into the role. First, I had to learn a lot about the differences between working on B2C  products versus B2B products, understanding the operations side of it, which is; in this B2B space of APIs, what are the different partner teams? Who are my stakeholders? So understanding the role of sales teams, understanding the role of my support teams, like how does all of that operate? Because customer success can look very different in a B2C space versus B2B space. In a B2C space, we don't really have sales and it's very marketing-driven versus B2B. [which] is very sales-driven. 
So understanding those functions, asking a lot of questions to my leadership around my manager and my leadership around how those functions align with us and how we can enable them and also understanding the tools they use. For example, sales teams use Salesforce and I would spend a lot of time digging into Salesforce data to understand what kind of data we get from there. And in search of understanding the customers and segmenting the customers, I was also trying to put that sales lens on who are the customers they care about the most? How do  they do their targeting? 
So, yeah, I think asking a lot of questions, trying to understand the bigger strategy was one of the first things that I started with, alongside trying to understand the product and the technical side of what we currently have and what are possible opportunities.

David Brown

So, if I understand correctly, was it the sales team or the end-users of the API you're managing?

Deepa Goyal

No, not the end-customers. These are the public APIs and public tools.

David Brown

Oh, okay so Twilio’s customers were the end-users. So, what I'm interested in is the balancing, the requirements of leadership versus the end-user. So did you go and have conversations with end-users in terms of what their expectations were of the API? And how did you balance that against the directions you were given from leadership?

Deepa Goyal

Absolutely. So, I spent a lot of time doing user research. I didn't have a dedicated user researcher, unfortunately. But I did actually create a structure around interviewing a lot of customers. And I did it two ways. One is I looked at usage data to figure out what are the different segments of users that we currently have in data. So we did have users, which is great. And I started with trying to interview different segments of data. And what I mean by that is in a publicly available product, it's not necessary that every customer is going to be an enterprise customer. 
So we saw the spread of users, some of them were like non-profits or somebody building an application for a church and somebody building an enterprise customer. So, we saw this big spread. And the interesting thing when you think about volume is somebody can be very successful using the product with only a hundred API calls a week. That's what they needed and they are getting it. And they're very successful. They're happy with the product. And somebody can be very unhappy making three million calls a week. So volume didn't necessarily mean success for the customer. 
And, the other thing is just the spread of customers we had. So, I studied a lot of the data on usage patterns to understand those segments and those customers and then based on that, I created a user research strategy in trying to make sure I talked to different types of customers so that I can understand better what kind of teams they had, how many developers they had and how they discovered the product, understand their customer journey because it could look very different for different customers. 
A lot of enterprise customers would come through sales but then a lot of individual or smaller SMBs wouldn't. They organically discovered the product but they could be really successful. So that was my strategy. I created a structure around the questions I asked to get data on things I'm trying to prioritise and understand their customer journey. And that really helped set the foundation of a lot of the conversations we had internally with the leadership in terms of how they're shaping the product.

David Brown

And how do you go about the API development process when you're talking to customers and they're giving you feedback? As you said, you came in when it was already in beta, so there was already something there to work with in terms of an API design. But if you're refining that API design, are you mocking the services? To what extent do you implement API-first design methodologies versus when you're already in beta, just making incremental changes to the beta and seeing whether they like the changes or not?

Deepa Goyal

So, not that much mocking. I guess we were not that design-first in our development approach but we did spend a lot of time doing user research in terms of once we understood that we have this variety of customers, we were able to have conversations around what kind of features they wanted to see and align that with our strategy. 
So, for example, an enterprise customer would want static proxy functionality and that's important to their security. It's important to their decision making. And  the chunk of the work is really how do we implement that in the backend? So, to the customer, it might just look like a simple toggle on their accounts page but there's a lot of machinery that goes on in the background to make it happen. 
And there could be very simple things that other customers want which are more in the realm of like, changing the API design or exposing a few new APIs. So, it's really [about] one; finding the balance of which ones to do and the other thing is we extensively use internal users to make those kinds of decisions. So, we didn't just look at external customers but we also had the sales teams and the support teams who are working with customers on a regular basis to be part of the design process so that we can get feedback because they have a good sense for the customers they work with, and get feedback on our designs to see what made most sense. Because a lot of times when you're API producers, a lot of things can feel very intuitive that are not very intuitive to the end customer. 
So, having a good input mechanism from our sales team, support team, or our internal power users at Twilio was really great. And in addition to that, we also had a lot of bata programs where we had developers that were just more engaged with Twilio and signed up to be part of beta. So, the way we would release features assured us that we would release it to a limited set of customers. They would try it out, we would get feedback and then grow the user base instead of doing it all at once. So that incremental release really helped get a lot of feedback through the development process.

David Brown

Okay, well your book is called API Analytics for Product Managers. So what sort of analytics are we talking about that a product manager would be interested in?

Deepa Goyal

So, There is a whole set of infrastructure APIs that we generally look at like uptime and things like that. But I think from a product manager [view], it's a little bit more of a business lens and the customer focused lens on analytics. And that ends up measuring the customer journey and answering questions like how are people discovering your APIs? Are they able to try it out? 
So, when I think about trying to build metrics on top of the infrastructure metrics, we have the product metrics which are around the customer and then we have the business metrics which are more around revenues. I think of it in three different layers. And in the product metrics, we think about discoverability of when we put our documentation. We are doing SEO optimization, for example. So, if I'm making another API for payments and there's already multiple players, are people even able to find my product? And when we put out video tutorials or YouTube or we do social media marketing, are we able to reach the right audience? 
So, that's the most top-level metrics on discoverability. But from a usage standpoint, we start to think about Time to First Call or even a number of sign-ups. Actually, let's start there. It's like a number of sign-ups per day. Are developers able to find the API? Are they signing up to become customers or are we getting enough user creation per day? And then, how many of them are actually able to reach their first API call? Because that also tells us a lot. For example, the sign up process for getting your credentials should get and potentially have a lot of friction points. Do you need some kind of an approval or can you just sign up and get your credentials in two minutes? Or does it take two days? So that can make a big difference. 
And then thinking about things like Time to Value, which can depend on a lot of different things. So for example, depending on how complicated our sandbox design is, does the customer make the first business transaction immediately? If they have a lot of approvals needed then they might not do it for weeks. So for example, when we look at Stripe, they don't actually have a very complicated sandbox. You can sign up, make a first transaction fairly in a couple of days, make a first production payment, versus in Paypal [where] it can take weeks or months. 
So because you will spend so much time in the sandbox, then going to production will be complicated. So [we’re] measuring all these different aspects of the user journey to measure the product that lead to business metrics like revenue and how customers scale.

David Brown

You mentioned a couple of things there. You mentioned Time to First Call and Time to First Transaction. Can you run me through the difference between the two? Because I know you want people to evolve to monitoring Time to First Transaction. So, I just want to clearly understand the difference between the two.

Deepa Goyal

Yeah, absolutely. So, I think payments are a great example. You can make a first API call which is like a test call, a dummy transaction in your sandbox account very easily. But in most payment APIs, you wouldn't actually move any real money until you get business approvals and you have to submit all this paperwork. And as a consumer, you can sign up, get your credentials, start testing out transactions in your development environment and that would be Time to First Call. But you would need a lot of paperwork and approval to actually get to moving real money that goes through a bank and is a transaction that is processed. So, that would be business value and so that would be the difference. So the way I think of it is, Time to First Transaction happens a little after Time to First Call. 
Another scenario where you don't have that kind of paperwork required is probably Twilio. So at Twilio, when you sign up, they give you free SMSs per month to enable developers to build. And the way we measure value is not just Time to First API Call, because you can sign up on Twilio really quickly, get your credentials, build a simple app. There's a lot of copy-paste code. You can really get it under like five minutes. You can make your first Twilio app and make an API call. 
But from a business standpoint, what we consider value is when a customer reaches 100 hundred API calls because that's when they have built their application to a point where it's significant and they're reaching value. So, it's also depending on what we see in terms of patterns, because you can send an SMS in your first API call but that doesn't mean that you have read success using the product. So, sometimes it can be as black and white as, “Did they move the money in terms of financial APIs?” But in terms of Twilio, it could be something that we set based on usage data.

David Brown

So, presumably as an API product manager, you want to minimise both. You want to minimise Time to First Call and Time to First Transaction. Time to First Transaction sounds like perhaps a more difficult thing to resolve if it's going to require, as you say, approval processes and the like. Whereas the Time to First API Call might be more of a technical type of thing and documentation and providing access to API keys or whatever it may be. But so, how do you get involved in that process of looking at those metrics the time to first transaction and then optimising as a product manager?
Social card:

“I don't think they're competing metrics [Time to First API Call (TTFC) and Time to First API Transaction]. They're really linear. If you improve TTFC, then you can improve Time to Value. As an API Product Manager, I am looking at the fact of how long it takes for a customer to get to TTFC and then breaking it down to understand which customers get there faster and how, and trying to understand that journey better.”
[0:26:38] Deepa Goyal
I'm looking at both. And personally I feel like it's incorrect to compare the two. I don't think they're competing metrics. They're really linear. If you improve Time to First Call, then you can improve Time to Value. And the other thing is, as an API PM, I am looking at the fact of how long it takes for a customer to get to Time to First Call and then breaking it down to understand which customers get there faster and how, and trying to understand that journey better. 
And Time To First Call impacts teams like developer relations, for example. They are producing all this content that is trying to get people to create their first application or try it out. So, if there are certain channels that are working better, certain content that is working better or certain documentation or parts of documentation that are more confusing, that's leading to customers not being able to get started. 
Let's say there is the user flow, like the sign-up process is confusing or people couldn't find the login page or things like our load time of the page is slow. It could be any number of things that could be leading to the user not getting to their first call. As the PM, I'm looking for those signals and trying to understand all the different things that are working and all the things that are not. And then based on that, trying to figure out what we can do to improve those pain points.

David Brown

Makes sense. You have now transitioned to the role of Product Strategy Leader at Postman. Tell me about the role there.

Deepa Goyal

So, this role is a very interesting role where I'm thinking more about how to shape strategy for Postman and also how to enable API strategy thinking for people who are using Postman. So our customers at Postman are a very broad spectrum. There are, of course, developers who are very successful using Postman. We also have enterprise customers who are looking for different things than individual developers. 
And in terms of strategy, we do two things. One is of course, how we evolve our product to better serve a wider audience and see where the industry is going. And the second thing being, really how do we enable all these companies that are trying to build APIs using Postman as primary or in combination, irrespective? How do we shape that conversation so that we can enable more companies, more people to build successful APIs?

David Brown

That's a challenging role. How long have you been in the role now?

Deepa Goyal

A little over three months now?

David Brown

How's it going? Is it also talking to the same deal? Talking to a lot of customers and that sort of stuff to get familiar with it?

Deepa Goyal

Absolutely, yeah. I really enjoy talking to customers. That's definitely one of my favourite things about being a product manager, it’s just how much I get to learn from our customers. And it's really interesting to see how much excitement there is for APIs. There are so many companies young and old who are now thinking of APIs more seriously and they want to build API businesses. 
I think for the longest time, developers have been champions for APIs. They understood the value prop. But I think the business side of a lot of organisations are still now onboarding onto that train and now starting to think like, “Okay we do want to invest in APIs. But how do we go about it?” So that's where the interesting challenge is, it’s how to help them shape their API strategy based on their scale skills and based on their scale based on their business and domain. Those are really interesting

David Brown

You said that, I mean I think postman has 30 million plus users. So dividing those into cohorts of, you've got all sorts of size organisations and individual developers using it as a product strategy leaders, do you break into cohorts and have different channels to sort of listen into that sort of conversation and their needs and requirements

Deepa Goyal

Absolutely swell direction. 20 million. Not

David Brown

yet, hopefully soon,

Deepa Goyal

definitely. So we do study our customers pretty closely. we published our, recently we published our State of the API report, which is basically a survey done with 37,000 participants. so that's one of our kind of flagship surveys where we try to learn the industry and the where people are at, but also otherwise we have a lot of conversations with customers to understand the different cohorts., and it's really interesting to see the there's so many users who are just developers using postman and it's not really an organisation versus, there are some that are, there's a lot of users who are driven by an organisational decision. So I think a great example is like then any developer can sign up and start using postman, but once you start having, a lot of users from your company, let's say are using postman, then suddenly your security team is wondering if this is safe enough or into the have any controls, What can, how they can be better admins of the stool can. So, so that's where things start to get really interesting, is like how these other adolescent functions start to think about postman in terms of it being a tool and then how do product managers start to think about what we can do. For example, when I was a Paypal, I launched the papal public collection., and I was looking at postman as a, a marketing channel essentially to help discover ability of paypal api like you have 20 million developers on this platform. If we put out an official papal collection, then these developers can very easily get started with Paypal A B S. So there's all these different personas and perspectives that really vary in terms of what they want and depending on how big their organisation is and what their priorities are

David Brown

deeper. I know we're waiting for your book come out in early next year in the meantime, how can our listeners follow you and your blogging regularly? So how can our listeners follow you on your blogs and social media.

Deepa Goyal

Absolutely. So you can follow me on linkedin, Pippa Goyo, you can also follow me on twitter. My handle is one Sprint at a time and my blog is called one Sprint at a time dot com because the greatest products out there are built one Sprint at a time.

David Brown

Great tagline deeper. Thank you very much for your time today and good luck with the publishing that book.

Deepa Goyal

Thank you so much. Really, really happy to be sharing this with all the audience and really happy to be here. Thank you!