Podcasts

Podcast with Jeremy Glassenberg on API Product Management Best Practices

Podcast with Jeremy Glassenberg on API Product Management Best Practices

Episode 1 from Moesif’s Podcast Network.

Providing actionable insights for API product managers and other API professionals.

In an expansive discussion with Moesif advisor and expert API Program Manager, Jeremy Glassenberg, we cover many of the most important issues affecting PMs today, including: how to achieve 10x results, which are the best tools to enable APIs and how to avoid the most common mistakes when designing and launching APIs.

Jeremy Glassenberg is an 11+ year veteran in building APIs and monetizing developer platforms. As employee number 20 at Box.com, he was their first PM, started the DevRel team and grew the dev community to more than 15,000. Since then he’s held product leadership roles at Edmodo, Pinn, Tradeshift, Deserve and now Docusign. Jeremy also advises and mentors PMs and startups, and is currently the Lead Product Management Lecturer at Product School.

Friend of Moesif, Kunal Punjabi, chatted with Jeremy over two days. The following is a condensed podcast of their discussion.

Moesif · PM Best practices with Jeremy Glassenberg


Listen to the episode on SoundCloud above, watch it on our YouTube Channel or download it on Apple or Google.

Listen on Apple Podcasts Listen on Google Podcasts


Table of Contents


Kunal Punjabi (friend of Moesif): On today’s episode we’re speaking with Jeremy Glassenberg, who I’m very excited to have on the show. Jeremy is a platform product management leader of over 11 years. Most recently, he has been the VP of Product at Pin, and before that, Jeremy was head of platform product management at companies like Box, TradeShift, and Edmodo. As head of platform at TradeShift, which deals with supply chain technology, he led the design of TradeShift’s new developer frameworks, documentation, and developer tools. At Edmodo, which deals with education technology, he grew the Edmodo app store to over 500 applications.

Prior to that he was the first platform product manager at Box, where he founded their developer relations team, created a community of over 15,000 partner developers, and was involved in building and monetizing the Box Platform. Jeremy, thank you so much for being here.

Jeremy Glassenberg (expert Product Manager): It’s good to be here, Kunal.

Kunal: Great. So Jeremy, I want to spend our time today on a number of topics: platform and API product management, and we’ll touch on a few of the stories and elements on organizational behavior as well, and then we will finally wrap up with some advice that you have to give to other product and growth professionals that want to achieve those 10x results that we’re all after. Does that sound good?

Jeremy: Yep. That sounds good to me.

Differences in Managing APIs vs Apps

At its core, platform product management is still product management, so APIs should be designed for the actual use case of the developer community, by applying proper product processes. PMs often conduct lots of A/B tests, iterating the product, but with APIs they need to watch backwards compatibility more closely than with apps.

Kunal: So, I’m excited to have you on. I’m going to start from the very beginning, so let’s dive in. Our first question, how is managing product for a platform different from managing product for a consumer or enterprise product?

Jeremy: Yeah, I’d first like to emphasize that platform product management at its core still is product management. So, I’d like to emphasize the similarities before getting into the differences. Very often, people do treat APIs differently, too differently from other areas of product. Sometimes they believe in the “just have it built by engineers for engineers,” and not that engineers shouldn’t be involved in designs or even driven by design - at places like Stripe, APIs were designed just by engineers. In fact, Stripe had over 300 employees before they needed product managers at all, before they had product managers. But, they still were applying product process. Very often, I see companies figure this is just a technical challenge, “we need to build something for engineers, let’s just hand it off to our engineering team, and provide really no context.” What we see then, are engineers taking whatever APIs the company already has internally, slapping documentation on them, and thinking it’s going to work. It’s the number one reason why we’ve seen so many APIs fail over the years, they’re not designed for the actual use case of their developer communities. What we have to actually do instead, even though this is for engineers, it’s still treated just like a product problem. It’s just that your customer happens to be more technical. If you apply proper product process, what will we do? Well, what are the kind of apps that are going to be built by the developer community? What kind of apps do we want them to build? Who are those developers going to be? How do you make it as easy as possible for members of that developer community to actually build those apps? So, we focus on the customer and work backwards.

What we see consistently, is that the APIs designed for the external developer community are not going to really be the same as those internal APIs. Now, where things are different, after applying proper product process, is the understanding that the customer is different, the customer is technical, so what we’re building will be a different product. Number one, UX and UI. Okay, APIs don’t have that much of a UI component to it, although the user experience does matter when it comes to designing good documentation, a good developer portal. That’s why we’re seeing a lot of teams now, in places like Stripe, have something called “developer experience”, in addition to API platform product management.

Also, the style of iteration is going to be different in the world of API product management. This I think is the most important for any product manager who starts working on APIs to understand. In the world of product management, we have to experiment, we have to iterate, conduct A/B tests, make a lot of small changes and seeing the results, and if those don’t work, reverting them or continuing to build upon them. In the world of APIs - yes, we want to iterate, we want to experiment - but we have to watch out more for backwards compatibility. Little changes in the API have a big impact, they can break a lot of applications, or they can break a small number of very important applications. The way these integrations work, the way developers interact with APIs, it’s more sensitive than when you’re just working on the interface of a consumer facing product.

So basically: A) still treat this like a product problem, but B) understand the rules of API product management, especially backwards compatibility. That goes back to developer empathy, and just understanding how to design your product for the long-term in a way so that you can iterate, but in a way that’s still different for what you may do anywhere else, where you’re focusing just on a UI product.

Learn More About Moesif Moesif Makes Managing APIs Easy 14 day free trial. No credit card required. Learn More

Tools to Standardize API Design

To make it easier to create and use RESTful APIs, standardize your design around the OpenAPI schema.

Kunal: Makes a lot of sense, Jeremy. Can you tell us what tools you use to enable standardization of API design, which makes it easier to create APIs for developers to use? Maybe that involves frameworks for designing APIs, opening API specs, or services that can auto-generate this stuff.

