In this part 1 of 5 for the series, we’re going to look at the “Why”
Why APIs and Interfaces need a fresh high-level consideration.
We know the role “Digital Product Manager” has always been ambiguous, at best. PM, Tech PM, Marketing PM, now AI PM, etc. Ideally, anything with “Product Manager” in it has something to do with market awareness, looking around corners, at higher levels and so on. A lot of us may have come from some kind of coding background, but certainly not always. In any case, even if we don’t, (or shouldn’t), need to be expert developers, at every level we should understand how our products are stitched together.
Let me give you my highly reductionist product-person mental model of the internet at a basic level. A huge amount of what we care about boils down to passing information and instructions from one system to another. Yes, there’s more, but I think it’s a defensible position. What’s changed along the way is all the ways we do it. Understanding how software connects matters at both tactical and strategic levels. It doesn’t matter whether you’re a new product manager trying to understand why engineering wants a webhook instead of polling an API every thirty seconds, or a C-level product leader deciding whether your company needs an agent strategy. This is especially so if you own budget for people or tools to enable such things.
For a long time, the technical fluency expected of a PM was arguably somewhat stable. You didn’t need to be an engineer, but it helped to understand APIs, endpoints, requests and responses, authentication, rate limits and versioning. This simplistic mental model is no longer enough.
APIs are not going away, but there’s so much more than ever. Postman’s 2025 State of the API found that 82% of surveyed organizations had adopted some level of API-first development and 65% generated revenue from API programs. But it also captured new shifts. 89% of developers surveyed were using AI, while only 24% said they were actively designing APIs with AI agents in mind. It’s worth a read as a broad industry view, and that’s something PMs should have a sense of.
Software has more than one kind of conversation
Let’s take a simple use case to illustrate. Consider a product that needs to know whether a package has been delivered. You really want to know when the new liners for your food dehydrator are coming so your next attempt at dried peaches doesn’t stick to the included metal mesh trays. (A lesson I learned the hard way.) One way to check is that you can click on the tracking button in your email every hour if you like. That’s a request and response style. Or rather, in this case, have your website send a request every time a user clicks a button.
Or if the functionality is there, you can just say, “Let me know when package 123 arrives.” This is an event notification, often implemented with a webhook, (and we’ll get to the differences soon enough.) In this case, the logistics provider could send an event to a webhook endpoint on your system when the delivery status changes. Your system could then update its own records, notify the user, or push the change to an open page through another mechanism.
Sometimes an event doesn’t belong to just one receiving system. A warehouse scan might publish a package.scanned event that several downstream systems can consume independently: customer notifications, analytics, fraud monitoring, inventory, and so on. That gets us into asynchronous messaging and eventing, where the producer can keep moving without waiting for every consumer to finish its work.
Now let’s get fancier. You have a live logistics map that needs continuous location changes. Now you’re likely into some kind of streaming subscription from a logistics provider of some sort.
And sometimes the consumer isn’t another conventional application at all. It may be a scanner, sensor, vehicle, industrial controller, appliance or some other connected device. Those environments can introduce their own constraints around bandwidth, power, intermittent connectivity and scale. That is one reason lightweight publish/subscribe approaches such as MQTT are common in IoT, while industrial environments may use standards such as OPC UA. “IoT” isn’t one separate interface pattern so much as a context in which several of these patterns show up under different constraints.
Now we have more. An AI assistant needs to change a delivery address so it has a different problem. The worst. One of those annoying exception issues. They’re small percentages of your product needs, but a disproportionate amount of customer service contacts as well as development effort to handle. (Probably why they were in the backlog for so long.) This tool needs a structured way to discover available actions and invoke the correct one. Sounds like a job for Model Context Protocol (MCP) to the rescue! (Though yes, an AI agent can call a conventional API or function directly without MCP.)
But wait, there’s more! If one agent hands a delivery investigation to another specialized agent, the relationship changes again. A2A agent protocol is aimed at agent-to-agent discovery, task delegation and collaboration. This gets more solidly into developer areas, but still, you need to know, especially if you have to budget for costs here.
All of these things aren’t “just more flavors of API-like” things, nor are they necessarily competing with traditional API methods. They’re different interaction patterns that solve different problems. They have different technical needs, sure. But they also may impact UI/UX/Information Architecture. And you may end up using several of them at once.
Don’t Bother With the Acronym Soup List
If you just click into every definition of REST, GraphQL, gRPC, Webhooks, Kafka, MQTT, WebSockets, SSE, MCP, A2A you’ll maybe get a vague sense of things. That’s not our goal here.
What we need to understand, (at a high level), or be defining, (at a tactical level), are things like:
- Who – or what – is communicating?
- Who – or what – initiates?
- What’s being exchanged? (Request, event, message, continuous stream, a tool invocation or a delegated outcome?)
- Validity? Decay Rate? How long does it live?
- How much authority does the consumer have?
- What happens on failure?
- How do we observe what happened?
This is about interface literacy. And in this case I don’t mean UI, I mean interfaces between systems; the technical touchpoints that ship data here, there and everywhere.
The Same Model Works At Different Levels
A junior PM might ask why a team is polling an endpoint every thirty seconds instead of receiving an event.
A senior IC might ask whether partners need REST, GraphQL, events or some combination.
A Director might decide which of those capabilities should become shared platform infrastructure.
A VP or CPO might ask wider scope questions. If customers or other companies’ AI agents need to use our product, what exactly are we exposing? Data? Tools? Tasks? What can those systems change? What requires confirmation? What becomes a security, pricing or governance problem?
The implementation detail changes by level, and those levels are of course not hard lines. There might be just one product person handling all things! The conceptual model stays the same though. So even if it’s just one person, (maybe especially if it’s just one person), it’s good to run the checklist top to bottom. Or bottom to top. Whatever. As long as all due considerations are handled.
Agents Can Make Assumptions Visible
Traditional integrations usually start with a developer who knows what the target system does and writes code to invoke it predictably. That is, deterministically seems to be the popular phrase. Agentic systems can add a layer of decisioning, likely probabilistic. An agent may discover a set of available tools and decide which one to use based on a user’s goal. And it might make a mistake here. Hopefully, that will be visible. Silent fails are arguably the worst and most dangerous. Perhaps especially because maybe a test case doesn’t cover them and they could show up much later with some odd exception case.
MCP is evolving quickly. The July 28, 2026 specification moved the core protocol to a stateless model and added changes around routing, caching, authorization and extensions. I suppose that all seems very nice. And yet, the more layers we add on, those are also more risk areas.
The Agent2Agent (A2A) Protocol addresses a different layer. Its 1.0 release focuses on communication and task coordination between independent agents, and its own documentation describes MCP and A2A as complementary rather than replacements for one another.
Don’t worry too much about the buzzwords right now. We’ll get more into these things. The point is to take away a useful product lesson. The tech changes, but if you’re focusing on the actual interaction problem first, that strategic how part should become clearer.
Product vs. Tech Questions
Yes, of course digital product and tech questions are often tightly coupled. And no, not every architecture choice is necessarily a product discussion. But an interface becomes a product concern when it changes what customers, partners, developers, devices, agents or other systems can do or impacts what you need them to do. Or of course, their costs.
All this can impact distribution, pricing, integrations, ecosystem strategy, developer experience, security, governance and switching costs. Increasingly, it can also determine whether AI can use a product through reliable machine-readable capabilities or only through brittle workarounds.
This series will move from Why, to What & When, to How, then back out to So What, and finally to a Field Guide, which will likely be obsolete days or weeks after I post it, but ideally will still be a fair starting point for more learning.
The question to take away from all this is, “How should this product be communicating with the rest of the digital world in the touchpoints where it needs to do so.”
Again, our goal is not for all of us to become engineers or architects. Still, a digital product leader needs enough technical literacy to understand when architecture choices become product, platform, cost, governance, ecosystem and strategic choices. Regardless, the seams between things are now more complicated than just putting a high-level story item in somewhere that says, “Get some info from an API somewhere to do this or that.”