APIs for Product Managers
The API Is a Contract, Not a Technology
An API is a promise about behavior, expressed as a set of rules two systems agree to follow.
Forget the acronym for a second. "Application Programming Interface" tells you nothing useful. Here's the version that will actually change how you think:
An API is the same thing as a restaurant menu. The menu doesn't tell you how the kitchen cooks the food — you don't see the stove, the technique, or the chef's mood. It tells you what you can order, what you'll get back, and what it costs. You place an order (a request), the kitchen does whatever it does (the implementation, which is none of your business as a diner), and a plate arrives (a response) that matches what the menu promised.
That's it. That's an API. Everything else in this course is detail on top of that idea.
The reason this matters to you as a PM, specifically, is the word contract. A menu that changes without warning — today's "Caesar Salad" arrives with anchovies, no allergy warning — breaks trust with every customer who ordered based on yesterday's promise. An API is exactly this, except the "customer" is another piece of software, possibly one your company doesn't own, running at 3 a.m. with no human watching. When you change an API without honoring the contract, you don't get an annoyed one-star review. You get a partner's production system silently returning wrong data to their customers, and you find out about it in a support escalation three weeks later.
Feature you're used to | API | |
|---|---|---|
Who is the "user" | A person, looking at a screen | Another piece of software, or a developer writing code against it |
How they discover problems | They complain, or you see it in analytics | Their system throws an error, or fails silently |
Tolerance for surprise change | Low, but recoverable — you can patch a UI in a day | Very low — a breaking change can take down every integration built on you, simultaneously |
Who owns the relationship | Your support team | Often nobody, until it's an incident |
Feedback loop | Fast (usage data, NPS, reviews) | Slow and quiet, until it's loud |
WORKED EXAMPLE
A payments company adds a new required field to its /charge endpoint response, thinking it's harmless — "we're just adding information, not removing any." Three integration partners' parsers, written to expect an exact response shape, throw errors on the unexpected field and stop processing charges. Nobody on the payments team sees this happen; there's no dashboard for "partner's code broke." They find out four hours later from a furious email. Nothing was removed. The contract was still broken, because the contract wasn't "here's the minimum you'll get" — for those partners' code, it was implicitly "here's exactly what you'll get, and nothing else."
YOUR MOVE THIS WEEK
Find one API your product exposes or consumes — internal or external, doesn't matter. Write down, in one sentence, "the contract": what a caller can rely on staying true. If you can't write that sentence confidently, that's your first real finding.