Jeremy: There’s that issue of backwards compatibility in APIs. That does make API design different from other areas of product. Do you design APIs for backwards compatibility? There are ways of building APIs such that you can make certain adjustments, add optional input parameters, add to the output without breaking existing applications. We have to design your APIs so that you can make those adjustments over time. We have found, there are certain standards that help with that - RESTful API architecture, there’s also GraphQL now, it’s another kind of standard for design, and these APIs are designed for these types of standards.

They help on two fronts: 1) ensure that you are designing APIs that are pretty scalable, 2) designing APIs that are consistent, not just within your company, but with other companies, as they’re designing their APIs. Now that we have APIs on a RESTful standard, it’s easier for other tools to integrate. So we’re seeing these connectors like IFTTT, Zapier, Mulesoft. It’s much easier for you to implement integrations and connectors with these services, and even if they’re providing different functionality, they’re doing it all under certain kinds of consistent standards.

Now, to build on REST, what’s basically become the standard for RESTful design is the OpenAPI schema. It’s basically a definition file for: what are the function names, what are the inputs, what are the outputs. Let’s make sure the outputs are consistent, and if you define your API in that schema, there are a lot of tools built around that. So, it’s very easy to generate good API documentation right off of that schema. It’s also easy to generate some basic API libraries, if you want JavaScript library, Pipl library, so you can give the developer community some starter code. You can auto-generate it when you have that schema.

I’m very emphatic about using the OpenAPI schema, that’s become the de facto standard for RESTful architecture. For those who are thinking about GraphQL, I don’t think we’ll have too much time to talk about that, but GraphQL was launched with this schema. Just build on it and it’ll help you to design your APIs well and then allow you to more easily launch all these other things that make for a good developer ecosystem.

Learn More About Moesif Quickly Resolve Design Issues 14 day free trial. No credit card required. Learn More

Character Traits of Successful PMs

The product manager who is most effective working cross-functionally with other team members is the proactive one — they solicit feedback from others and present a balanced assessment.

Kunal: Awesome. What are some of the different types of personality traits you come across in working with PMs and other cross functional team members? And, which ones have you found to be the most effective?

Jeremy: When I’ve seen product managers, there’s actually a spectrum in your style of interacting. We’ve talked about how there are ineffective PMs. The most ineffective I know of are the pushover PMs, the ones who when something comes in from sales, the goal of the company just get sales driven. Or something comes in from a manager and they just do what they’re told.

I’m emphatic, by the way, as someone who has been the first product hire at several startups, that your job as the first PM at a start-up is to support the vision of your founder. Supporting the vision doesn’t mean building everything that they ask you to build, it does mean questioning, criticizing the vision, and sometimes flat out saying “no.” You’re responsible to execute, you may actually come from your own research data that says this is not the right idea.

One side of the spectrum is this pushover, the ones that are very friendly, but it’s easy just to crush them. Someone is going to come in with an idea, and if they’re a strong personality, the strong personality wins. On the opposite end of the spectrum, and I’ve seen this one misinterpreted, the bulldozer PM. The one who does whatever is necessary to get something done, and they will leave a trail of destruction in the process. What I also find is that the bulldozer personality is associated with ego. Ego is not correlated with empathy, and so these bulldozer PMs are more likely to be driving their own ideas, what they think is cool, not based on real data, and they’re going to force the company in the wrong direction.

What we have in the middle, you start to get into the sweet spot. My favorite is what I call proactive. That means you really are trying to get feedback from other people. It’s not necessarily about consensus, it’s not about saying “yes” to everyone. But you want to actively get feedback from everyone, you’re very much listening to people. At times, you’re saying “no,” at times you’re not waiting for someone’s permission. There is always that “do you ask for permission or beg forgiveness,” there’s something in the middle of the proactive range, where you let people know what you are going to do, and you give them a certain amount of time to respond and challenge you. If they don’t respond, by default you will take action because you have to take action. You can’t just let them stall by not responding or not prioritizing this thing, but you want to make sure that they know what you’re going to do and that they have an option of coming to you if there is a concern.

There’s one more that I noticed. I used to just say that there’s pushover, bulldozer, and proactive, but there is one more that I’ve seen. I call it aggressive, where the person does have good ideas, they do listen to people, they are high in empathy, but they struggle a bit in communication, and maybe they are pushing something a little bit harder than they should. They may be unintentionally interrupting a conversation, they may just have a little bit of sensitivity, it’s hard for them to take criticism. And so, they’re not pushing hard, but they may still be a little bit difficult about getting feedback, about interacting with people, and they may push a little bit more than they’re supposed to.

I emphasize if you’re hiring PMs, watch out for a pushover. Either train them, and if they’re ineffective, transition them out, they shouldn’t be a PM. Bulldozer- flat-out fire them. Give them a chance if they’re a junior, but if they’re senior and they’re doing it, don’t deal with them because you’re probably dealing with narcissism. If they’re aggressive, try to alleviate their concerns, it may be a discomfort thing, or it may be okay to just try to work with it. You can work with it, but the ideal is someone who is proactive.

Learn More About Moesif Get Actionable Insights With Moesif 14 day free trial. No credit card required. Learn More

Kunal: That makes a lot of sense. Where do you fit in the range, out of curiosity? Everybody I’ve found shifts at different times, so which ones have you found yourself fitting into the most?

Jeremy: At times I may have been a pushover, and at times I may have been aggressive. As I developed more customer empathy and told myself “don’t just build what I think is cool,” as I learned to not just do what the executive was telling me even if it was a good idea, I managed to get myself into the proactive range. I do think as you develop experience, as you get really good at a job, to be successful, be more and more in the proactive range and stay in that range.

There really is no reason to ever go pushover or aggressive. When you’re in that proactive range, there is flexibility in how to respond depending on the circumstance that you’re in. Sometimes you’re really making sure that you’re listening to people, sometimes there’s a strong personality on the other end and you have to seem more aggressive by pushing back harder, but it’s not actually being aggressive, it’s part of being proactive in just dealing with the different circumstances.

