API Evangelist Conversation with Dale McCrory, Software and Product Management Leader at Breeze Strategy

All right, hello, Kin Lane here, API Evangelist, here for another one of my API Evangelist conversations, where I just sit down with folks who are doing interesting things with APIs in the space. So let’s see who we got with us today. Hello there, who are you?

My name is Dale McCrory, and I’m an experienced product manager doing APIs in the enterprise and in the SaaS world for a long time, and currently have a consulting company that I started up as well, to kind of help others with their strategies and technology strategies. And so that’s kind of what I’ve been doing, doing this for over 20 years at this point I think.

Yeah, you’ve been in the space as long as I have. We used to talk quite a bit back in the day, and then we’ve kind of followed each other over the years, and you’re someone I trust that kind of gets the business aspect of this, not just from kind of enterprise leadership and enterprise product and business, but also startups, and you said you got your own consulting, so you kind of get the bigger picture of it. And let’s start with the basics. For your average enterprise business leader, why do APIs, why invest in APIs?

Yeah, it’s a great question. A lot of times in the — if we’re just talking about the enterprise space, before you get into like software as a service, that sort of thing, if you’re normal classical enterprise, a lot of your integrations historically have been going directly to databases. You might have developers who are used to doing it that way, and they built a lot of integrations to databases, and over time what happens is you lose those developers, but you’re also losing out on opportunities for business agility, so being able to actually use data in different places in a quicker way. And it’s an aspect of how many people need to know about change as well, so there’s a big change management aspect to APIs that’s probably one of the leading needs that you have as a business owner in the enterprise world, or business manager, is like, hey, how do I know that I didn’t make a change in system X that impacted system Y, especially when you get a number of teams working on a single problem. And you always get like, well, why didn’t this team tell me about the change over here? Do you know what, like, that’s a great question, we should have done that. Someone says, well, if we had a good, really nice API around here, we could have actually made a non-breaking change, you never would have even known that we made that, right. That’s a spot that a lot of enterprises are still in as their teams are trying to work together. Like, sticking to an API-first mentality limits risk, that’s a big deal.

Yeah. My previous incarnation of this podcast that I was doing when working at Postman, top two things I heard from the 150-plus people, enterprises, I talked to is, one, we need to govern our APIs, because we got so many APIs everywhere, but two, we need to hire product managers and/or train product managers to be more technical. So why does this business leadership need an API product manager? These things are just technical configurations, these APIs, right?

Yeah, I mean, they’re technical configurations, but they have a lifecycle, and that’s the key thing with APIs. The moment you introduce an API, so you solve the risk problem by introducing the API, so you got the risk problem solved, but now you’ve added this new thing that has a lifecycle, has multiple versions, you have to live with it forever. So even as, if your business needs change, this API needs to change in an orderly fashion and needs to be treated like a product that has versions, has a business problem that it’s solving, that eventually might get deprecated if it’s not solving the right business problem. And most classical product managers aren’t able to really get their head wrapped around that. And there is direct revenue implications for it, depending on the types of integrations you’re doing. An enterprise might be doing a strategic integration. So there’s a difference between a strategic integration and an ecosystem. A strategic integration is, I’m an enterprise corporation and I’m strategically going to integrate with one of my key suppliers, that actually requires a fair level of thought, it isn’t a UX problem, but it will be around forever, as your business evolves and your supplier’s business evolves you need to keep iterating those systems.

So you’re kind of alluding to — I think a lot of people think there’s kind of one type of API to rule them all here, that you’re going to just make APIs publicly available and you’re going to charge for access and you’re going to publish those to a single portal and everyone comes and builds. Is that not true? Is there other types of APIs that people should be thinking about?

That’s a great question, because typically the first thing a product manager gets hit with APIs is, just because their developers are building a single-page application, they need REST APIs to connect to React or something like that, so there’s a bunch of REST APIs that are built, they’re using authentication type JWT or some front-end mechanism, and then they’re like, oh, we’ve got APIs there. Someone’s like, okay, that’s great, it’s called an internal API by the way, that’s a private internal API, it’s not designed for public consumption. But then someone’s like, okay, we do need to do this strategic integration, like, well, can we take that one that we built for the UI over there to kind of use it for the strategic integration? The developers are like, no, really wasn’t designed for that. And then someone’s like, well, how do we actually repurpose — I mean, the functionality is there, the contract kind of exists, but the business process is really kludgy, you take like eight API calls over here, but we really need an API that does all that in like one API call. And then someone needs to think that through and design that. Is that an architect, a product manager gets in there and says, well, I understand what needs to be in there, what doesn’t. And that’s really what, at that particular stage, before we get to ecosystems and trying to build all sorts of other external public stuff, you’re looking at.

