In this part 4 of 5 for the series, we’re going to look at the “So What?” of digital connectivity among products.
The product goal and product manager’s role with regard to things like products’ technical communication structures is to make sure the team has correctly defined the interaction the product needs. This includes customer and business consequences that will help engineering choose implementation options. This way, engineers can better determine what interface patterns and technologies are worth consideration.
There’s also a second-order goal. Product needs to determine if something should become a long-term supported product surface at all. Whether it’s an external API, webhook, event stream, device interface or something else, the moment there are external dependencies on these things, they become long-term promises involving versioning, reliability, support and so on. There are clearly costs to this, and Product, likely along with Finance and Engineering, needs to have those costs and benefits modeled.
Eight questions for product leadership
The graphic is the quick visual. The questions below are the working checklist. None of them automatically selects a technology, but together they define the interaction well enough for a much better architectural conversation.
- Consumer: Who or what needs the capability? A browser, internal service, partner, device, automation system or AI agent can bring very different operating constraints and expectations.
- Initiation: Who starts the interaction? Is the consumer asking, the provider notifying, or a producer publishing work or information for others to pick up?
- Exchange: What is actually crossing the boundary? A resource, selected data shape, command, event, asynchronous message, batch/file, stream, tool invocation or delegated task are meaningfully different exchanges.
- Duration: How long does the interaction live? One request, queued work, a batch cycle, an open session or stream, and a long-running task create different requirements.
- Autonomy: How much discretion does the other side have? There is a big difference between calling a predetermined operation, letting an AI choose a tool, and delegating responsibility for an outcome.
- Authority: What is the consumer allowed to do? Reading data, changing state, triggering external actions, spending money or making commitments may require very different permissions and approval boundaries.
- Failure and observability: What happens when something goes wrong, and how will we know? Retries, duplicates, timeouts, partial completion, audit trails and human escalation can be product requirements, not implementation trivia.
- Economics and ecosystem: What does this enable, cost and commit us to support? An interface can create partner value or platform leverage while also creating infrastructure, documentation, versioning and support obligations.
Those eight lenses are not equally important in every situation. A few tend to expose the product consequences especially quickly, so they are worth expanding on.
Start with the consumer
Before asking REST, GraphQL, events or MCP, ask who or what is on the other side. Is it your own frontend product? An internal service, a partner developer, a batch-processing system, an automation platform, a sensor or connected device, an industrial controller, an AI agent, or another company’s agent? Who or what is going to consume the information or capability you’re exposing? And why?
That distinction matters. A battery-powered sensor on an unreliable cellular connection has different constraints from an internal cloud service. A public partner API carries different expectations from an overnight EDI file exchange. An AI agent may need especially clear capability and authority boundaries because software can make choices and quickly take actions.
A private interface can probably change relatively quickly, at least compared with a public API or other external contract that can become a long-term promise.
Who initiates and who decides?
A typical request begins with a caller that knows what it wants. A webhook changes who initiates the useful exchange: instead of the consumer continually asking, the provider sends a notification when something happens. In asynchronous messaging, a producer may publish an event or piece of work without knowing exactly when each consumer will process it. A stream supports an ongoing relationship. MCP can let an AI discover which exposed tool fits a goal. A2A can move further toward delegating responsibility for an outcome.
Those are differences in control, timing and responsibility, not just communication. This is where initiation, autonomy and authority can start to overlap: who begins the exchange, who gets to choose what happens next, and what they are actually permitted to do.
Failure is still customer experience
A synchronous request can fail immediately. A webhook may need retries. A queued message may sit until a consumer recovers. A device may disappear from the network for hours. A batch file may arrive late, arrive twice, or fail validation. A delegated agent task may only partially complete.
Product requirements should therefore cover more than the happy path. What can and should be retried? How long do we wait? Can an action be reversed? How do we recognize duplicates? When does a person get involved? What does the customer or operator see while work is underway? How are we going to monitor what happened?
Decide what becomes a platform promise
Every external interface gives customers options and gives the provider obligations. APIs can enable whole ecosystems that quickly come to depend on them as part of their critical path. Events and messaging can make automation easier. Device interfaces can become embedded in physical products or operational infrastructure. MCP can make capabilities easier for AI applications to discover. Agent interoperability can allow a product to participate in workflows the company does not control end to end.
But every exposed contract also needs documentation, monitoring, lifecycle management and support. “Can we put this out there?” is a weaker question than “Are we wholly prepared to support this as part of our product surface for the anticipated life of this product or function?”
Product leadership generally does not need to dictate the transport layer. Product does need to make sure the company is solving the right interaction problem and understands the strategic value, cost and commitment to both users and the company.