Miksi APIesi kannattaisi olla API-tuotteita?

Mikä on onnistuneen API ohjelman salaisuus?

This is a question API professionals often get asked. While the answers to this question may vary, most API experts agree that APIs should receive the same attention as any other product. But what does that mean?

Let us look at it this way: Many organizations have hundreds of point-to-point integrations that are all unique to a specific client. No one is up to date on how many there are, what they are used for or which problems they solve. Furthermore, no one dares to take on the challenge of figuring this out. If this were the situation with any other product line in a company, the management would have intervened a long time ago.

Why does designing API products pay off?

1. Helps you identify your consumers and actual users – Every product has a target group. With APIs, it is equally important to understand who is buying and using your APIs.

2. Clarifies what your users want and value – Your API should cater to the needs of your target group. What is the business problem they are looking to solve with your API?

3. Helps you identify the shared needs of your API consumers and partners – By recognizing these common factors, you can simplify your API catalog.

4. Puts focus on the packaging – Your API should be designed and described in a way that can be understood by both people and machines. This includes, e.g., API management tools, gateways, API security controls, and coding tools.

‍

Why an API product needs a value proposition?

‍

Sometimes a product team is in charge of the API development as part of a "real" product.

Sometimes it's the API that is the product 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".

Tämä johtaa useisiin kysymyksiin:

• Why does it exist?
• Mihin asiakkaamme käyttävät sitä?
• Mitä siihen pitäisi vielä lisätä?
• Is it valuable for us and the customers or partners?

Your salespeople ain't Han Solo nor your customers Sherlock Holmes.

Your salespeople will only spend a short time determining what a customer should do with your API. If they encounter a very generic, technical, or non-existing description of what the benefits, use cases, or in broad terms, the value of the API is for them, they just won't care. They will rather skip talking about the API or always drag the developers, product managers, or whoever they can get their hands on to the sales meetings to explain things.

But the real point is the API should be simple. A person (developer, architect, business developer, etc.) interested in solving a specific problem or completing a task could start using it immediately.