Defining APIs

APIs are the stuff that lets some stuff talk with other stuff

Kunal: So, we’ve all worked with APIs, but how do you define an API?

Jeremy: Yeah, my parents still struggle to understand exactly what I do. In its simplicity, I say that an API- and usually I focus on web APIs- APIs is the stuff that lets some stuff talk with other stuff. Let’s dive in deeper and say that APIs are a way for code, for applications, to communicate with each other. So, when I am going to www.gmail.com, what’s happening is that the browser is going to Google and Google is sending data, my email information, and also information on how to create an interface- HTML and JavaScript and CSS- that I can see.

It’s a way- HTML and all this- is a way of translating computer stuff, when I’m asking for information from Gmail, into something I can see. APIs is a format by which an application can go to Gmail and say, “I need this information,” and it provided it in a form that the applications can understand. But all it’s about is allowing applications to talk with each other.

My simpler example, I usually go into just a mobile application, I say “have you ever worked with some app that wasn’t built by Facebook, but it clearly connects with Facebook?” That’s how it’s done, APIs are the way that Facebook lets other applications interact with Facebook so that you don’t have to interact with Facebook directly. I mean, in addition to interacting with Facebook directly.

Value Prop of APIs

Make sure you have a clear business reason before developing an API, such as: enabling new third-party features, scaling customer acquisition or increasing stickiness.

Kunal: Right. What is the value proposition of an API or a developer platform? And you mentioned that there’s a number of business models and value props for platforms, can you talk about that a bit?

Jeremy: There are many ways that an API can benefit a company. We’ve already talked about- Box had three ways that did bring us customers, providing features that we couldn’t build ourselves, and also enabling customers to connect Box with all the stuff that they had.

In Edmodo’s case, it was about enhancing the educational experience by letting third-party educational app developers, that were trying to get apps in the hands of teachers, do it and then allowing teachers to bring apps into homework assignments, into their class more easily. Sometimes, it’s about stickiness, sometimes it’s about up-sell, sometimes it’s about bringing in new customers. There are many models. It is important though, to know what those are before you start building APIs.

I turned down an offer from a unicorn start-up once, that was super excited about APIs- half the VPs, and the CEO, and the CTO. They were all ready to invest in APIs and said they were committed- what was the reason? Because, if we don’t build APIs, we are just not going to stay competitive, and we’re going to fail. At one point, I meet the VP of sales in the interview process. The VP of sales was very excited, and I said, “so what were the use cases for APIs?” Got a blank stare. I asked “Ok, let me rephrase this, what are some cases where-“ because this is a consumer sales driven company, it was a BDB company that relied on direct revenue from customers, so I asked- “So, what are cases where you couldn’t close a deal because you’re missing something- you just couldn’t solve this one problem the customers had, that you think could’ve been solved by integrating with a partner?” Not much.

But you know, Box had less than 20 people, the use cases, the value proposition was there early on. But even at that unicorn company, it wasn’t really there. They were trying to build APIs because they thought it was cool. I didn’t take an offer, and I’m glad I didn’t. I’m not going to say who it was, but the APIs didn’t go far there. I interviewed there a couple of times, and every time there were different people running the developer platform. Every time, I would share a few ideas of what I thought were good use cases, and I’d find that either they were already launched or they were about to be launched, and they really didn’t have any other use cases.

Finally, a couple years later when I interviewed there again, they basically said despite having- I don’t want to share the name so I have to be careful about who they were- but it was tens of millions of users at least, a very large company, logically there would be a need for a platform, but they evaluated it, and based on what they were building, they said they have a need for an API. But the use cases were fairly small. That small number of use cases were very important, they were generating a lot of revenue, but they realized they didn’t need a massive platform, they kind of figured that out over time.

So, you do need to really think over when does it make sense to launch a platform? I actually say, play conservatively here, don’t do it until you see a key opportunity- either bringing in new customers, stickiness, needing to close sales deals, knowing that this solves a problem you know your customers have.

Learn More About Moesif Know Your Customers (KYC) with Moesif 14 day free trial. No credit card required. Learn More

Business Models of APIs

At the companies Jeremy’s worked at, the business model for APIs was to offer a platform that was complementary to a customer-facing service that the company was already providing. In developer-first companies, the business model is monetizing access to the API itself.

Kunal: Makes sense. What are some of the business models that you’ve found that can be built on top of APIs? We talked about the value proposition, and valuable important use cases, that is really important before you invest in a platform in an API stack, but what are some of the business models that can come out of that?

Jeremy: If I were to summarize these ones where I’ve been, these were all cases where the platform is complementary to some sort of customer-facing service the company is already providing. Box provides an interface, mobile apps to upload files, download files, organize and collaborate. Edmodo was for teachers to interact with their students, there was an interface to it. The APIs were complementary to that core product.

In those cases, one of the business models was just satisfying customer needs, getting new customers, solving problems for customers. Yes, Box had some sort of a rev-share, but the bigger thing for us was really just solving our own customer problems through third parties. They tested monetization other times. Sometime after I left, they actually got very creative, and to encourage developers to build integrations. They had a rev-share by which they would basically say, if a high-paying customer is using a certain application heavily, regardless of whether that customer came directly to sales and added that integration later, Box is going to pay out a rev-share to that app just for being used by a paying customer.

At Edmodo, the model was more of a monetization play, where they wanted teachers or administrators to pay for these applications, and then there would be a rev-share between Edmodo and a partner. The marketplace was both for stickiness, to keep our teachers active in using the product, but also an upsell, giving teachers and administrators a reason to actually pay for Edmodo by buying these third-party apps.

