Sri Kandikonda, Fedex

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 topics from the world of APIs, but we look at things through the lens of business and engineering leadership. Joining me today, we have Sri Kandikonda. I found Sri’s view of treating APIs as a product to be pragmatic and informative, and it really got me thinking about the role that self-service is playing across our internal as well as our external APIs. All right, I always start with the basics. Who are you and what do you do?

Well, first things first, thanks for inviting me on this podcast. What do I do? I’ve been in tech for the last decade, made a career in tech and creating technical products, if you will, and the majority of my last five to six years is really working on scaling B2B products and B2B technology products at that, ranging from machine learning to platform products in our API portfolio and strategy at FedEx. So I made my career creating tech products and working with some of the really brilliant developers, both with them as well as creating products for them.

Nice. So explain to me, what is the difference between a product and the classic IT projects, technical infrastructure that we deliver historically?

Now, really understanding what is it solving, what problem or value is it providing to the customer, and understanding the customer on a deeper level, and being able to package your value proposition to your customers, and hopefully being able to scale to hundreds and thousands of customers with the way you architect and design that product. And I think that really differentiates between a product and a project. A project has a set timeline, it’s done when it’s done, it’s an implementation at best. A product is, it’s just like a baby, it needs to be nurtured, it needs to grow, and it needs to solve real-world problems for our customers, so it needs to be carefully managed and maintained over a period of time so that it can essentially solve customer problems at scale.

Yeah, good description. So what’s the feedback and alignment loop kind of with this look like, so alignment keeping in alignment with business but the feedback loop with customers? How do you find balance with that?

Well, it all starts with a customer, and I think at the core of it every product manager, any product person for that matter, has to be a customer advocate in terms of what customer problems they’re resolving and why, and then tying it to our business strategy in terms of what does it mean for our business, and then finding synergies between the two. At the end of the day, you don’t want to create products that don’t create revenue or achieve your business vision, so you want to find a balance between solving customer problems and then being able to monetize your products if that’s your goal. So I think, again, it starts with the customer in the middle of it, customer centricity if you will, understanding their problems and pain points at a deeper level, and then tying it to the business strategy to understand, okay, what can we bring to the table, what value proposition can we enable these customers, and how can we differentiate ourselves against our competitors and in the marketplace, so that we can effectively solve our customer problems at the core of it. To achieve our business results and potential, if it’s making revenue or bottom line, then how can we achieve those OKRs set for ourselves from a company perspective, and number three, how can we differentiate ourselves and market ourselves in the marketplace for a longer-term and sustainable business and product growth. And I think the combination of these three things is what I would really strive for, and I think best companies and best products really do these three things very, very well.

So what’s your toolbox of metrics that you need to get what you need to find this balance and meet those OKRs?

Say that again, can you add a little bit more detail on that question if you will?

Yeah, so like, what do you need to measure, what’s the important things that you need to measure to know that you’re being successful?

Yeah, and it starts with the why. I like how Simon Sinek puts it, everything starts with a why. First thing is understanding what is the objective of the product or the portfolio of products. If it is to create new business opportunity or new revenue streams, then of course revenue becomes the KPI that you strive for. On the other hand, if the intent is to create a new business model, for example with APIs, creating a third-party developer ecosystem where you enhance your offerings with the help of the third-party value-added resellers, then the metrics are different in terms of market reach would be an example. I think a good example to go by is, if you think of Facebook API, login with Facebook, the product itself doesn’t generate any revenue, but if you think about it, the proliferation of login with Facebook on every platform globally, being ubiquitous, is their vision, or that was their OKR. So in terms of creating metrics, you really need to understand the business vision and the customer need, and in this particular case it’s market reach, not necessarily revenue, but it is more in terms of being ubiquitous in the marketplace. So it really depends on the vision and the strategy of the business, and then of course tying it to the company, tying it to customer objectives as well.

Yeah, so how do you, as you talked about developer ecosystems, is self-service a quality of this that you feel is essential as far as these products that you’re putting out there, or should customers be able to just come and use them and choose how they use them as they wish, or is there more hand-holding and engagement required?

