API Products: Who, What, Where, When, Why, and How?

Editor's Notes

• #5: First, what is a product? According to Wikipedia, “In marketing, a product is an object or system made available for consumer use; it is anything that can be offered to a market to satisfy the desire or need of a customer.” Applying the definition of product to APIs, an API Product is an API offering made available for consumer use that is offered to a target market to satisfy a customer’s needs. While a simple statement, there is much behind this. First, notice the focus on “consumer/customer”. An API product should be an attractive offering to a customer. The implication of this is that we know what a customer wants (more on how we find that out to follow later).   Assuming we have this information, we then need to build the API Product to meet this need. Is a single API the same as an API Product? The answer is that it could be. You might build a single API that meets the needs of a consumer and package it as a product to be offered to the market. Another possibility is that multiple APIs may be required to meet a customer need. In this case, rather than have the customer figure out what combination of APIs they need we can package multiple APIs as a single API Product and offer this package to the market as a simpler way to acquire the necessary solution. So, an API Product can contain one or more than one API.   Further, to make the API Product attractive to the market we may want to enhance the offering with some acquisition options. API Products can contain “plans” which are terms and conditions for use. This may include usage limits (i.e. rate limits) where consumers can sign up for the usage they require. It could also include pricing options.   Of course, we also need to establish the necessary security around the API Product to ensure the appropriate access is granted only to the target community(s) and verify their identity and authorization as the API product is acquired and used.   Let’s make a comparison to purchasing a car. While there are some people who want to buy all the individual parts and build a car, most consumers want to buy a car as a complete working vehicle. Offering a complete car is far more consumable to most customers and they would be looking elsewhere if offered a collection of parts. Of course, the car does have models to choose from – EX, SX, LX, etc. and these are like the API Product concept of plans. Some people just need more than others! Finally, when we make our car purchase, we are given the keys. Not just anyone can use the car – Security!
• #6: Summarizing from these resources, the API Product Manager has two groups of activities related to API Products: Identifying the target market / consumer and their needsThis can be broken down as follows: The product manager must identify an intended desired target audience for an offering and understand the needs of that audience. Note that this audience can be internal developers in the same company or external developers outside the company. Then the Product Manager must work with the API Developer role to have the developer build the necessary API(s) to solve the identified needs The API Product Manager then creates the product offering package (i.e. API Product) and determines/establishes the “plans” that will be offered for acquisition of the product. Driving the consumption of the API Product by the target consumerThis includes the following: Executing a set of activities to communicate the existence of the API Product to the target audience and demonstrate the value of the offering to drive consumption of the API product Measure the results and adjust marketing activities or product capabilities of the API Product based on metrics or feedback from the consumers.
• #7: API Products are created as part of an API Lifecycle managed by an API Management product. At the appropriate stage in the lifecycle, the API Management solution assists the product manager in creating the API Product offering. For example, IBMs API Connect supplies a lifecycle management process to create, secure, manage, socialize, and analyze the creation of APIs and API Products. The lifecycle capabilities support many stages specifically focused on the creation and deployment of API products as part of the overall lifecycle
• #8: API Products are offered to consumers in an API Portal. API Portals are included in many full API Lifecycle Management solutions (such as IBM API Connect).   When a potential consumer accesses the API Portal, they are shown the set of API Products that the Product manager wishes to offer to them. The consumer can explore the offerings and sign up to use the API Products that they would like to acquire. To assist the consumer and help drive the acquisition, the product manager and API Developer often supply code samples to invoke the included APIs, documentation, and the ability to try the included APIs before the consumer needs to sign up for the API offering.
• #9: If we are building APIs, there is only one reason we are doing this – because we want someone to use them. API Products are all about driving the consumption of our APIs. “If you build it, they will come” simply does not work! We are fighting for the attention of an audience and trying to drive their acquisition of an offering we have built. Without API products, we would be supplying a set of parts and requiring the consumer to figure out what they need to solve their problem. Putting this burden on the consumer may drive them to look elsewhere for an easier to consume solution. The simpler we can make the acquisition and the more complete we can make the offering, the more likely we are to succeed in our goal and drive the success of our API initiative