“Successful knowledge transfer involves neither computers nor documents but rather interactions between people.” — Thomas H. Davenport
The other day, a colleague pointed out that apart from his regular tasks, he now had to oversee the transition of an important resource. This made me ponder if this really was their responsibility? Through this article we talk about the role of a Product manager in Knowledge sharing, resource transition and possible ways to manage it.
Statement: Product Manager is not responsible for Resource Transition
Reality: Product Managers are responsible for the success of a Product. Anything that impacts the product, falls under the belt for a Product Manager. And hence there’s a role every product manager should play with respect to resource transition and knowledge transfer.
Product Manager as a role has evolved recently and is a complex amalgamation of skill sets and responsibilities that bring harmony to an otherwise complex environment.
This role impacts a wide range of teams and has business impact both internally and externally. While externally, this may translate to client, commercial success, but internally it brings about a confidence to the teams Product Manager interfaces with. Confidence with respect to what they have been building and a common sense of self worth aligned to a unified vision of product success. Hence, Product Managers become the Key to unlocking and balancing the knowledge base across different disciplines — the UI,UX, technology, business and the strategy. This may defer if you are a part of a large MNC with clearly defined roles but is nevertheless expected for a product success.
Product success is then drawn from a common pool of knowledge:
- Business — The why. Product manager derives the why for a product from its possible clients/customers
- UI/UX — The What — Product Manager shares their vision of what could an interface/ service look like
- Technology — The How — Product Manager validates this by asking relevant questions for the product future and client expected features and possibly negotiating what’s feasible