What about the business side, like, as a product manager, am I just charging access for all these APIs, or what’s my revenue model look like, do I capture that value?

Yeah, traditionally, an API is introduced for the strategic integration, which is the first step in a partner ecosystem. Strategics are your first step in a partner ecosystem, saying, all right, my business, my sales team, my executives say we need to actually have a technology relationship with this other vendor. Okay, well, the API product manager says, okay, I see the business value of that relationship with this set, or there are multiple, one or many vendors, and we’re going to build some APIs to make sure we can facilitate those integrations internally, and there’s a direct business value there, because now you have the sales and the marketing capacity. But when you get into enterprise sales and say, well, we have a lot of problems to solve and we know we can’t solve all these problems with just a couple strategic vendors, we would really want to enable any vendor to solve these problems on top of our platform — now you switch from an application play to a platform play, and now you’re talking about indirect revenue that your sales team is able to acquire, new deals, because they are able to talk about relationships and functionality that they weren’t able to do when you were just playing in more of an application space.

So this is more than technical, you gotta have domain experience and understand what’s going on with the business and customers, and really dial in your API design based upon that.

Yeah, because if your application or platform has 47 features, and someone says, well, we gotta build an API, you have to determine which of those 47 features are the ones that drive value and ultimately gonna help sales, right, because you can’t just say, okay, we’re gonna — no one’s gonna give you the time to build out an API for all 47, and that’s a business problem, what’s important.

Yeah, well, as I’m going around the various enterprises, I’m really trying to, one, focus on the product problem, the kind of business, and get out of the kind of core tech realm, so I’m going to healthcare industry, I’m in finance where things don’t change too fast unless it’s broken, and I get a lot of people who don’t see the API, and they definitely don’t see it as a product. They’re making an argument that, well, we have SDKs that abstract away a lot of those problems, and a lot of things we’re dealing with we just give people SDKs. So help us understand, what’s the relationship between an API and an SDK?

It’s a great question. An API is typically built for a business purpose, to solve a business problem in a specific way, but that API needs consumers in order to be successful. By itself the API is just, you know, it’s just like a piece of mail that hasn’t been delivered yet, but the consumers are actually what drives value to that, and the SDKs make it easier for those consumers to add value to your organization. But the SDKs themselves are only so good. If you wrap an SDK around a poor API, then you’re not going to have many consumers either, right? That maybe the API hasn’t exposed a couple key features. I’ve seen this multiple times, where there’s an API strategy but a couple of the key features aren’t there, so no one’s actually able to really use the API, even though the company invested like a hundred thousand dollars in the whole strategy so far. So the SDKs are the thing that makes it easy to use for developers, it’s called developer experience, and developer experience matters because you can get things done quicker.

So yeah, I mean, you could be abstracting away the wrong things with your SDK without it being part of a larger experience strategy, understanding your consumers. One last question for you though, what’s in it for you, what keeps you coming back and working in the space?

Yeah, I mean, I enjoy solving problems, and recognizing that I’m a creator, I’m a builder, and the way that things get built the proper way is when you have the right contracts and the right abstractions in place, and APIs are the primary mechanism for that. And there’s a lot of creativity even in the world of APIs, depending on whether you’re doing event-driven or whether you’re doing bulk APIs. And Salesforce is a really good example. If you look at Salesforce APIs and all the variety of APIs that Salesforce has produced, they’re actually solving different business problems for each of their API patterns, and that’s really fascinating to me. Other people may not geek out about that stuff, but I’m like, I know why Salesforce introduced that API, because they were trying to solve that business problem, and that was the only pattern that could do it.

Yeah, I’m a fan of looking through people’s portals and reading their blog posts, looking at their resources, their endpoints, and how they separate their APIs from each other, and Salesforce is endless in the lessons there, and how — because it’s not just the technical details, it’s the business details as well, right.

Right.

Well, I appreciate coming by, Dale, this has been great. I love catching up with you and appreciate you sharing the product and the business lens of the space, because I think we need to spend more time here. I appreciate being on.

Thank you.

All right, well, I love diving into the business alignment side of this, definitely it’s one of the reasons I’m firing back up this podcast, is to have more conversations with product managers. I’d like to bring Dale back and talk more about maybe the tooling that product managers use, more of those stories and arguments that we can make to business leadership to get them on board. But that’ll have to wait until a later date. But until then, thanks everyone.