Over my years as a Software Quality Engineer my respect for the role of Product Manager has grown steadily. This role, critical on any complex product, has the duty of determining what changes will be made in the product. Specifically, the Product Manager determines what new pieces of functionality will be delivered in the next release and what defect fixes (if any) will be weaved into that release (or if defect fixes will be processed in a separate release). It is a challenging task - determining the right new functionalities that should be delivered among the many that are 1) being asked for by the client, 2) that changes in the market and industry demand and\or 3) that the Product Manager believes will allow the product to offer something unexpected and powerful to the product's users.
Shockingly, often it is not really the Product Manager that decides what new functionality will be built. Many times I have witnessed this very common pattern (below) occur.
Product Manager declares three new pieces of functionality to be delivered and shares the list with Development for feedback.
Development says one new piece of functionality is fine and can be built, but the remaining two pieces of functionality 1) simply cannot be built or 2) will take a very long time to develop or 3) will require additional developers or new developers (with different skill sets) to complete.
Product Manager takes Development's feedback, changing the plan to deliver the one piece of functionality that Development is OK with and fills the rest of the release with defect fixes (an easy and simple response to Development's feedback).
The pattern detailed above is common and is a terrible way to determine what new functionality is delivered, because Development is deciding what is being delivered rather than Product Management. The effect to the product when this done is worse than if the Product Manager coded the new pieces of functionality, rather than Development coding them.
I have often wondered why executives are not alarmed when Development decides what will be delivered, but the idea of Product Managers writing code would immediately be flagged (as well it should be).
With InTanj, Product Managers would be equipped to respond differently.
Product Managers will be encouraged to work with Development to push further together and determine how Development can achieve what they have stated they cannot. (If the Development team feels a piece of functionality cannot be delivered, it is important to recognize that this means success at building that piece of functionality will immediately produce a barrier to market for competitors trying to deliver the same functionality to their clients.) Product Managers also will be equipped to draw the Executive team in to show them the opportunity that Development's "no" has revealed.
If the executive team upholds Development's "no", Product Managers will have a platform to require from Development the plan Development has to increase the teams' existing skill set so that future needed new pieces of functionality can be delivered.
The Product Managers desire to minimize conflict with the Development team is understandable, but allowing the Development team to drive what new functionality is delivered (extremely common practice today) needs to end on any and all teams it is occurring on. Teams need a sound and agreed upon understanding that Product Management sets the direction for the product and that any group other than Product Management that is changing that direction is adding risk to the product and is stifling its progress (as surely as poorly written code will do).