Folks,
Here is an interesting article i came across about “Want to create innovative Products? Tap into global brains!” .
It gives lot insight into how innovation works at globally and how it should happen!
http://knowledge.wharton.upenn.edu/india/article.cfm?articleid=4244
Happy reading!
-Yogesh
————————–
I am writing this post on a crisp Fall morning, in a world in which Google stock has crossed $700 per share, Microsoft’s tiny stake in Facebook values the company at $15 billion, and New England’s beloved Boston Red Sox have won their second World Series in four years. If any of you can explain any of that, I’d love to hear from you in the comments section of this blog.
The only conclusion I can draw? We are living in a world full of surprises. As a company, you never know who’s going to emerge as your most important rival. As an innovator, you never know where the next great idea is going to come from. As a long-suffering baseball fan, you never know when an 86-year old drought is going to turn into a dynasty.
Indeed, that surprising reality defines the new leadership frontier for executives, entrepreneurs, and game changers of all stripes. More than ever, the most powerful source of business genius isn’t the strategic brainpower of an individual CEO or the technical chops of an inspired engineer. It is the “hidden genius” of grassroots innovators inside your organization, and the collective genius of all kinds of talented people outside your organization. Increasingly, the best ideas come from the most unexpected places.
That’s what Goldcorp’s Rob McEwen learned when he invited the whole world to help him figure out where his company should explore for gold. As an entrepreneur, Rob bought a low-performing gold mine, spent years trying to find gold where the previous owners couldn’t find it—and only succeeded when he shared his proprietary geological data with the outside world and organized an open competition to devise the best drilling strategies.
That’s what shoe designer John Fluevog learned when he applied the lessons of open-source software to the creation of high-heel shoes and knee-high boots, in a program he calls open-source footwear. He unleashed the talents of passionate customers around the world, who have designed a bunch of hot-selling new models for the hot-shot designer.
That’s what the founders of Rite-Solutions learned when they decided to create a “stock market” for ideas inside their fast-growing software company, and let anyone in the organization float an idea (in the firm of a stock), and everyone in the organization invest in ideas that they like through $10,000 of opinion money.
These are just a few examples of this game-changing approach to leadership and innovation. Have you figured out how to navigate—as a company, as an executive, as an entrepreneur—in a world in which the most powerful ideas come from the most unexpected places? Don’t be surprised if that emerges as your next big challenge.
———————
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”.
Business 2.0 