Role of Product Manager @ SDK/API Management

Role of Product Manager @ SDK/API Management:

Objective behind having SDK for any s/w is:

• Seamless integration with 3rd party software

• Reduce the integration/deployment cycle.

• Increase usability and quality of product

• The key audience for SDK is going to be the developers and technical team. Even to add in, I believe, system integrators/partner also should come into picture! Since even some time partner also deploy the integration rather than we as a product company.

PM should consider following points in mind while dealing with SDK/API:

 Requirement:

• Base” product will certainly place certain requirements on the SDK, but PM better be listening to the customers who use this SDK – as folks who are doing the development / integration, who would know better what features or services are needed.

• Important to specify functional requirements before working on the API signatures and how they’re accessed!

• PM better be getting pretty involved in the API definition!  PM doesn’t need to define the exact names of the function calls, parameters, etc – but PM  should probably be getting involved in the  “spirit” of API, what language its written in, how high or low level is the API (or do you provide multiple types of access routines), etc.  all an all, PM have to find the right balance for your product, your customer/market and your engineering/development team! one of the challenges here is knowing where to draw the line!

Strategy:

• PM should know where your SDK product need to be headed?  Ultimately PM need to get feedback from the various constituents (customers, partners, internal developers) and develop the appropriate strategy.

• An SDK can create some very important strategic options for your product/company.  A real good example right now is the Apple iPhone and the SDK.  Take a look at what has happened with the iPhone platform in the absence of a proper SDK – the community has found a way to get on without it and create some very interesting, compelling and valuable applications.  Apple has not yet rolled out an SDK, but has announced plans to do so early next year.  Now, as an iPhone user I hope I don’t have to pay Apple for each and every application I want on the phone, and I do like the idea of a more “open” environment, but I also see value in the “controls” that we all expect to turn up there…..

Usability:

• APIs need to be designed with a long lifespan. Hence, the PM and their engineering counterparts need to give a lot of thought about the current and future direction not only of the product but the APIs they produce.

• In API management, PM now not only care about the end features provided, but also how those end features get to the customer… what your customer will be interacting with daily (the API) to get value out of your “whole” product.

• Related to the longevity of the API is the usability of the API.  This is somewhat subjective, but just as a PM should emphasize usability, a PM working on APIs must spend as much time on ensuring that the APIs are usable and follow standard convention.

• Deprecating APIs can be a sensitive issue as it has a significant impact on customers. Changing your APIs from release to release can annoy our customers! Valid reasons for migrate to the new API include: – the old API is insecure, buggy, or highly inefficient – the old API is going away in a future release – the old API encourages very bad coding practices Not all of these reasons are of equal weight, yet deprecation is a reasonable (though not mandatory) choice in all these cases. Therefore, the use of deprecated APIs can never be made a hard error by default. Also, the deprecation comments need to help the user decide when to move to the new API, and so should briefly mention the technical reasons for deprecation. When a feature is deprecated, it is a good idea to notify the engineering organization of this fact, so that other engineers can respond to the change (pro or con) in a timely manner.

Other:

• Do not underestimate documentation, sample applications, and if possible provide/support a “developer community”.