Well, self-service is essential. Really understanding the customer needs is more essential. And then there are three aspects to a developer ecosystem which I believe is very critical. Number one is, how do we create a self-service developer experience in case of understanding and discovering the products, and being able to integrate with the products, and maintaining the products for the reliability of their systems. And then being able to secure these products from a company perspective. While APIs provide a lot of scale, they’re also major points of attack, so from a company perspective and a product growth perspective it’s important to take care of security as well. And then the third aspect of it is, once you create this self-service ecosystem for developers to come in and consume the APIs and the products that they would like to consume to inspire their vision of creating a software product, the last piece is how do you scale it. And self-service in my mind is the only way to achieve these objectives. If you include any aspect of hand-holding, some don’t require hand-holding, but if you do not minimize the aspect of hand-holding, it is not feasible to scale your product to hundreds and thousands of users, but of course millions of transactions a day. So self-service becomes essential in scaling your product, and self-service becomes essential in reducing the cost to serve, and self-service becomes essential for developers especially. I’ve worked with developers all my life, and one thing I know most certainly about developers, they want to figure it out themselves. Our job is to empower them with tools and services that they can achieve their vision. In fact, sometimes our goal is to get out of their way so that they can get their job done, and self-service is a mechanism to do that.

Yeah, and it feels like if we’re not being self-service we’re kind of being lazy and we’re not doing all the work that needs to happen in there. And I feel like the companies I talk to that are waking up to this are realizing, like, here’s kind of the narrative that I’ve been hearing play out: we at large enterprises, mainstream organizations, 2015 we started realizing we’ve got to get our strategy together with this API, but efforts were still very IT-led, the APIs we produced were still very much a project, they were technical groups, we had a few things built on them, had a couple hackathons, but nothing, no real business value came out of it. And now that we’ve started bringing in more product managers and more specialized API product managers, we’re starting to see a shift, we’re starting to see that alignment we talked about and the feedback loop. So where do these product managers need to come from, this next generation of API product managers? Do you feel they’re more from technical backgrounds or more from business backgrounds? Is it a blend? What’s the sweet spot for API product managers, would you say?

I mean, I love the question. In my previous life I was an API product manager, now I manage the product strategy. But that’s a great question. In terms of understanding the value of APIs, I strongly believe businesses are sitting on millions of dollars of untapped potential in understanding what API products they can offer and then how can they monetize and how can they provide new business models with these APIs. And the missing ingredient really is that product mindset. And of course a product mindset comes from a strong product management discipline, and I’d like to think most companies, digital and technical companies, have a strong product management discipline. And if we can apply that to API product management, a couple of things stand out. APIs are technical, that means a product manager has to understand at a minimum the customer experience and the consumption aspect of API products, so that they can empathize with the developers, because developers are our customers, we have to understand what they’re going through, we have to understand what their pain points are. If they say that, hey, you have encoded these values which I don’t expect, then a product manager should be able to empathize and understand the pain point and then try to understand how to solve it. So at a minimum it’s important for the product managers to empathize with developers, which means a technical skill set, a basic level of technical skill set, is extremely important. On the other hand, you also have to tie these to business objectives and the product management discipline, which means how can I market my product and how do I create a key value proposition that might stand out from my competitors, or set a price point where it is appropriate for our customers to pay and achieve their business outcomes. And these are all the things a product manager has to tie together. So essentially an API product manager has to be technical enough to empathize with the users, in this case developers, and business savvy enough to then understand how can I take these products I’m building and then achieve my business outcomes, my OKRs. Again, it could be revenue, driving revenue, it could be creating new platform for internal customers, or it could be creating new business models with third-party developer programs. So I think it’s essential for an API product manager to be technical and business savvy, and I guess that’s really why it becomes really difficult for companies to get this sort of skill set. I can go on and on about this, but I do think the best possible scenario is to take the existing technical product managers and technical product management discipline within companies and augment it with education and empowerment with API skill sets and API knowledge, so that they, the existing product managers, cannot just talk about their SaaS products, whether it’s web application, mobile application, they can also take their APIs and say, hey, how can I package this API product and serve to my customers, how can I create new revenue streams from existing API products and APIs. So the why and the what really becomes important for an API product manager, and how is more of a negotiation with your technical and engineering teams, and when is of course a matter of understanding the marketplace reactions as well as your business objectives.

