In this part 1 of 5 for the series, we’re going to look at the “Why” of digital connectivity among products first. Then we’ll dig into some details including several real-world hands-on examples.
Why APIs and Interfaces need a fresh high-level consideration.
We know the role “Digital Product Manager” has always been ambiguous. Still, ideally any Product Manager should have something to do with market awareness, looking around corners, and so on. And this includes the building blocks we may choose. 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, we should understand how our products are stitched together.
A lot of what we care about lately involves passing information and instructions from one system to another. What’s changed along the way is all the ways we do it. We need to understand how software connects at 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 leader deciding whether your company needs an agent strategy. This is especially so if you own budget for people or tools.
For a long time, the technical fluency expected of a PM was arguably stable. You didn’t need to be an engineer, but it helped to understand APIs, endpoints, requests and responses, authentication, rate limits and so on. This simplistic mental model is likely no longer enough. Postman’s 2025 State of the API found 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.
Software has more than one kind of conversation
Let’s take a simple use case. Consider checking if a package has been delivered. You 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 clicking on the tracking button in your email every hour. That’s a request and response. Or use a website sending a request every time you the user clicks a button.
Or if the functionality is there, you can just ask once from a website, “Let me know when package 123 arrives.” This is an event notification, often implemented with a webhook, (we’ll get to the details about this soon.) 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 a user, or push the change to a page through another mechanism.
Sometimes an event doesn’t belong to just one receiving system. A warehouse scan might publish an event.package.scannedAn 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. Or increasingly, an AI. Those environments can introduce their own constraints around bandwidth, power, intermittent connectivity and scale. That’s one reason lightweight publish/subscribe approaches such as MQTT are common in IoT, while industrial environments may use other standards. “IoT” isn’t one interface pattern so much as a context in which several of these patterns show up under different constraints.
Now we have more API surfaces and needs. An AI assistant needs to change a delivery address so it has a different problem. (We recently ordered a new kid’s bike and had to change a mistake in an accessory that showed as double-ordered on the confirmation. The automated system couldn’t handle that.) Such annoying order-management/customer-service exception issues may be a small percentage of transactions/use cases, but a disproportionate amount of customer service contacts as well as development effort to handle. So you built a tool. And it needs a structured way to discover available actions and invoke the correct one. Though an AI agent can call a conventional API or function, this sounds like a job for Model Context Protocol (MCP). We’ll likely see more of this, if only because for many businesses, reverse logistics is a surprisingly large operational headache, especially once returns get beyond modest volume. That’s only one use case of course, but it’s an obvious one with a lot of moving parts.
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 the costs.
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 Has Different Product Consideration 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. Finally, 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 concerns change by level, though these levels are 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 critical 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. 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
Digital product and technical questions are often tightly coupled. 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. And maybe their costs. All this can affect 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 the moment 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 a project planner that says, “Get some info from an API somewhere to do this or that.”