There was some direct monetization through a revenue share with a partner. Now there are times where you just flat out charge for API usage. Box did charge for API usage when we had customers building apps for internal use. At companies like Twilio and Stripe, where the product is fundamentally an API, what they have to do is just charge for actual API usage. So then we talked about there, there were 4 or 5 business models among the dozens of business models for platform role, but hopefully this gets you some starter insight as to how to do it.

Unique API Product Management Challenges

PMs need to be technical and possess developer empathy.

Kunal: For sure, Jeremy, what are some of the unique product manager challenges when it comes to APIs?

Jeremy: I think we talked about some of this already, but I’d say first, treat this as a product problem. This is where I think some of the API platforms can be unique in that they do have to be technical, but they still have to have customer empathy. That’s why I’ve seen a lot of product managers fail here. Sometimes they are great at customer empathy, but they don’t have experience in developer empathy. Sometimes they have experience on the technical front, but it’s not sufficient.

I’ve seen a lot of APIs built, they have the RESTful architecture, but they still aren’t designed for the needs of the external community. So, the big thing is to treat this as a product problem, and I think the rest is to really watch out for challenges of backwards compatibility. Knowing RESTful API architecture and the OpenAPI specification will be very helpful - those are tools to guide you.

It is best to dive in deeper and understand from other experiences: what to watch out for to make sure that your APIs will scale as you need to expand the API endpoints, add to the endpoints, and basically continue to enhance your APIs over time.

Learn More About Moesif Better Understand Developers 14 day free trial. No credit card required. Learn More

Common Mistakes Launching APIs

Mistakes when launching APIs include: giving too little context for the API, basing the functionality on an internal API or a mobile app, and following a “set it and leave it” mentality.

Kunal: What are some of the most common mistakes you see people making when designing and launching APIs?

Jeremy: We’ve talked before about developer empathy. How I have seen this play out in practice. The first being, “let’s just make it by engineers for engineers.” Hand it off to the engineers, give them no context. The engineers are working on other things, thinking “What do I do with this? Ok, well we already have a bunch of APIs, and maybe have an OpenAPI specification for our internal APIs… So, let’s just make some good documentation, make it possible for developers to register API keys, and then just launch that.”

What you have then are a bunch of APIs that are based on internal use cases. What are those internal use cases? Probably really closely designed to your database. It’s like a product manager saying, “OK, here’s what we need to build, let’s go and design the database first, and then just slap an interface on the database and assume that that’s going to work.” That’s how you have the Pied Piper app kind of situation.

The next level of error I see is where they say, “Okay, we have an API that was used for the mobile application that we built, let’s go and open that API to the public.” That’s better than just launching these internal APIs based on your database, because here at least it was based on some sort of an external use case. That mobile app, that was customer-facing, but it’s only one use case experiment, it’s very limited. So, it will work a little bit better, but it’s still not going to work that well.

How to do it successfully is to think, “What are the apps that we need from the community?” and work backwards. I’ve written some blogs, used to do some writing for programmable web, where I reviewed APIs that they would launch. I could tell that some popular companies launch their APIs taking one look, that this was a case of taking some internal stuff, slapping documentation on there, and just launching it. I would interview these companies and confirm that’s what they were doing. What are they thinking? “Oh, this is just an MVP, we’re going to get feedback.”

Product managers know that an MVP isn’t a bad product, it’s a minimal product. You’ve probably planned out something better, a long-term plan, and you figure here’s where we start. Taking our internal APIs and slapping docs on there, that’s not doing that, that’s not an MVP, and then they wonder why it fails. They also have this philosophy that you don’t see anywhere else in product management, this “set it and forget it” thing. The whole idea is you don’t need business development anymore, you can just make this thing self-service. And they also think that goes with, “if you build it, they will come.” I literally hear that verbatim, “if you build it, they will come” when it comes to APIs.

We know it doesn’t work anywhere else in product management. You can’t just build what you think works. Maybe you built it according to product process, you still have to launch it properly. In fact, if we actually look at where that quote, “if you build it they will come,” came from. It was the movie, “Field of Dreams,” where what they actually bring are the ghosts of the White Sox players, who actually took a bribe to throw a World Series game. It was a great movie, but when you think about it, even in that movie, “if you build it, they will come,” the philosophy there didn’t really bring the kind of customers you ordinarily want.

Learn More About Moesif Track How Your APIs Are Doing 14 day free trial. No credit card required. Learn More

Biggest Successes Launching APIs

To really make your APIs successful, get very close to customers, so that whatever you’re building is going to be aligned to their needs.

Kunal: Okay, so we’ve talked about the failures when it comes to launching a platform in APIs. What has contributed most to your success in launching APIs and platforms?

Jeremy: That goes back to developer empathy. I think I can share a good story at Box, where I am just getting forced to do the right thing. I initially wasn’t applying good product process, and we got lucky that the right circumstances came about. When I joined Box, I was focused on supporting certain types of partner integrations. There was a challenge at Box, where they needed to set their goals right. For a little while, there was a goal of just getting as many partners as possible. That wasn’t aligned with getting partners that actually generated value. I was working on these because I thought all these partnerships were kind of cool, and that was creating some friction with the sales team. They were getting frustrated; they were taking up time for these integrations when they had clear customer requests. Not getting in the whole “don’t be sales-driven,” but what I will say is that the Box sales team didn’t want the company to be sales-driven, they did believe in the company being sales-influenced, that we should be taking their feedback.

What ended up happening during this time of friction with sales, is at one point I was brought into a customer call to help them with something where they thought an API may come up. It ended up being significant, more than we realized. This was a very large customer in the company’s history for that time, and they’re asking for some very one-off features.

The sales team actually was about to say no to the deal, because they understood that it’s not worth forcing engineering to build something really custom, a one-off just to close a sale. They didn’t want the company to be too sales-driven that way. They were about to actually say “no” to this deal. I said, “Hey, this is entirely your decision, but to make sure all options are out there” based on what they’re actually trying to do, the stuff that’s custom, “I think if we build a couple of administrative APIs that we know other customers down the road are probably going to want and we ask them to build and maintain the other stuff that’s really custom with the pitch that it’s in their interest to do it because if they need to update it, they can do it freely. We might be able to make this work and not have to actually do anything that we have to maintain that’s just for them.” That’s what got this conversation started, that became unofficially, a sales engineering process.