Yeah, I’m getting a lot of requests from enterprise organizations, large ones, where’s the, can you provide us with curriculum, because they want to upskill their existing folks, but they’re still concerned about the overall, they’re going to need a lot of these folks as things grow here. Do you feel like this is something that’s going mainstream enough that universities, because product management’s a pretty established discipline, do you think universities should be following up with some curriculum that’s specialized towards APIs?

Absolutely. I think everywhere, anywhere there is SaaS product management or technical product management involved, APIs or API product management becomes a core aspect of it. The internet is run by APIs. Whole companies are being run by API products, Twilio for example, and Stripe for example, and that’s the new breed of companies that we’re dealing with. And most companies today are API first, so it is not a technical imperative anymore, it is a business imperative. And I could vouch for at least our company that our executives are very well aware of what value API products can bring, and understand enough that they can make decisions on APIs as, or treating APIs as, first-class digital products. And that discipline, to get to that point it requires a lot of education, a lot of empowerment, in terms of taking internal resources and then equipping them with education and tools necessary to build these API products. So yes, the short answer is yes, and I can see that the next three to five years most corporations will invest heavily in educating the product management teams on APIs. And I cannot imagine any team now not talking about APIs. I think it’s a daily thing now, however non-technical you are, I’m sure you’ve talked about APIs, heard about APIs, your developers ranting about APIs all the time, it is all over the place, APIs are all over the place. So I do expect the likes of Kellogg and the big Ivy League institutions also rolling out some of the API product management courses and discipline. I mean, we’re already seeing it, it’s a matter of time.

Yeah, I love the way that you talked about it, APIs being everywhere. I remember leaving SAP, I was running North American events for SAP in 2010 when I started this API journey, and I remember just how everyone, all my coworkers and colleagues, thought I was crazy for dedicating my career to APIs. They’re like, what are you doing, man, this is so weird, why would you do that? I’m like, APIs are everywhere, you don’t understand. And they’re like, okay, all right, whatever.

I mean, it’s not an exaggeration to say the internet is run by APIs, and we live in an interconnected world. The phones that we deal with and the TVs that we connect with and the cars that we drive, they’re all now morphed into more technology-driven digital assets, we interact with them on a daily basis. So APIs power all of these experiences behind the scenes. The only reason I can switch from my web application to mobile to then my, in the future, cars or a Tesla, is all powered by APIs. I cannot imagine a world that’s more seamless and an interconnected experience without having APIs run the internet as it is doing today.

I had, great, preaching to the choir here. You mentioned API first. For our audience, what does it mean to be API first?

API first is understanding the value of APIs and treating APIs as first-class digital products. Just how we talk about mobile experience being the most important for our consumers, and then understanding API first, or educating our internal developers to think of APIs not just as integration methods but APIs as a first option to be able to develop and drive interactions between different applications. So that starts from understanding that APIs become the core of running our technology architecture and the microservices architecture, and then being able to teach our teams in terms of, hey, when you think about creating an API, don’t just create something for the sake of it, understand the strategic intent behind it, how does an API play with the other APIs, how can we take an internal API and then externalize it so that we can create new revenue streams for our customers or improve their business outcomes. So really thinking of APIs as first-class products and really thinking of APIs as first choice to be able to build and consume different services and applications within our organization. I think that’s the core tenet of API first. I think most companies are getting there in terms of, hey, we have some APIs and for internal developers we have some APIs, we expose some to customers. I do think the missing ingredient, or the next level of maturity, is now turning these APIs and understanding how can I turn this API and package that into an API product so that it’s self-sustainable and scalable.

So does that, I think a lot of folks stumble on kind of where they’re at in their journey, and they hear product and they hear revenue and they think only external, we only do this with externally facing APIs. So does everything you talk about apply to just internal APIs as well, microservices? Should we be thinking about these as APIs as a product as well?

