While I agree with you that monetization is not what makes an API a product or not, I do have to disagree with the premise that all APIs should be managed as products. In a typical enterprise, there are going to be APIs that, whether with intent or not, are designed for one, and only one, consumer. When that consumer is also controlled by the same team/organization (think one level of hierarchy), it's common that the product management is occurring at a level above the APIs. Trying to do product management at the lower level winds up adding unnecessary overhead.
The questions I would ask to answer the question, "Should my API be managed as an independent product?" are:
1. Does the API represent an interaction point between digital interfaces and back-office business processes?
2. Does your API encapsulate clear business processes?
3. Are there external parties that are potential consumers of the API?
4. Are there teams from outside of your organizational domain (i.e. different internal teams) that are potential consumers of the API?
If any of these are yes, then treating it as a product is probably a good thing. Also note that 1 and 2 go hand-in-hand. There are plenty of APIs that are certainly a point of interaction between digital and back-office, but really don't represent a good encapsulation. If the consumer has to have intimate knowledge of the back office details, it's not likely to make a good product beyond that consumer.
While I agree with you that monetization is not what makes an API a product or not, I do have to disagree with the premise that all APIs should be managed as products. In a typical enterprise, there are going to be APIs that, whether with intent or not, are designed for one, and only one, consumer. When that consumer is also controlled by the same team/organization (think one level of hierarchy), it's common that the product management is occurring at a level above the APIs. Trying to do product management at the lower level winds up adding unnecessary overhead.
The questions I would ask to answer the question, "Should my API be managed as an independent product?" are:
1. Does the API represent an interaction point between digital interfaces and back-office business processes?
2. Does your API encapsulate clear business processes?
3. Are there external parties that are potential consumers of the API?
4. Are there teams from outside of your organizational domain (i.e. different internal teams) that are potential consumers of the API?
If any of these are yes, then treating it as a product is probably a good thing. Also note that 1 and 2 go hand-in-hand. There are plenty of APIs that are certainly a point of interaction between digital and back-office, but really don't represent a good encapsulation. If the consumer has to have intimate knowledge of the back office details, it's not likely to make a good product beyond that consumer.