By making my way over to suddenly becoming a company sales engineer, which I didn’t want to do. I couldn’t stand it, I got really frustrated at times. But looking back, it was the best thing for my career because it forced me to develop that customer empathy and get very close with the customer. From there, apply proper product process and say going forward, whatever we’re building on the APIs is aligned to the needs of our customers.

In Box’s case, early on, it took a little while to really argue with a lot of people that had mixed opinions about the platform, that this is worth doing. I was solving problems directly for the customers, and as Box got more data driven, I could pull up the numbers to show them we had a small team, that we were generating value, that we were a necessary part of the sales process that could then justify expanding the platform more, but again, based on what the customers really want.

Learn More About Moesif Deeply Understand Customers 14 day free trial. No credit card required. Learn More

Strategies to Grow Developer Ecosystem

To make your developer platform successful design it with a set goal in mind, build it to be self-service and provide exemplary support.

Kunal: Makes a lot of sense. What are the most effective and ineffective strategies for growing a developer ecosystem?

Jeremy: First, know the use case, that goes back to developer empathy. What are the kinds of apps you want? What are the goals? Is this about getting new customers? Is this about monetization, do you want to have an app marketplace? And then designing everything accordingly. The next part, that secret sauce to Box and to Edmodo, was understanding developer relations.

As John Musser noted in that top 10 list, “What Developers Can’t Stand Working on API,” 8, 9, and 10 were about API design. 1, 2, and 3 were about support documentation, and communication. I learned that when I was at Box. In the early days, our APIs were not RESTful, they were not going by generally recommended design guidelines. There were quite a few issues with the API product itself. We were able to work around it by building a few solutions that we knew to be important for developers based on their feedback. Also, we were just highly responsive to developers when they had questions.

Many times, developers were coming to Box, after trying to build on one of our competitors, and I’m not going to say which ones. They would come to Box after initially hearing about a competitor and then say, “we want to work with you more because you’re actually answering our questions.”

I remember one time, 4 o’clock on a Sunday, a developer reached out to me, complaining about the design of our APIs. Which was rare because we had built these API libraries and tools to cover some of the limitations of the APIs themselves. But before 4:30, he got an email from me saying, “Thank you for your email, we completely understand. Yes, we know that certain APIs are not RESTful, it’s more the style of API, we are working to improve upon it. It’s going to take some time. But in the meantime, people have just been working off our API libraries, and that’s done the trick.” That developer responded, just completely surprised. He wasn’t arguing with us, he was just being very direct with us, and he was just so surprised to get a response in under 30 minutes on a Sunday.

I always say design developer platforms in principle to be self-service, but in practice, developer relations and developer support is vital to the success of a platform.

Learn More About Moesif Understand How Developes Adopt Your Platform 14 day free trial. No credit card required. Learn More

What is a Developer Platform

When others have built new businesses that are running on your system, then you’ve created a developer platform.

Kunal: How can a company turn APIs into a developer platform? What are the steps you need to do, and how do you know whether you should do it? How do you know that you’ve gotten there once you’ve started doing it?

Jeremy: I think we’ve already talked about use case, making sure that you only build APIs when there’s really a need, designing those APIs accordingly. Or I could get into when we would say that this is actually a platform and not just APIs. It is very common for companies to start with APIs, allowing a mobile app to integrate, but is that really a platform?

I’d ask how you define a platform, in particular a developer platform. That word has been used a lot in the last decade, it’s quite a popular buzzword in Silicon Valley. I have my own definition, there isn’t really an official definition of a developer platform. I can say at its core, it becomes a platform when applications can be built entirely on what you’re providing.

If you just have APIs, others are building apps, running them elsewhere, they’re connecting, and the way they’re integrating is a simple feature, you have APIs. When you start to see a product that’s built entirely under APIs, like in Box’s case. A desktop application in the sidebar that’s syncing constantly with Box and providing particular information for customers, this is now a product that relies entirely on Box.

Is it that the tech is dependent? Or is it that the business is dependent? I think it’s more important that you have a business that’s starting to run on your platform, and products being built that are built entirely by working off of your platform. One shortcut I do have though, if you have a pretty nice system for apps to integrate into your interface itself, then you probably already have a platform that’s literally running in your UI. Although, I think the real clear definition is, when you’ve built it such that new businesses are created and are running on your system. Which is really one of my favorite things about building a successful developer platform.

My top two really were getting to build up product teams, developer relations teams, training developer advocates to become product managers who created those jobs, and are helping people get their careers started. But then also seeing partners really succeed, businesses form, people literally creating companies that are running on your platform, allowing these businesses to happen. Those business opportunities just never would’ve happened otherwise.

Learn More About Moesif Get Your Developer Platform Up & Running Fast 14 day free trial. No credit card required. Learn More

Ensuring API Backward Compatibility

Follow a rigorous schedule when modifying APIs and especially when sunsetting APIs

Kunal: That makes a lot of sense. What are some tips that you have to give companies when they are rolling out a new release of their APIs? You’ve talked about backward compatibility and breaking changes, but how do you ensure backward compatibility and a smooth transition when you’re a company rolling out APIs?

Jeremy: From a small tactical level when it comes to backwards compatibility, and this could probably be an entire talk on its own, how to make sure you actually have backwards compatibility. I would say if you’re removing anything from either the input or the output, that could break a call. Obviously, from removing a function, that’s going to break things. If you’re changing the name of a function, that’s going to break things. If you’re changing the inputs, the name of the inputs, or changing the name of the outputs, it’s going to break something in the API.