Yeah, I think so. Not every API is a contender to be a product. There are certain cases where we build APIs just for the sake of integration, it could be one-off integrations, but at the core of it it’s human-centered design, for internal, whether that’s internal consumers or external customers. Who are my consumers or customers in this case? If it’s an internal developer trying to build, let’s take an example, trying to build a shopping cart experience on an e-commerce store and he needs his address verification service, really need to understand what the needs are from the consumption standpoint and how our API plays along with the rest of his or her ecosystem of software or application, and then build it to the needs of the customer and really trying to productize it so that you don’t have to hand-hold each and every customer or consumer, because we’re not building to the order of this particular one-off customer or developer, we’re really building a product that can scale and satisfy the needs of a core segment of developers internally. So it applies as much to internal customers, in this case developers and application teams internally, as to external customers. The revenue and creating new business models is an aspect that is applied to the external world or external consumption of it, but when it comes to internal consumption the goals may be different. It could be speed to market, it could be empowering our developers to be more productive in terms of how quickly can they integrate and how securely can they integrate, and empowering them with tools and platforms so that they can minimize some of the tasks that they have to do to get to their end goal. So it is applicable both to internal consumption as well as external consumption.

And self-service is huge for internal, reducing dependencies on teams, value exchange between teams, there’s a lot of parallels there.

Absolutely, and I think we have to go back to the Bezos mandate. I’m not sure if Bezos had said this himself or someone made it up, but the fact being, the mandate saying that each internal team will only communicate with the other application teams via these interfaces, API interfaces. It cuts down costs dramatically, and self-service, I mean, is the way to go. It’s not just cost to serve, it’s also the ease of access and discovering products, ease of identifying what products I need to use, or APIs I need to use, for my application, and not relying on certain teams or hand-holding to get there. Self-service has a lot of benefits. I love self-service in the fact that, again, as a developer and working with developers, I know for a fact that they will figure it out as long as we give them the right tools, right services, and the right platform and ecosystem.

Yeah, and not all APIs are created equal, but I think there’s a certain journey that all APIs need to go on that reflect this externally facing. There’s a maturity involved. So what would you say feeds into maturity around APIs that would dictate wider usage, wider consumption? Like, what are the characteristics of a mature API?

I think there are three things when it comes to designing API maturity. Self-service is at the center of it, understanding really from a customer needs. And self-service does not happen without deep understanding of who our customers are, what their problems are, and what value proposition the API provides. That in itself is the API productization that translates into self-service. And then building on top of it, how can we make it easy for developers to self-guide themselves in understanding the product, understand the features and capabilities, how can they integrate, inspiring them to really understand what can they do with it. Can I build an AR application with it, or can I build a VR application with it? So inspiring them and educating them is paramount in the self-service space. But the second aspect of it is really creating a structure or systematic process within the organization for how could you secure these APIs. So security becomes paramount as well. And the third part of it is scalability and reliability. When we talk about APIs, the reason they shine is because APIs are all about scale. Twitter for example has about 13 billion API calls a day, and if we cannot scale our APIs to a level where that is needed, to that volume of transactions, it’s not going to work. So it’s important to build infrastructure and architecture to be able to scale to the level of need from our customer consumption standpoint. So security, scalability becomes paramount. And the last part is reliability. I know I say the last part, but this is perhaps the most important success metric for any API regardless of the context. How reliable is your API? Can I trust your API to get my job done? Can I trust your API to be up? And typical SLAs is 99.99, which is to say that I expect your API to just work 100 percent of the time, and that’s the expectation. And of course speed also becomes paramount. So these three factors. You think about creating a self-service ecosystem for customers to integrate and developers to integrate easily and maintain easily, second is creating secure APIs, and the third is of course how can we create scalability and reliability into this ecosystem.

So you guys found something that I think is a really interesting sweet spot. I encounter a lot of companies are really nervous about putting their APIs publicly for security purposes. But what you described, and kind of the product management base that you described, is, if you know your customers, target customers, you have a plan in place, you’ve designed that API to meet that need, and that’s intentional, and then you’ve properly secured those APIs, like, this is, it’s a good thing. But it’s the companies who don’t have a plan, don’t have a strategy, and just put APIs out there with a build-it-they-will-come mentality, that are fearful of this.

