Dale McCrory


Bio: Internet technologist with deep experience in B2B product management building SaaS-based platforms in multiple enterprise domains (education, finance, and marketing). I'm passionate about SaaS excellence and have deep knowledge in building SaaS products, Kanban agile project management, product strategy, building teams, API strategy, data analytics, product messaging, and technology standards (PaaS/containers/APIs) that impact the user and developer experience.

Role: Software and Product Management Leader

Company: Software and Product Management Leader

Industry: Breeze Strategy


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

I had a conversation with Dale McCrory, Software and Product Management Leader at Breeze Strategy about the business and product manager view of the API landscape. I am eager to hear from veteran API product managers like Dale about how we convince leadership to invest in APIs, but also API product managers. Dale has a healthy view of the business of APIs, and how this applies across the many different types of APIs we produce and consume--which is something we need more of in the API world to help balance our heavy focus on the technology of APIs over the last decade.




Who are you?
Hi. My name is Dale McCrory, and I'm an experienced product manager doing A P I S in the enterprise and technology industry. And SAS world for a long time and, uh, currently have a consulting company that I started up as well, um, to kind of help, help others with their strategies and technology strategies. And, uh, and so that's kind of what I've been doing, doing this for over 20 years at this point, I think.
Why should business leadership care about APIs?
Yeah, it's, it's a, it's a great question. Um, a lot of times in the, in, if we're just talking about the enterprise space before you get into like software as a service and that sort of thing, but if you're a normal classical enterprise, a lot of your integrations, uh, historically have been going directly to databases. You might have a, you might have developers who are used to doing it that way. And they've, they've built a lot of, a lot of integrations to databases and over time, what happens is not only do you lose those developers and, you know, but, 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, um, and, and this is, and it's a, it's an aspect of how many, how many people need to know about change as well. So there's a big change management aspect to APIs. It's probably one of the leading, leading needs that you need as a, 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 lot, a number of teams working on a single, single problem. And then, you know, you always get like, well, why didn't, 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. You know, and then someone says, well, if we had a good, really nice API around here, we could have actually, you know, made a non breaking change. And you would have never, you never would have even known that we made that change. Right. And that's a spot that a lot of enterprises are still in as their teams are trying to work together. Right. And, and, you know, like sticking to, uh, an API first mentality, uh, limits, limits risk. And that's a big deal.
Why do businesses need an API product manager?
Yeah. I mean, they're technical configurations, but they have a life cycle and that's the key thing. Um, with, with API is the moment you introduce an API. So you, you've, you've solved the risk problem by introducing the API. So you got the risk problem solved, but now you, you've done, you've added this new thing that has a life cycle, has multiple versions, and you're gonna have to live with it forever. So even as if one, if your business, if your business needs change, this API needs to change in an orderly fashion. And, and it needs to be, you know, treated like a product. And, you know, that has versions that has a business problem that it's solving, you know, 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, um, an enterprise might be doing. A strategic integration, right? So there's a difference between a strategic integration and ecosystem, right? A strategic integration is I'm an enterprise corporation, and I'm strategically going to integrate in with one of my key suppliers, right? That actually requires a fair level of thought. That isn't a UX problem, but it will be around forever. And as your business evolves and as your suppliers business evolves, You need to keep iterating those systems and
What are the different types of APIs?
That's a, that's a great question. That's a great question because Yes. Typically when the first thing a product manager gets hit with APIs is just because their developers are building a single page application and 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 tied to JWT or some front end mechanism. And, you know, and then they're like, Oh, we've got APIs. And then someone's like, okay. That's great. Um, that'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. They're like, well, can we take that one that we built for the UI over there to kind of like use it for the strategic integration? And the developers are like, no, it 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. The business process is really cludgy. It'd take like eight API calls over here, but we really need an API that does like all that and like one API call. And then somebody needs to think that through and design that is that an architect, you know, a product manager gets in there and says, well, I understand what needs to be in there and what doesn't. And that's really what, um, you know, at that particular stage, you know, you're looking at before you get to the ecosystems and trying to build all sorts of other external public stuff.
How do you generate value from APIs?
Um, well, I mean, traditionally, traditionally the you, an API is introduced. For the strategic integration, which is a, which, which is the first step in a partner ecosystem, right? Strategics are to your first step in a partner ecosystem saying, all right, my business, my sales team, my executives say we need to actually have a tight technology relationship with this other vendor. Okay. Well, the API product manager says, okay, I see the business value of that tight relationship with this, with this set or set or multiple one or many vendors, and we're going to build some APIs to make sure that 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 want it We have a lot of problems to solve and we know we can't we can't solve all these problems with just a couple strategic vendors you know and um And we would really want to enable like 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 and application domain.
Are APIs more than just technical?
Yeah, because if you're, if your application or platform has, I don't know, 47, 47 features can, if you got 47 features and someone says, well, we got to build an API, you have to determine which of those 47 features are the ones that drive value and ultimately are going to help sales, right? Because you can't like just say, okay, we're going to, because you're, you're not, no one's going to give you the time to build out an API for all 47 things. Um, and that's a business problem. Um, what's important?
What is the difference between API and SDKs?
Yeah, that's a great question. So the API is, 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, you know, a piece of 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, to add value to your organization. Um, and the, but, 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 of 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, really use the API, even though the company may have invested like a hundred thousand dollars in the whole strategy. So far, you know, um, so that's kind of a, um, you know, the SDKs are, are the thing that makes it easy to use. Um, and for developers, it's, it's called developer experience now in the realm of developer experience and developer experience matters because you can get things done quicker. So,
What keeps you going each day?
Yeah, I mean, I, I enjoy solving problems and recognizing that, um, I'm, I'm a creator, I'm a builder, right. And the way that things get built in a proper way. Is when you have the right contracts in the right, uh, abstractions in place. And, um, and APIs are the primary mechanism for that. And, um, and it's also, there's a lot of creativity even in the world of APIs, depending on whether you're doing event event driven or whether you're doing. Bulk APIs and Salesforce is a really good example. If you look at Salesforce's. APIs and the, 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 when, to me, that's fascinating to me again, not if other people may not geek out about that stuff, but I'm like, man. I know why Salesforce introduced that API because they were trying to solve that business problem, you know, and that was the only pattern that could do it. Um, so that was, um, so that's what I love.

All People