Most products are used by a person who wants to get something done. A platform, an API, or an internal technical product is used by someone who wants to build something else on top of it. That sounds like a small distinction. It changes almost everything about how you decide what to ship, what to measure, and what counts as a good day.

The trap is treating "platform" and "API" as engineering words, plumbing the product team can safely ignore. They are product words. An API is a product with users, a roadmap, a support burden and a reputation. A platform is a business model, not a tech stack. Leaders who miss that ship technically sound work nobody adopts.

The quick version

  • A platform is something others build economic value on top of, not just software you happen to call a platform. The test is whether the value created by everyone using it can exceed the value of the company that built it.
  • An API is a product. Its users are developers; its UX is documentation, predictability and the time it takes to make the first call work.
  • Technical products win on contracts and trust: a stable interface you don't break, so people can safely depend on you. Breaking that contract is the cardinal sin.
  • The hardest part isn't the code, it's the chicken-and-egg adoption problem and the fact that your "customer" can't tell you what they want in a usability test the way an end user can.

The idea in depth

Three ideas sit underneath this topic, and they're often confused for one another. A platform is an economic structure. An API is the interface and the product surface. And "technical product" is the discipline of building for a builder. Take them in turn.

A platform is defined by who captures the value, not by your architecture

The most useful definition of "platform" didn't come from a textbook. It came from Bill Gates, in a meeting around 2007, telling Chamath Palihapitiya that the Facebook Platform he was describing wasn't one, a moment Palihapitiya still brings up. The phrasing that stuck is Ben Thompson's, who built a whole essay on it: "A platform is when the economic value of everybody that uses it exceeds the value of the company that creates it." Thompson called this the "Bill Gates Line" and used it to separate true platforms, which facilitate independent businesses that thrive on top of them, from aggregators, which intermediate and control the relationship and capture most of the value themselves.

Stop asking "is our thing a platform?", almost everyone answers yes, and ask instead: could a third party build a real business on us, and would we let them? If the honest answer is that you'd rather they didn't, because you want all the value, then you're building an aggregator or a product, and that's a legitimate choice. Just don't run a platform strategy, with platform investment and platform patience, on something that isn't one. The label sets the expectations.

Geoffrey Parker, Marshall Van Alstyne and Sangeet Paul Choudary, in Platform Revolution (2016) and their HBR article "Pipelines, Platforms, and the New Rules of Strategy", draw the same line as pipeline vs platform. A pipeline creates value in a straight line, design, build, sell. A platform creates value by enabling interactions between producers and consumers it doesn't own, so the critical asset moves from inside the firm (your code) to outside it (the community building on you). That's why the topic matters to a product leader: you stop optimising what you produce and start optimising what others produce through you.

An API is a product, and its user is a developer

An Application Programming Interface is just a contract: a defined way for one piece of software to ask another to do something. The leadership insight is that this contract has users, developers, and they have a user experience as real as any consumer's. Their "onboarding" is your documentation. Their "first-run experience" is time-to-first-successful-call. Their "churn" is silently switching to a competitor's endpoint because yours returned an unhelpful error at 2am.

Run an API like a product, then, with the same instruments you'd point at a consumer app: a getting-started path you've actually timed, error messages that tell a developer how to fix the problem, versioning so changes are predictable, and usage analytics so you know which endpoints are loved and which are dead weight. The best API teams obsess over the first ten minutes the way the best consumer teams obsess over the signup funnel, because a developer who can't get a "hello world" working in that window rarely comes back.

"All teams will henceforth expose their data and functionality through service interfaces… there will be no other form of interprocess communication allowed… no back-doors whatsoever.", Jeff Bezos's API mandate, as recalled by Steve Yegge

The famous illustration of treating internal interfaces as products is the Amazon "API mandate." Around 2002, by Steve Yegge's well-known account, Jeff Bezos ordered that every team expose its data and functionality through service interfaces, that all communication happen through them with "no back-doors whatsoever," and, the load-bearing clause, that every interface be designed "to be externalizable." Internal plumbing was forced to meet a product bar, and that discipline is widely credited as a precondition for Amazon Web Services existing at all. The move for a leader: hold your internal APIs to the standard you'd hold a public one, because it's the standard your platform will inherit.

flowchart TD
    Q("Could a third party build a real business on top of us?") -->|Yes, and we'd welcome it| P("Platform: optimise what others produce through you")
    Q -->|We'd rather capture the value ourselves| A("Aggregator / product: optimise what you produce")
    P --> C("Run the interface as a product: docs, versioning, trust")
    A --> C
The first question isn't technical. It's about who captures the value, that decides whether you're running a platform strategy at all. Leaders Loop

The contract is the product, and breaking it is the cardinal sin

When someone builds on your API or platform, they are betting their own product on your stability. Every breaking change you ship, a renamed field, a removed endpoint, a changed default, breaks their thing, often without warning. The trust you earn by not doing this is the real asset. It's why mature platforms version aggressively, deprecate slowly with long notice, and treat a backwards-incompatible change as a serious event rather than a routine release.

