Getting your hands dirty: Why being ‘hands-on’ is a must for every Product Manager
Post my MBA, I got an offer to join as a Product Owner in Bangalore (The IT Hub of India). I was in my ‘honeymoon’ phase with little or no work in the office for the initial few months of my joining, spending most of my time playing Foosball, table tennis, reading articles and talking to folks.
On the 7th week of my joining, I received a mail from my off-shore manager sitting in the US, stating that I would be a co-product owner for a project which will be developed and delivered from India Office. Within fifteen minutes of the mail being sent, I am pinged by the development team for the scope of the project, what stories to be taken up, when to start the project! It was simply overwhelming! I got dragged into a project where I had no head or tail information about the system. I had never seen the portal which had to be enhanced, let alone talk about the scope. I did not know where to begin. I reached out to a few of my team members asking if they knew how the portal worked or if there was some documentation that I could read through to make some sense. Alas, this did not yield any results.
It was almost lunchtime and I went to the canteen dejected. While getting my food, my director was standing beside me and asked why I looked so glum? We sat on a table and I explained to him the situation and how helpless I felt. He gave me just one piece of advice — “Start getting your hands dirty”. Here I am eating my food (with my bare hands — mind you, this is Indian food!) and the advice seemed ironic at that moment.
I decided to take the advice and started off. I asked for test logins from dev team and started the journey of ‘getting my hands dirty’.
Here are some insights from this exercise:
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:
a. I understood how the system works
b. I understood the business use cases
c. I understood the personas who were using the system
d. I understood the pain points of the current system
e. I could co-relate and imagine behind the scenes how data was stored, retrieved, manipulated.
f. 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!
The advice of ‘getting my hands dirty’ is still helping me to traverse through different projects, organizations in my capacity as a Product person and I hope it will be useful for you too!
