Nice post Marsh! -- I've always found this "lie" strange in another way when applied to internal APIs. it's that the API isn't actually the product, it's the thing underneath the API that is really the product. So if your API is a new (better!) way to access (for example) to retrieve data from the customer database, then the ability to make those queries is that "product". The API team then has to realize it is competing with all the "other" ways to do the same - from the BI tools, to a naked SQL query or whatever.
With discipline, you also have to shut down those routes you really want to stamp out and push them to the better API. Or simply be so much better + helpful to those who want to switch that everyone does stop using SQL queries.
So it's really the much-loved resource that is the product, and the API teams are the heroes, making it more accessible. If the API team focused on the API itself as the product, it's easy to care more about the interface than the system it makes accessible...
Nice post Marsh! -- I've always found this "lie" strange in another way when applied to internal APIs. it's that the API isn't actually the product, it's the thing underneath the API that is really the product. So if your API is a new (better!) way to access (for example) to retrieve data from the customer database, then the ability to make those queries is that "product". The API team then has to realize it is competing with all the "other" ways to do the same - from the BI tools, to a naked SQL query or whatever.
With discipline, you also have to shut down those routes you really want to stamp out and push them to the better API. Or simply be so much better + helpful to those who want to switch that everyone does stop using SQL queries.
So it's really the much-loved resource that is the product, and the API teams are the heroes, making it more accessible. If the API team focused on the API itself as the product, it's easy to care more about the interface than the system it makes accessible...