The job, then, is to make the contract explicit and defend it: publish what's stable versus experimental, set a deprecation policy with real timelines, and resist the engineering urge to "just clean this up" when real customers depend on the messy version. A platform's reputation is built slowly through reliability and lost instantly through a careless Tuesday-afternoon change.

An honest limitation. Most of this is hard-won practitioner wisdom, not peer-reviewed science. The Bill Gates Line is a memorable heuristic, not a measured law, and people argue endlessly about whether a given company is "really" a platform. Platform business-model research is younger and thinner than, say, the strategy canon it's challenging. And the model has a dark side its own proponents acknowledge: platforms that succeed can tip into the aggregator behaviour they started by avoiding, squeezing the very builders who made them valuable. Choudary himself talks openly about that downside. Use these ideas as a lens for deciding and a vocabulary for arguing, not as a guarantee that calling something a platform makes it one, or makes it good.

A worked example

The figures below are illustrative, a composite scenario, not a real company's data, but the decisions are the ones a technical-product leader actually faces.

Priya leads product for the payments team at a mid-size logistics company. Her team built an internal service that calculates shipping rates. Three other teams want to use it; two partner companies have asked for access. Leadership has started calling it "the rates platform." Priya's job is to decide what that word should mean.

She starts with the Gates question, not the architecture. Could a partner build a real business on top of our rates engine, and do we want them to? The answer is a qualified yes, partners reselling logistics services would benefit, and the company wins if they do, so a platform strategy is defensible. But today it's an internal service with one happy team and a lot of undocumented assumptions. Calling it a platform doesn't make it one; it sets a bar she now has to clear.

She treats the API as a product. The team's instinct was to add features, bulk pricing, currency conversion. Priya reprioritises around the developer's first ten minutes instead. She has an engineer from an unrelated team make a single rate call cold, with only the docs. It takes him forty minutes and two Slack messages. That number, illustrative, but the kind you should measure, becomes the headline metric. They rewrite the quickstart, fix the three error messages that sent him to Slack, and get a cold first call under five minutes. Internal adoption roughly doubles the next quarter, because the friction quietly blocking it is gone.

Then the contract test arrives. An engineer wants to rename a confusing field from cost to amount_cents. Clean, correct, and breaking, because two teams already parse cost. Six months earlier they'd have shipped it. Now Priya treats the interface as a contract: they add amount_cents alongside cost, deprecate the old field with a six-month sunset in the docs, and ship a changelog. Nobody's product breaks. The cost is a little duplicated code for two quarters; the return is the thing a platform runs on, the quiet confidence of every team that depends on her that she won't pull the rug.

The unlock isn't any single decision. It's the order Priya put them in: decide what kind of thing you're building first, run the interface as a product second, and defend the contract always. That sequence is what turns an internal service that leadership called a platform into something that could actually become one.

flowchart LR
    S("Internal rates service, one happy team") -->|Ask the Gates question| D("Platform strategy is defensible")
    D -->|Measure & cut time-to-first-call| G("40 min cold start - 5 min")
    G -->|Defend the contract on the rename| T("Add field, deprecate slowly, break nothing")
    T --> R("A dependency teams trust")
Priya's path (illustrative): name the model, fix the developer's first ten minutes, then protect the contract. Leaders Loop

Frequently asked questions

What's the actual difference between a product, a platform and an API?

A product solves a problem for an end user. An API is an interface, a defined contract one piece of software uses to talk to another, with developers as its users. A platform is a business model: something third parties build their own value on top of, where you win by enabling their success rather than capturing all the value yourself. A thing can be all three at once, an API is often how you expose a platform, but the words answer different questions: what does it do, how do you reach it, and who captures the value.

How do we know if we have a real platform or just software we call one?

Apply the Bill Gates Line: could the combined economic value created by everyone building on you plausibly exceed your own company's value, and would you actually welcome that? If you'd rather keep all the value, you have a product or an aggregator, which is fine, but don't fund it or measure it like a platform. The label should match the strategy, because it sets expectations about investment, patience and how you treat the people building on you.

Why is an API "a product" if no customer ever sees it?

Because someone does see it, a developer, who is a customer with a deadline and alternatives. Their experience is your documentation, your error messages and how long it takes to make the first call succeed. Treat those badly and they leave, exactly like a consumer abandoning a broken signup flow. The Amazon API mandate worked precisely because it forced internal interfaces to meet an external product bar before anyone outside ever used them.

How do we solve the chicken-and-egg problem of getting people to build on us?

This is the genuinely hard part, and there's no clean formula. Common moves: be your own first customer (build something real on your own platform so it's proven and not theoretical), make the time-to-first-value trivially short so trying you is cheap, and seed the side of the market that's scarcer with extra effort. The honest caveat is that many platforms never escape this problem, most of the value accrues to a few that do, so go in clear-eyed about the odds.

How do we balance moving fast against not breaking the people who depend on us?

Separate the two surfaces. Behind your stable contract, change whatever you like as fast as you like. On the contract itself, the public fields, endpoints and behaviours people parse, move slowly and visibly: version, deprecate with long notice, and never ship a silent breaking change. Speed lives in the implementation; stability lives in the interface. Confusing the two is how platforms lose the trust that took years to build.

Related in the Toolkit

Where to go next