More businesses than ever are embracing an API-first approach, with many building entire products around APIs. This doesn’t mean that the approach is suitable for every single organization out there, but you probably have a sense of whether it would be for yours.

Unfortunately, even within the tech space, some people still see APIs as something more suited to side projects and developer experiments than legitimate products. With that in mind, it can be difficult to get management to buy into embracing APIs.

One of the reasons this can feel like an uphill battle is that some developers focus on the wrong things when they pitch API implementation. The solution? Contextualize API benefits in the language of business.

Don’t worry — you don’t need an MBA for this. Just a few tweaks to how you think (and talk) about APIs can be enough to get buy-in from leadership. Let’s get into a few different ways you can do it.

Treat APIs as Products

In a recent LiveCast with Nordic APIs, Jason Harmon, CTO of Spotlight, really hammered home the API-as-a-product mentality. “An API is no different than any other product. You need to help traditional business management into understanding the relevance behind the API program.”

You wouldn’t expect your company to build a new product from scratch without answering essential questions like:

• How will this product add value to the business?
• Why are we the ones to build this product?
• Who is the ideal customer for it?
• Does it fit into our overall business model?

These should be the same questions you’re asking about an API you’re hoping to implement. Because ultimately, business leaders are always thinking about the return on investment that any new product (APIs included) can offer.

Demonstrate Use Cases

When we talk about use cases in this context, we aren’t talking about executing code.

“You don’t need to do cURL calls in front of execs — that’s not going to go well,” comments Jason. “Those are operational/technical measures,” he continues. “Think more about the outcomes, what the business value is going to be.”

In other words, who’s going to use this thing, and how are we relating in a business sense?

At a higher level, this involves positioning APIs as a game-changer that can address issues of stagnation or contention within the industry. Shifting from traditional channels, which may be monolithic and inefficient, into smoother integrated flows can, for example, help with issues like fixing leaky buckets and reducing churn.

Depending on the size of your organization, there might already be some internal case studies around API usage that you can pull from. Otherwise, look at competitors and beyond for examples of how APIs are changing the business world.

Positive Network Effects

So what exactly are some of those ways in which APIs are changing the world? As Harmon puts it, “APIs can open the door to consumers who connect to new business flows…Those are powerful personas.”

If you’re reading this post, you probably already know that APIs can do much more than help to fix leaky buckets and reduce churn. They can also open entirely new audiences, and expose those audiences to other products through cross-selling and up-selling.

As Jason mentions, people will always be wary of attending a meeting that kicks off with someone saying ‘hey, we need to reinvent the entire business’… even if that is the underlying sentiment. But more and more companies are realizing that people care less about individual products and brand loyalty than they do integrating and automating as much as possible.

In this respect, getting buy-in is less waxing about the features and functionalities of APIs and more positioning them as the solution to that problem. To quote Harmon, the message is, “we need to shift from being a tool provider to being a marketplace that helps different personas interact together on our platform… an API is just the connection point.”

Get Buy-in From Others First

“It’s my view that API-as-a-product shouldn’t only be seen as a public business tool, but also as a mindset,” says Bill Doerrfeld. Even the most ardent fan of APIs is unlikely to get far unless they become a legitimate evangelist within their organization.

When listening to pitches, one of the biggest questions in the minds of executives (after perhaps “how much is this going to cost?”) might be, “who is going to own this?” Successfully implementing an API-first approach requires input and co-operation from many different teams, from developers to marketing and support.

Talk to these different groups. Get to understand their pain points. If you can, figure out how APIs could solve some of their problems. This could be the absence of a feature would become available through integration, or perhaps slow manual processes could be automated. Speak to that, and it’ll go a long way towards getting buy-in from people throughout the business.

Know Your Expenses

Even if people in your business like the idea of embracing APIs, they’ll undoubtedly still have concerns. Although we suggested above that getting too technical straight away isn’t necessarily a great idea, it’s something you can touch on when the time is right.

For example, if higher-ups are worried about the process being disorganized or scattered, you can talk about working with OpenAPI Specification. Concerns around security? Mention how user data can be protected using OAuth or API gateways.

But one thing they’re sure to want to know about is the cost of running an API product. Even if the numbers are rough, talking about the expenses associated with an API project could impress executives and bring them around.

On the other side of that coin, it’s helpful to discuss the positive financial impact, too — consider potential freemium and API monetization strategies. Be sure to be realistic, though. It’s unlikely you’ll be able to switch on monetization on day one. Instead, the focus should first be on getting the API(s) embedded in the business.

Ignore API Buy-in at Your Peril

In his talk, Harmon, who also runs the API Intersection podcast, states that “APIs are unique as a product in the sense that it’s not very easy, necessarily, to be customer-centric in the way you approach it.”

Maybe that’s a byproduct of the fact that, for so long, they were seen more as fodder for side projects and gimmicky tools than fully-fledged projects. But those days are behind us now. Developing APIs for the sake of it without thinking critically about their implementation is a bad idea.

“If you don’t treat your APIs as products, they become just a commodity, a tech artifact,” said Harmon. “You end up with an engineered design experience instead of designing for the end-user.”

If you decide to go off and build an API on your own, without input from others within the business, that’s what’s likely to happen. The API might have some exciting features, but you won’t understand what problem it’s solving. Without that insight, it’s challenging to explain benefits to potential users OR an internal audience. Which could be the kiss of death.

Some final words of warning on that from Harmon: “If you’re not putting the business perspective around why you’re building APIs, it’s really easy to kill it from a management POV.”

On the other hand, an outright refusal to even hear you out on the value of APIs (without good reason) could be an early sign that the company is not willing to embrace change. That might be enough to get you thinking about looking for another company that is…