Absolutely. And I think the analogy is, it’s almost like the first level of maturity I see in some companies is, hey, we have some internal APIs, let’s see who we can sell to and what we can sell for. It’s almost like trying to find a problem to an existing solution, and that’s a classic mistake of any product management discipline. Really it comes down to what the customer needs are and understanding who our customers are. Not all are the same, and you cannot bucket all of them into one segment, which means deeply understanding different customer segments, their pain points and needs, becomes paramount to creating these API products. So it’s an outside-in perspective. It’s not about saying, hey, we have some API services, let’s see how we can sell it, it’s the reverse. It takes a lot of discipline, impact, and time and resources to understand who are our customers, what are their needs, and what do we bring to the value, what is our unique value proposition or key value proposition, and then think about marketing your API product in terms of, what marketplace do we want to play in, what’s a price point if the intent is to sell it, or what is our business outcome that we’re looking for, is it ubiquity, is it creating new revenue streams, or is it creating new business models and things of that nature. So there’s a lot of factors that play, but at the core of it it’s still human-centered design. We’re designing these API products which are essentially software building blocks for developers so that they can build software.

Do you feel like one of the deficiencies of the space up until now, until recently, has been REST APIs have dominated the conversation, and rightfully so? I think HTTP or web APIs are ubiquitous, cheap infrastructure, and simple, but REST in the terms of resources and defining your resources kind of has dominated, and it feels like when we have these simple CRUD resources and we have feedback loops with consumers, no one cares about my book API or my raw resource, I have to actually create experiences with those APIs, I have to actually go the next step. And do you feel like that’s where we’re finally at in all of this, is we’re able to create actual experiences that matter to users, that’s why we’re starting to see more velocity?

Exactly. And I think we’ve come to a realization that APIs by themselves do not do anything, they’re enablers, they’re enablers for developers, whether that’s internal or external, to meet their business, to create digital experiences with these software building blocks. So APIs are software building blocks, and now the question is, what does it enable my customer to do, what vision can they achieve with my API product, can it help them grow their business, can it help them go to market faster. Let’s take an example. If Uber were to build all the maps infrastructure internally without using Google Maps API, it would have taken years to go to market. So the only reason we were able to be faster in terms of going to market and nimble and being able to identify third-party APIs is because of the API ecosystem that’s built today, that wasn’t in existence 10 years ago. It’s starting to proliferate now. Companies are starting to understand it’s important to create an open API ecosystem for all of us, all of our companies and products, to build experiences faster and build experiences in a better fashion for our end customers and experiences.

So you’re saying the resource, which in that case is Maps or Twilio SMS, that really isn’t the API economy or the ecosystem, it’s the fact that we got Uber and GrubHub and DoorDash and all those things on top of SMS and Maps, that’s actually the API economy, not the individual resources themselves.

Exactly. APIs power the digital economy, I’d like to put it. So APIs by themselves are enabling this digital economy that we are seeing today. But if I just have an API without it letting me create an experience or build an application faster or nimbler, it doesn’t serve the purpose. So they have to enable my developer, whether internally or externally, to create that end digital experience, which we really are calling it the digital economy. But APIs power the digital economy, as I would call it. It’s all a mismatch of different API products from different third-party providers to create that end infrastructure or application. It’s no different than thinking of APIs as building blocks, in that it’s like Legos. Now, our job as API providers is to understand how do we design our API or the building block so that it fits well within our customers’ or developers’ ecosystem and other APIs, so that they can achieve their vision of building their product. So it’s all about the customer, it’s all about them, we are more or less enablers for them to succeed, whether that’s an internal developer or an external developer.

I love the Lego analogy, because the blocks feel like the resources, but really what’s getting people, the trainings, the Millennium Falcon, the Star Wars product sets, the space ones, the train ones, the ones that actually get people emotionally connected. And there’s a bunch of us who love a big bin of just bricks, but that’s a finite audience, right? To really reach the world you got to have the emotional connection of the product.

