The product framing is a genuine improvement on the project mentality, where an API gets built, shipped, and abandoned. A product has a named owner, a road map, real users whose needs shape it, a support commitment, and a lifecycle that includes a planned end. Applying that discipline to APIs produces markedly better outcomes than treating each one as a delivery.
So adopt the discipline. Give every API an owner with authority. Track consumers, not endpoints. Have a road map. Publish a change log. Plan for deprecation from the start. Design around a business objective rather than a backend system.
Where I have grown skeptical is the popular version of the framing, which assumes leadership cares about APIs the way product management assumes leadership cares about products. Frequently they do not. You end up with an “API product manager” who has no budget, no pricing authority, no road map ownership, and no seat where decisions get made — the title without any of the powers, which is worse than not having the title, because it looks like the problem is solved.
The honest test: does someone own this API’s outcomes, and do they have the authority to act on them? If yes, the product framing is doing real work. If no, it is a label on an org chart, and the useful move is to fix the ownership rather than to argue about the terminology.
