Productizing an API leads to many interesting questions: But why does it exist? What do our customers use it for? What should we add to it? Is it really valuable for us and the customers or partners?
Sometimes there is a product team in charge of the API development as part of a "real" product.
Sometimes it's the API that is the product in itself.
The first case is the more difficult one, because the API may end up as a second class citizen. It's kind of out there, because "we have to have an API".
This leads to several questions:
Your sales people ain't Han Solo nor your customers Sherlock Holmes.
Your sales people are not going to spend ages finding out what a customer should do with your API. If they are daunted with a very generic, technical or non-existing description of what the benefits, use cases or in broad terms value of the API is for them, they just won't care. They will rather skip talking about the API at all or always drag the developers, product managers or who ever they can get their hands on to the sales meetings to explain things.
But the real point is, the API shouldn't need hours of explaining. It should just be there, and a person (developer, architect, business developer etc.) interested in solving a specific problem or completing a task would just find it and take it into use.
Ok, enough with the rant.
If you got interested to learn more, or think you have a colleague or friend who could benefit in digging deeper in to the subject, check out our course on designing a good value proposition for your API customers. It gives you examples and direction on what APIs to build and what is a good value proposition and why it's important. You will also learn how to use APIOps Cycles method for designing the value proposition with your team.