Exactly, and that’s a great point you made. I think there’s always good products and great products. A good product gets the job done for the customer, and in my mind a great product inspires our customers to achieve their vision or do something that they have not imagined or have not thought possible before. And I’d like to think Legos and the concept of API products in that fashion. It has to not just get the job done for the customer, but it has to inspire them to think of more capabilities or new business models or new experiences they can develop with the help of these API products. I have a great example in this regard. In fact, we were working with one of the developers, and all we gave was a simple, let’s say, tracking a package API, and the developer went on to build an augmented reality application to show the package movement on an AR view. Who would have thought that was possible? So it really is helping the end customer and developers achieving their vision, and APIs are enablers to get there. But for us as API product management folks and API product people, we really need to understand what our developer is trying to do and help them get there. That’s all there is.

Nice. I have a similar one from that same slice. I was interviewing a blockchain API company and they said, we’re going to create gambling, one of the things we saw, some creators gambling off of FedEx packages whether it arrives on time or not, and we’re going to let people bid Bitcoin based upon that and actually create a gambling game.

Wow.

I was like, okay, interesting. So you’ve talked a lot about customer alignment, we mentioned business alignment, how do you keep this in line with business? There’s another alignment issue or challenge that I’m seeing with a lot of organizations, is consistency across an enterprise organization and the APIs that are putting out there. So you’ve got self-service, secure, and reliable, and there’s a lot of conversation around governance right now, but I’m seeing a lot of top-down governance fail, and the ones that I’m seeing succeed have kind of a bottom-up enablement aspect, we provide you with standards, we help you make the right, do the right thing in the right moment. So how do you achieve that balance across many teams, and since you’re in the strategy role, how do you help enable that?

I think you hit the nail on, and said, it’s not enough to have APIs, individual teams creating API products is a great first step, and now if you think about consistency and standardization, because at the end of the day your customers, your developers, expect your organization to deliver API products with a consistent experience when it comes to consumption, and also follow a cohesive strategy in terms of APIs playing along well within different organizations, they all have to complement each other not compete with each other, even in some cases that happens. Now, how do you do that? It’s easier said than done, especially for large enterprises with tens and hundreds of teams developing API products on a daily basis, it becomes even more difficult. In my mind, top-down approach is setting very strict and strong governance models in terms of intake of different or new API products, or being able to build and having a center of excellence team to guide, okay, what do we productize, what do we not, and an overarching governance structure to guide the whole end-to-end process. That, like you said, is great on paper, although rarely works because of the tighter control and less decoupling, if you will, it’s very tightly orchestrated process, and it’s easy, even if one of the pieces do not go well, the end result would not be consistent or efficient. So I think, to your point, when we talk about bottom-up approach, somewhere in between these two options, where you have an enterprise-wide top-down approach of governance and there is a bottom-up approach of product management teams and API teams understanding their customers and building APIs, a platform in the middle that empowers both of these capabilities, both of these sides, is essential. When we talk about a platform, once you have a structure in place with the right rules and processes, then it has to be self-service even for that API teams to understand, hey, what is a non-negotiable requirement or design standard that I need to follow. So it’s more of creating that base rules but giving the flexibility to the teams to be able to build the products. So you still have governance baked into this platform, but it’s not a handheld process, it’s more of a platform where the developers in this case can educate themselves on the standards that they need to follow, and product managers can identify the synergies between different products to be able to say, hey, what product am I offering and how does it play along with the business vision, and of course the right governance structures in terms of approving, if you will, API product capabilities. So I think it’s a trade-off between having a strong top-down model to then a bottom-up model, somewhere in between a platform would alleviate some of the concerns of, you have enough governance that’s not tightly coupled with the entire development process but sets the guidance and rules necessary to create this consistent and standardized API products across the enterprise. Again, all of this is easier said than done, and in my mind, especially for large enterprises, this is a multi-year effort in itself. And the difficulty I see in most enterprises is being able to justify the business value in investing in such a platform and what would it take to build that platform and how would it enable the company to be able to innovate faster.

Yeah, and that, I’ve seen design reviews get heavy-handed where they take weeks or months, and the security reviews similarly, and these become gates rather than enablement, they’re not self-service. Those rules aren’t self-service. There’s a lot of things that we apply to APIs that we should also apply to the API life cycle and governance as well, that we’re not doing that self-service nature, there’s a lot we can do that’s better.

