Get under the hood and get your hands dirty

I was inspired by Rule #15 in the "42 Rules of Product Management" book by Brian Lawley and Greg Cohen (link) - "Get your hands dirty". This section of the book explains how a great product manager is a passionate one who is able to give a valuable opinion (e.g. a credible one) in the problems that the various teams on the product experience. 

The book referred to above emphasizes the importance of "being the customer" on your product - but it is more than that. As a Product Manager, getting my hands dirty in all of these areas every now and again. It is no good sitting in a bubble approving requirements and planning the future versions if you are not exposing yourself to the "real world" of actually selling, using and supporting the product. In order to be a good Product Manager, you should be proficient (at the least) in actually being a doer in each of the areas where a separate team is involved.

Getting your hands dirty doesn’t always mean ‘Learn to code’

While today’s environment for PM expects them to be technically knowledgeable, knowing how to write code is not a must-have skill in my opinion. If you understand how things work system-wise, you are not technically handicapped. This means visualizing how data flows from one system to another, having a basic understanding of system architecture and what individual components do and work, is a great way to get insight on some of the system or technical problems.

Every day I would sit with one of my developer friends and ask them to explain the system in a simple language. I would then go back home, read much deeper into the topic on the internet and understand it much better because of the knowledge imparted to me by my development folks. Sometimes, I would come back the next day with follow up questions after reading those articles or blogs to clear my doubts and enhance my understanding.

This would go on for a couple of weeks post which I do a reverse ‘Knowledge Transfer’ session with my development team. In reverse knowledge transfer, I would prepare a flow chart in Visio of the system architecture and explain them how things work system-wise. This exercise boosted my confidence in understanding a bit more of technical specification. It not only helped me in a long run to talk in a language which is understood by my development team but also helped to debug some of the issues in the system by analyzing, pointing to the place of failure, which in turn saved some time for the team .

Perform ‘Exploratory Testing’ on the system

Exploratory Testing: Cem Kraner, who coined the term in 1984, defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”

When I got the login from development team to explore the test system, I did not know the definition of ‘Exploratory Testing’ or ‘Monkey Testing’. I would read online help knowledge articles to get a gist of what these functionalities do and then sit hours doing testing, writing my observations and putting in thoughts as to why was it designed this way. With these observations, I would reach out to my SME who would then help to clear a lot of doubts. This exercise turned out to be the most fruitful thing ever because:

• I understood how the system works
• I understood the business use cases
• I understood the personas who were using the system
• I understood the pain points of the current system
• I could co-relate and imagine behind the scenes how data was stored, retrieved, manipulated.
• And most importantly, I knew the nitty-gritty of the system to microscopic level.

Do not fear ‘Data’

Getting your hands dirty also means doing your own data analysis. If you fear the data, you will never uncover the complete truth. To complete my holistic understanding of the system and getting hands-on, I started my journey to gather data on the features of the system. Salesforce, BI systems, system logs were some of the places I started to explore. Not only did this exercise help me to put numbers and draw insights of the system usage and failure points but I also learned how to use these new tools!

Understanding and exploring data was cherry on the cake for me. I got so much more confident in my learning in the past few weeks and was now in a situation where I knew a good amount of ‘Ground Realities’.

Without getting hands-on, you may be able to manage some conversations in a project, but a Product Owner/Manager who has gotten their hands dirty would always have an edge!

A key differentiator between a great and an average Product Manager is the value you can add to the product as a whole. So take the time and get your hands dirty once in a while.