Every endpoint you ship is a permanent liability: something you now have to document, version, secure, monitor, and support, indefinitely, because someone, somewhere, will eventually depend on it. The discovery question isn't "could we build this" — it's almost always yes — it's "does the value of exposing this capability outweigh the permanent cost of maintaining a public promise about it."

A simple filter that catches most bad API ideas before they cost anything:

Ask	If yes	If no
Is there a specific, named caller (internal team, partner, or a clear developer segment) who needs this today?	Proceed to scoping	You're speculating. Prototype it as an internal-only capability first.
Can we describe the smallest version of this that solves the real problem?	Build the smallest version	You're probably designing a platform when the ask was a feature
Have we looked at how similar capabilities are shaped elsewhere in our own API?	Reuse the pattern	You're about to introduce inconsistency that costs every future developer time
Do we have a plan for what this costs to run at 10x current usage?	Proceed	You're about to get a very unpleasant infrastructure bill or an outage

YOUR MOVE THIS WEEK

Take the next API endpoint someone requests from you. Run it through this table out loud, in the meeting, before agreeing to scope it. Watch how many "obviously yes" requests turn out to have a real gap once you ask "who, specifically, needs this today."

APIs for Product Managers

Module 1Module 1: What an API Actually Is

Module 2Module 2: How APIs Work, Just Enough to Be Dangerous

Module 3Module 3: Designing APIs as a Product, Not a Feature

Module 4Module 4: The API Product Lifecycle

Module 5Module 5: Strategy, Security, and Working Cross-Functionally

Deciding What API to Build (and What Not To)