Yep. I think, just to top it up really, the API life cycle management happens in pockets very, very well, individual teams do that very, very well. It really is building that transparency and structure and platform across organizations, taking it to the next level. And the only way I can think of is to democratize this platform enough that both the supply, the gatekeepers if you will, and security is a great place to start, gatekeepers have enough tools and controls to set necessary standards but not have complete control over what needs to be built, and on the developer side, the consumer side, again having certain controls on standards-based rules if you will, on the other hand having flexibility to be able to design the products to their customer needs. So it’s a trade-off between these two, but I think a platform, a well-created or well-curated platform, is a significant step in terms of managing API life cycle management across different organizations.

Amen. I don’t normally bring in Postman to this because I try to keep it outside of the conversations, but what I see most of our customers, because we have 20 million developers, they fit into three buckets. We have customers where there’s hundreds or thousands of individual users operating it on their own and they’re not doing a lot of sharing, and they might be sharing some Swaggers, OpenAPIs, a long way, but they’re not working together. Then there’s the next group who have started sharing, started collaborating, started design first, started doing more collaborative and poking holes across teams and seeing what teams are doing. And then there’s the ones that have approached the API first, where they’re planning in a centralized way, they have observability across teams, they’re sharing what the life cycle is, what does testing mean over here, what does testing mean over here, and it’s less about the API and it’s more about that collaboration and that observability across teams, like you said, that is what makes the difference.

Yep, and again I think I may have oversimplified some of these things. The beauty is in the execution in itself, and it really takes a strong discipline and a strategy to put together this structure. And I think it’s an iterative process at best. It’s going to take a multi-year effort to get to the end state of a very cohesive and flexible process at the same time, but I think the only way to get there is to iterate on each of the increments, if you will, and building the platform into play and then testing different things and seeing what works. And it’s not different than creating a product, it has a life cycle in itself.

Interesting. So when I ask people this question, what does the innovation look like for you, what’s next that excites you about APIs, I tend to get a mix of answers, some people go towards the technical, Kubernetes, service mesh, some people go more towards the business and products and services. Like, what’s innovation look like for you, what’s the next important thing that you want to be investing in?

Yeah, I mean, it’s a combination, to your point. A well-orchestrated vision in this case is really understanding the technical capabilities and innovations that are coming in, whether that’s Kubernetes or now even event-driven architectures are becoming commonplace, some of these capabilities, and trying to understand how to tie these to business vision or business outcomes, and then tie these to customer needs to then help our customers innovate or internal developers innovate faster. So I think it’s a combination of both, it’s really trying to understand the technical capabilities and then tying it to the business outcomes and the customer outcomes, that’s where innovation, I feel, is. But one thing I’m most excited about, or one thing that I see tremendous, untapped potential at best, is companies are sitting on a gold mine of APIs. What’s missing is that product mindset to be able to turn some of these APIs into API products, whether that is to create new business models or API businesses, lines of business for API products, or new revenue streams. And I think there is a huge untapped potential within each of the companies, and it takes a good product leadership team to identify it and own the skill set to then extract the value, to extract the gold out of that mine. I get too passionate about the subject, because it’s a lot of untapped potential, and I think the next three to five years I see most companies, both tech and non-tech, trying to understand, hey, how can we leverage our APIs and then innovate, whether that’s creating new digital experiences faster or creating new lines of business from API products.

Wow, I couldn’t have asked you to end the show better than that. I’m going to just, we’ll just put an end right on that moment there. Wow. Thank you for coming and sharing, this has been enlightening. I love your vision of things, I love your view of the landscape, it’s right at that perfect level for this audience, especially reaching business and technical stakeholders, so I appreciate you coming by and sharing with me today.

Hey, I had a great time today. This is a very passionate topic for me, and you, of course, so it’s great to share some of the things that I’m interested in and learn from you as well, so this is great. Thank you.

Same here. I’m glad, thanks for your time, and I’ve been looking forward to having this conversation with you. I appreciate you coming by.

Likewise, Kin, I’m sure we’ll meet another time, I’m looking forward to that.

All righty, thank you, bye.

Thanks again to Sri for stopping by. You can find more about them on LinkedIn. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.