Getting your hands dirty: Why is ‘hands-on’ a must for most Product Manager?
Last updated: November 26, 2022 Read in fullscreen view
Recommended for you
- 01 Aug 2024
The Standish Group report 83.9% of IT projects partially or completely fail 162/1787 - 13 Apr 2024 Lessons on Teamwork and Leadership from Chinese story book "Journey to the West" 45/954
- 02 Nov 2021 What is Terms of Reference (ToR)? 25/1471
- 03 Apr 2022 Microsoft Solutions Framework (MSF) 15/1163
- 12 Oct 2022 14 Common Reasons Software Projects Fail (And How To Avoid Them) 11/506
- 18 Dec 2023 The Cone of Uncertainty in Scrum & Requirement Definition 9/648
- 18 Oct 2021 Key Elements to Ramping Up a Large Team 8/1116
- 13 Oct 2021 Outsourcing Software Development: MVP, Proof of Concept (POC) and Prototyping. Which is better? 7/427
- 07 Oct 2025 Case Study: Using the “Messaging House” Framework to Build a Digital Transformation Roadmap 7/55
- 28 Jul 2022 POC, Prototypes, Pilots and MVP: What Are the Differences? 6/613
- 04 Oct 2022 Which ERP implementation strategy is right for your business? 5/279
- 12 Dec 2021 Zero Sum Games Agile vs. Waterfall Project Management Methods 5/377
- 31 Aug 2022 What are the best practices for software contract negotiations? 5/215
- 20 Jul 2022 Software Myths and Realities 5/802
- 05 Mar 2021 How do you minimize risks when you outsource software development? 5/318
- 18 Jul 2021 How To Ramp Up An Offshore Software Development Team Quickly 4/519
- 28 Oct 2022 Build Operate Transfer (B.O.T) Model in Software Outsourcing 3/365
- 04 Oct 2021 Product Validation: The Key to Developing the Best Product Possible 3/296
- 24 Nov 2023 The project management paradox: Achieving MORE by doing LESS 3/194
- 26 Sep 2024 Successful Project Management Techniques You Need to Look Out For 3/369
- 10 Apr 2024 The Parking Lot Method: Unlocking a Simple Secret to Supercharge Your Productivity 3/403
- 14 Jun 2022 Example and Excel template of a RACI chart in Software Development 3/710
- 07 Jul 2022 Managing Project Execution Terms 3/379
- 12 Aug 2022 What is End-to-end project management? 3/383
- 02 May 2022 What Is RAID in Project Management? (With Pros and Cons) 3/736
- 15 May 2022 20 Common Mistakes Made by New or Inexperienced Project Managers 3/248
- 01 Dec 2023 Laws of Project Management 3/250
- 05 Sep 2023 The Cold Start Problem: How to Start and Scale Network Effects 3/167
- 01 May 2024 Warren Buffett’s Golden Rule for Digital Transformation: Avoiding Tech Overload 2/188
- 27 Jan 2020 Should a project manager push developers to work more hours due to mistakes of manager schedule setting? 2/414
- 05 Jun 2023 Fractional, Part-Time (virtual) or Interim CTO: Who Will Cover Your Business Needs? 2/109
- 01 Mar 2024 10 Project Management Myths 1/122
- 07 Dec 2023 12 project management myths to avoid 1/169
- 22 May 2022 What are common mistakes that new or inexperienced managers make? 1/243
- 12 Aug 2024 Understanding Google Analytics in Mumbai: A Beginner's Guide 1/85
- 06 Mar 2024 [SemRush] What Are LSI Keywords & Why They Don‘t Matter /131
- 02 Dec 2021 3 Ways to Avoid Scope Creep in IT Consulting /192
- 17 Oct 2021 Does Fast Tracking increase project cost? /350
- 13 Jan 2020 Quiz: Test your understanding project cost management /568
- 30 Nov 2023 Project Managers, Focus on Outcomes — Not Deliverables /143
- 02 Nov 2022 Difference between Change Management and Project Management /216
- 06 Jun 2022 Change Management at the Project Level /293
- 09 May 2022 Build one to throw away vs Second-system effect: What are differences? /299
- 10 May 2022 Levels of Teamwork /180
- 03 Jan 2023 Organizing your agile teams? Think about M.A.T (Mastery, Autonomy, Purpose) /333
- 23 Jun 2024 Best Practices for Managing Project Escalations /184
- 21 Jun 2024 Dead Horses and the Escalation of Commitment /124
- 02 Jun 2024 Reviving Ancient Wisdom: The Spiritual Side of Project Management /204
- 01 Aug 2022 Is planning "set it and forget it" or "set it and check it"? /264
- 19 Oct 2021 Software development life cycles /628
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.
Explore more on these topics
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!