If you’re adding to an API, adding a new endpoint, it’s probably fine. If you’re adding a new optional input parameter, fine. If developers were already using that API, they don’t have to use that input. If you’re adding something new to the output but not changing the structure of the output, that’s probably fine as well. You’re not likely to be breaking anything. There are some caveats for adding output, though, but let’s not get into that here.

It’s when you are fundamentally changing something to an API, warning, there may be a backwards compatibility break. Sometimes you do have to do that. There are different ways of approaching it. If it’s a security issue, I say they can justify doing more of a hard “we need to break this thing immediately.” When that happens, I also check to see how many developers are using it. If it’s just an input to an endpoint, something niche, maybe a smaller number of developers. You might be able to just reach out to them directly and say, “Hey, are you okay just making a change in the next 14 to 30 days?”

If it’s not a security thing and it is a popular API, I am a big advocate of sunsetting, of deprecating APIs. So that, you basically say, “We have a new API endpoint. All existing developers, basically your API keys were created before a certain date. You’re allowed to use this API, it’s going to stay in our documentation with the disclaimer that it’s deprecated, and any new developer who comes on board and creates a new application. You have to use the new endpoints, you’re not allowed to use the deprecated endpoints. They were deprecated as of a certain date, that means it’s only accessible to applications that were created prior to that date.”

I also give the disclaimer, especially when it comes to B2B APIs, if you want to create a new version of an API entirely, go from a V1 to a V2, not just changing an endpoint here or there. Assume that you will need to maintain the old API for at least three years. I’ve seen companies attempt it in one year. Sometimes they are, but not in a world of B2B software, it always takes three years.

Learn More About Moesif Automatically Notify Customers When Endpoints Change 14 day free trial. No credit card required. Learn More

Webshooks Websockets and APIs

Webhooks are calls to an endpoint when an event happens. Websockets are streams of information for events with lots of activity. Both are more efficient that constantly polling APIs to see if events happened.

Kunal: Interesting. Let’s get a bit technical now. When it comes to APIs, what are Webhooks and Websockets?

Jeremy: I do encourage people, when building APIs and designing APIs, to think outside the box. I’m a big fan of embedded integrations, I may be writing some stuff soon on that topic, as to how you can enable third parties to safely customize your interface. Another area of key importance is to consider webhooks and websockets. These are basically real-time notifications to your apps.

The way I like to explain, if I’m ever asked in an interview, “How do you explain web sockets to a 5-year-old?” Well, maybe not to a 5-year-old, but have you ever been on a phone call, where you’re calling Southwest Airlines. I love Southwest, they’re the best customer service of any airline. They were the first to do this. You call them up and no agent is available at this time, so you’re going to have to go on hold. Now besides the fact that Southwest rarely has a 60-minute hold time, for them it’s like 5 or 10 minutes, what they did differently from others is rather than make you wait and just listen to really annoying music for 10 to 15 minutes, they just said “Give us your phone number, and we will call you back.So, you don’t sit there listening, polling: Are they ready? Are they ready? Are they ready? Instead, Southwest will let you know when they’re ready. That’s a web hook. It’s a reverse API.

In Box’s case, we had certain integrations that needed to know when files were being uploaded into Box, and then act accordingly. How do they do that? One way is polling, which is basically constantly calling our API, probably our updates API, to see what events are happening in Box. “Was there an update in the last 10 seconds? No. Okay, well, let me call in 10 seconds, has there been an upload now?” It’s inefficient for you, it’s inefficient for your partners to have to do this. The webhook is instead where a partner has some server endpoint where they let you know when uploads happen. And they can say, “We’re trying to lock in, we want to enable a webhook for upload events in Box.” When an upload happens and you have an account, we make a call to their API letting them know that the upload happens.

Websockets, if you’re curious, it’s basically a stream. Depending on the type of events that we’re looking for, that may be more efficient than either polling or webhooks. Webhooks are more for when an occasional event occurs, we should let you know that that happened. Websockets can be that we know there’s going to be a lot of activity that we need to watch. So we’re going to be constantly listening. It’s also known as long-polling. It’s just a more efficient way of just keeping this constant stream of access for what’s happening.

Kunal: Like a chat interface or something.

Jeremy: Yeah.

Learn More About Moesif Product Management Insights With Moesif 14 day free trial. No credit card required. Learn More

API Tool Evolution from Soap to OpenAPI

APIs have come a long way since Soap, evolving from XML to JSON, and then, after a brief period dabbling with API Blueprint and RAML, consolidating around the OpenAPI schema.

Kunal: Got it. What are Swagger and API Blueprint? What other tools do you recommend for a company interested in building out their APIs and opening up their APIs to third-party developers?

Jeremy: I just realized, it’s actually been a while since I’ve been asked about API Blueprint, but we could go into a little bit of history of API definitions now. There’s been evolution of APIs. There used to be something called Soap, which was a very heavy API. Nobody likes using that anymore, but occasionally you see it in legacy enterprise software.

One nice thing about Soap though, is that they had something called a WSDL, which was the schema defining the APIs. You can use that to auto generate a library of code to interact with that API. We moved towards REST, where everything was simpler. Things were a little disorganized.

There was something called a WADL, which nobody used. It was a way of trying to define REST APIs similar to WSDL and Soap. It didn’t really fly well. As APIs also evolved from XML to JSON, which was far more efficient and loved, it just overtook XML very quickly a few years ago. What also came about was Swagger.

We tried one more time, as REST APIS which were flexible were still coming back to RESTful API design, a sort of consistent structure design, and Swagger was the schema to design those — RESTful format with JSON. There were also competitors to Swagger: API Blueprint and Mulesoft had something called RAML. There was a time when I used API Blueprint over Swagger. I always thought Swagger really was the best, but at times, API Blueprint had, through some community developer, a way of creating really good API documentation automatically.

