API Evangelist Conversation with Rose Misseur on Shifting API Governance Left, Federated Models, and Bridging Product and Engineering

At the heart of it, the concept of API governance still remains the same to me. Coming from an engineering and product background, our focus has always been on quality, governance, and standards built into every phase of the API lifecycle. Where the shift has happened is with this massive explosion of tools. Rather than relying on heavy centralized governance processes, you kind of have your governance copilot with you right now. And it’s not just engineers — it’s cross-functional. Product and design teams have always felt left out, and that hasn’t changed, but the AI era is helping them realize they can actually get involved. It now starts right from your business case and your PRDs, not just the build or design space. So governance is no longer an afterthought, and it’s no longer something understood only by developers. The scene is changing.

Depending on who you work with, fintech and banks can still be caught up in a centralized model, where governance is seen as almost some sort of red tape — and that mindset has to change. We won’t get away from centralized in certain industries, because it’s a mindset shift. But a single group or person running everything is a big bottleneck at the speed we operate today; what we work on today is not the same tomorrow. In one of my previous places we started centralized and it collapsed because we couldn’t keep up — we had incidents. Every team does governance differently depending on the standards and policies they comply to, so there’s no one size fits all. You’ve got to have a federated model: a little autonomy for each team, with something sitting at the top that gives them guidance. Centralized and the era we’re in just don’t go hand in glove.

The elimination of negotiation is never going to happen, and it’s more of a mindset. The negotiation gets tough because the further you get from the problem — the further you are from being hands-on — that’s where the issue lies. So it comes back to the same thing: it’s a mindset, and that’s very hard to educate, regardless of how many years someone has had in the industry, or whether they come from the pre-internet or post-cloud era. I should give credit, though — there are stakeholders who are genuinely interested in the problem. Governance should be pre-baked in; it needs to start from the time you’re defining your strategy and vision. Most places I worked in still don’t have that concept of getting product people involved, and that’s partially the problem. Product folks do the storytelling and the why; engineers bring the design, elegance, and consistency. For discoverability and the future, you have to lean on the other stakeholder groups.

I think the intent is we need to shift far left — we’re still caught somewhere between the middle and governance to the right. And it all starts with thinking about the API as a product. You don’t have to be building public APIs, and you don’t have to be an API company like Spotify, but everything is fundamentally APIs today. AI cannot exist behind the scenes without APIs, so every company is going to be an API company. People who go straight into building need to put some thought into who they’re building for and who’s consuming these APIs — because it’s no longer just systems and humans, it’s agents and we don’t know what else. With our PRD templates we can help product folks describe, in plain language, exactly what outcome they want, what information they’re sending, what they’re getting back. So the gap between product, design, and engineering will be bridged very quickly, because everybody is starting to think much earlier.

The quality you get back totally depends on how much you fed it. If I give very basic, limited information, I’m going to get limited quality back. So those fundamentals need to be strong, and I don’t think everybody’s there yet — understanding how context matters, how prompts work, what information to give and how to structure it. The days when we were talking about docs are gone; now we’re talking about agents and skills, and that needs a lot of structure. Our skills are changing, so we’ve got to give people who haven’t been close to all of this some time to get on board and understand how things work. Until then, we probably still need a human in the loop — API governance and security is a very risky thing to leave entirely to your governance copilot. It amplifies what you give it, but it still needs a lot of thinking, and it doesn’t have a brain.

It comes down to how we want to embrace the differences in the times we’re in. Product and engineering will never fully align — but that’s a strength, not a weakness. The problem is one segment keeping the other out; that isn’t going to work. We need to embrace those differences, because that’s exactly where these problems get solved, and then tooling doesn’t amplify the problem, it amplifies the speed at which we can simplify governance. Roles are getting blurry because of AI — I already have agents checking the OpenAPI spec and telling me what I’m missing. But AI still needs a lot of thinking; it works on the context we provide, so the human in the loop is still needed. We do know things our engineering counterparts don’t, and they know things we don’t, and AI doesn’t know how to think. So the gap gets bridged, not closed — we just need to understand how to work together.

The biggest challenge is getting everyone on the same page when it comes to focusing on governance. We’re all chasing bigger deadlines; everybody wants to be AI-first, everybody’s looking at rewriting everything we built over the last ten years that isn’t leveraging AI. With the SaaS apocalypse everyone’s fearing the worst, and in that bubble I don’t think people understand that API quality needs to be considered even more today, not less, if they want to deliver on the vision these companies have. They get that it’s about APIs, and that we need to build them faster — but faster doesn’t necessarily mean building them the right way, and handing the work to an AI companion isn’t automatically safe. Senior stakeholders often feel that tools can do it all, and that’s the risky part. We still need that human piece.

It’s completely balanced, and it’s skyrocketed. If you take a step back, the fundamental problem is API discoverability, because we’re going to have a lot of shadow APIs — APIs created by the day, in the millions — and apps exploding across various ecosystem marketplaces too. With the SaaS apocalypse everybody’s going to panic, and we’ll see an explosion of APIs. You can’t govern what you can’t see. There are tools that help you find and catalog new APIs, but we still have very static ways of discovering them, and that’s where the problem is — we haven’t really thought about how to dynamically discover APIs. It’s striking that discoverability has been a focus for so long and, if anything, it has gotten worse. So that, to me, is the fundamental problem right now: discoverability.