Why Product Ownership transfer is complicated

Taking a complete ownership of a product from another team involving Dev & Dev-Ops is painful. There is always the possibility of missing out some minute thing which may prove the most critical thing. Also you have to deal with a lot of people and other historical issues which will eat up lot of time if not mitigated early in cycle.

Complete theoretical KT of a product ownership is not possible, no matter how much time is given. Something will be left out,which will cause embarassing situations.

I have got KT done for multiple complex products and even with hostile transitioning teams. I am sharing a template below, which is aproven one and will ensure that you won’t face any surprises.

Traditional approaches of Ownership transfer fails

Organizations invest immense amounts of time, resources, and attention in their software projects. But all too often, when it’s time to transfer the finished project to new “owners,” they settle for the most superficial classroom training, documentation, and code walkthroughs. These conventional approaches to knowledge transfer often fail, dramatically reducing the value of new systems in production .

True ownership requires experience of successes and failures; of understanding procedures intimately and knowing when to take deviations

Using the Template below

Knowledge transfer is only the first step in ownership transfer. If you are contemplating the transfer of an application system – from a vendor to in-house or from one internal location to another (as happens often today) – then you need to use this book as a model for making your transfer a success.

[embeddoc url=”https://startuppitamah.com/wp-content/uploads/2019/11/Product_DevOps_Details_Doc.xlsx” download=”all” viewer=”microsoft”]

Core tenet for the transfer exercise

The core tenet for the exercise should be“learn by doing. The guys taking the transition must be build skills in following order

  1. ABility to handle Production Fires.
  2. ABility to know the critical modules and do quick fixes in them.
  3. Ability to know the Vendor Integration points
  4. Ability to know the key points which have max failures.
  5. Ability to enhance the software.
  6. Do next set of Vendors or third party integrations.
Previous post Organic Marketing for Gaming product
Next post Health Tips for IT Professionals