But at this point, all of this actually merged into the OpenAPI specification. It was basically the next generation Swagger, but they called it OpenAPI, so it’s really the new standard. In the past you might have heard people refer to RAML, API Blueprint, or Swagger, but It’s all basically consolidated with everyone agreeing on OpenAPI as being the official standard. Within that, there are other tools you can use alongside OpenAPI. There are many tools that generate documentation. That allows you to do what Stripe did years ago — that three-column documentation. Google what I’m talking about, “three column API documentation.” Once you have that OpenAPI specification, it’s really easy to generate that.

I’ve seen a lot of different tools on top of that. APIMatic specializes in building API SDKs off of that documentation. There are tools like Apiary and Postman that are there to help to create the OpenAPI specification. If we go to other tools over time, like Kong, they’re building out their own developer portal framework.

A lot of these tools allow you to just import an OpenAPI specification and auto-generate documentation, and other features off of it. I haven’t actually looked at the latest that Kong has for that framework. Last I checked, Kong was a work in progress. I anticipate over time this framework will build your own developer portals, to be able to just utilize the OpenAPI specification, to just auto-manage all of these aspects for the core product to make a successful developer program.

Learn More About Moesif Drive TTFHW With Moesif 14 day free trial. No credit card required. Learn More

When to Open APIs to Other Developers

Kunal: Thanks for that insight. I’m not sure if we’ve addressed this question already, but at what stage should a company consider building and open up its APIs to third-party developers?

Jeremy: We did talk about it a little bit. My emphasis here is to do it when you clearly have a use case and you can see that there is demand. Either you feel that you can reach out to developers who can bring you customers, or you see the customers have a need that you’re not able to solve yourself, and then it starts to make sense to build out those APIs.

For different companies, this happens at different stages. For Box, it made sense very early on. I’ve also worked with unicorn companies, where even at a billion, even at 10 billion, it didn’t make sense. Some of the companies that I’ve consulted for, they just crossed the billion dollar mark. They just started looking into it, and maybe they were a little bit late to the game, but not that late. That was okay, they had more confidence that we can look at what customers need and say, “Yeah, you’re definitely at a point now where if you build APIs based on the needs of the customers that you have now, maybe it was an S&V Solution that transitioned to Enterprise, and it made more sense at the Enterprise. Now it starts to make sense to actually build and launch these.” Don’t just go in and start building APIs because you think they’re cool.

Biggest Challenges for PMs

Kunal: Jeremy, let’s dive into your background a little bit more and talk about advice you have to give other PMs. When you’re starting with a new product role and you’ve done this a few times now, what have you found with them to be the most challenging, and how have you gotten them past that challenge?

Jeremy: PMs need to communicate effectively very well, not just to drive their own vision, to get feedback from the right people. Every company I’ve seen has different processes, but more importantly different cultures. It’s important early on to get to know as many people as possible. I’ve encouraged at times where I’ve had interviews to be interviewed by more people before they actually give me the offer. I want to make sure that those people know me, that I know them, and that we think we’re going to have a good rapport.

For engineers, the different kinds of engineering personalities. When I was at TradeShift, I worked with engineers in San Francisco, Denmark, and China. Denmark was very direct, they don’t sugarcoat. San Francisco is kind of sugarcoating. China, in Chinese culture, they sugarcoat much more than in the United States. Very indirect form of communication, and you have to be aware of that. You also have to be aware there are certain engineers that are just not a fan of product managers. Which engineers are going to be more upfront with you about their concerns, which are going to be uncomfortable and be good troopers but not share when they’re uncomfortable? Which ones are really going to pull some shenanigans because they don’t want to work with a PM?

You also have to make sure you have really good lines of communication with sales. If you’re in B2B, you’re with customer success, with those people who are going to be getting you the feedback from customers. A little secret I’ve learned, when you’re at companies of a few hundred, there are certain people in sales, certain people in customer success, who are better at consolidating that feedback and sharing it with you. It’s not necessarily in a managerial position. There are just certain people who are just happier to talk with other teams, and you have to know who those people are. They’re going to be your better source of communication in keeping up with what’s going on.

Learn More About Moesif Excel At Customer Success With Moesif 14 day free trial. No credit card required. Learn More

What Makes a Great PM

Kunal: Yeah, I’ve seen that, too. That makes a lot of sense. You kind of touched on this already, but in your opinion, what makes a great product manager? Obviously, communication’s a key part of it, but what qualities do they share, and are they common across these different companies you’ve worked at?

Jeremy: Yeah, we’ve talked about the customer empathy and the growth mindsets aspect, I think we can dive in more here. I do say that you no longer need the engineer-MBA combo. It does help because it is good to have business skills and technical skills, but there’s a lot more to it.

I break product management skills into two areas. There is the growth mindset, and customer empathy. I emphasize, whatever background you’re from, you have to have that. You have to have both of those, you have to be great at both of those. Next are practical skills. I say there are a handful of things that all PMs have to get good at, and then one or two things among those skills you have to just be great at. That goes to design skills, technical skills, communication skills, and business sense. You have to have a minimum, be able to communicate reasonably well, have enough technical knowledge so you’ll be able to talk with engineers, have enough design sense to be able to work with a design team. And then, you have to be great at one of them.

This is why, as we’re building out product teams, we know it’s important to diversify backgrounds. We now have people from a diverse set of backgrounds and education, because it helps to have someone who specialize in the front end. A former designer who not only knows how to work with design, but really understands the latest learnings and usability in designing a good onboarding interface, designing the front end overall.

Those who were working on APIs and developer-facing tools, it’s nice to have someone who has an engineering background, or a computer science background, so that they not only know how to work with engineers, but they really understand how to design things that are more technical, occasionally code, and prototype things. That’s where you start to diversify the team. Maybe have those who are more experienced in administrative tools or pricing decisions, those can be more of the enterprise PMs, ones that have the MBA or business background. You have to be good at all of those, but then you have to have your specialty, the superpower some say, which is just to be great in one of those pillars.

Learn More About Moesif Get Actionable Insights With Moesif 14 day free trial. No credit card required. Learn More

How to Achieve 10x Results

Kunal: Makes a lot of sense. Jeremy, what advice do you have to give other product managers and groups of professionals that want to achieve those 10x results that we all want? How can one be super successful as a product manager, especially in platform product management?

Jeremy: There was a professor of mine in B-School, Robert Kelly, who wrote this book, or he co-authored this book, “Developing Star Performers.” He taught a lot of secrets that go well with growth mindset, about what star performers are, but also where do they come within a career. People don’t start as star performers. You usually are not going to do that well at your first job.

I would say if you have growth mindset, you’re going to be in the position to fail a few times and learn. But what happens, is that at some point a few years into people’s careers, they’re growing and growing, and then suddenly those are the stars. Most people don’t ever hit that point. What happened was that they had learned certain things, they figured certain things out, how to work more efficiently, how to be more productive, how to communicate more effectively, to execute well.

We talked about a lot of these things, like the need for communication, some things tactically to watch out for. What I say to get there, is 1) have growth mindsets, have empathy, drop ego, learn how to learn faster. In its simplicity about developing star performers, the PMs that I know have had a good career over 10-15 years, who moved up- they all learned how to learn faster.

When I came into product management, there wasn’t that much information out there as to what a PM actually was. Over the years, as I saw from training people who weren’t engineer MBAs what it really took, and saw the community sharing blogs and newsletters on Slack, what a good product manager was. Conferences forming, Product School and other boot camps and training courses forming.

Now, we finally have all that information that we didn’t have before, and consequently people have to learn it the hard way. They had to learn how to learn faster, especially as technology improves. That I find is really vital, that goes with growth mindsets. I lost my trail of thought, there’s one other thing that I really wanted to emphasize, tactically, to actually get there. So, the big areas are just to constantly learn, keep up on the boot camps, the blogs, the podcasts. Just keep trying to learn, because there’s a lot more that’s coming out from the community that’s going to be helpful.

Learn More About Moesif Track How Your APIs Are Doing With Moesif 14 day free trial. No credit card required. Learn More

What to Read

As a budding product manager keep up on the lastest in Product Manager Interview questions from Lewis Lin, and Useability/Gamification techniques for successful products by Nir Eyal.

Kunal: Jeremy, what are you currently reading, and what book, or article, or blog posts have you read recently that blew you away?

Jeremy: Most recently, I’m reading the latest on Interview Practice for Product Managers by Lewis Lin. I’ve been in the field for a while, and interviews have evolved quite a bit. Years ago, we used to ask estimation questions, “How many golf balls fit in an airplane?”, and we’ve moved more and more towards behavioral interviews. And I’ve determined in my own experience of 11 years, how I need more practice, actually. It’s been very helpful both in those cases, to prepare for future interviews, but also to get a better understanding of product sense.

Other than that, I am keeping up on the podcasts, the blogs, and newsletters. Product Manager HQ, I find, is very helpful. I continue to read from design experts, there’s been quite an evolution in customer onboarding, in particular. That’s what I’ve been following.

Basically, years ago when iOS first launched. There was a big push to make registration flows as simple as possible because you don’t want drop-off during registration. But then, we would see you get a lot of users registered, you have to look at the rest of the pipeline. Users can register, you need them to be active and come back and become active users. There’s a lot of experimentation and newer and newer studies coming out from usability experts. They try different things to see what is effective in creating a healthier onboarding flow. Another book I can recommend, Nir Eyal, I think he wrote something new after the book, Hooked. That’s one I highly recommend.

Kunal: Indestructible.

Jeremy: Yeah, because what we’re seeing from Hooked, which was just a great source of experience, and a great source of knowledge in user experience. Back in the day of gamification, I remember. People thought we should make everything like a game, and Nir Eyal finally came out and explained, “No, it’s not about making everything like a game, it’s about taking usability learnings of the gaming industry.”

He knew himself, habit creation can be a good thing; it can be very dangerous, and he saw that it has been abused. I know he’s writing some new things about how to really create habits and not addiction. He’s really emphatic about it. I am emphatic about it, as an empathetic developer.

There are books coming out, there’s still the content from the community, the articles, the blogs, and the podcasts, and there’s also curriculum content. I’ve been teaching at Product School. I think it’s a great boot camp. I’ve also been in touch with Carnegie Mellon University. As part of their MBA program now, they have an addition to the MBA, a Masters in Product Management program. They’re experimenting with it, but it’s an interesting take on potentially creating a major. I know that Stanford has also a course, just on product management.

In the world of boot camps, the world of academia now, there are many options to learn more about product management. I certainly encourage everyone to truly take a look at those. There’s a lot of opportunity there to find a style of teaching that suits your needs.

Kunal: Great, thank you so much Jeremy. It’s been a pleasure having you. Where can people find you?

Jeremy: You can find me either on LinkedIn, or feel free to check out my consultancy, it’s APIStrategist.com.

Kunal: Awesome. Well, thank you again, Jeremy. It’s been a pleasure talking to you.

Jeremy: Thanks, it was great talking with you, as well.

Kunal: Awesome.

Learn More About Moesif Make Your API Platform Successful With Moesif 14 day free trial. No credit card required. Learn More

,

Larry Ebringer

Larry Ebringer

Head of Marketing at Moesif. Previously, founded fortesque and CMO at InSpeed Networks

Related Articles

Announcing

API Strategy

Announcing General Availability of the Moesif Developer Portal

We’re thrilled to announce the General Availability of the Moesif Developer Portal, a major leap forward enabling you to deploy a seamless experience for dev...

Introducing

API Analytics and Monitoring

Introducing AI Explain

We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...

Monitoring

API Analytics and Monitoring

Monitoring Cost and Consumption of AI APIs and Apps

Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.

Unlock

API Development

Unlock Deep API Insights with Moesif’s HTTP Body Analytics

Learn how to use Moesif to analyze HTTP bodies.