To put it in one line: the product manager is the Jack of all trades. A product manager is multi-faceted and deals with the technical, design, managerial, as well as emotional needs of the team. A PM proactively gauges the demands of their team, identifies roadblocks and miscommunications, and bridges any potential gap within his team. To make matters more interesting, PMs often coordinate with other teams and manage peers who are not obliged to work for them.
A PM has no hard-coded success mantra to establish all of the above. One has to rely on their own judgment and experience. Matt LeMay tells us that all PMs are bound to have gloomy days of self-doubt, but how one navigates through these phases matters the most. It might be easy to fall into a cycle of insecurity, defensive attitude, and repeat the same mistakes. To break from this cycle, one needs to communicate with his/her team, seek active feedback to improve as a team player, and recognize and fix the error.
As per the book, a PM has responsibility without much authority. But human nature craves validation and quantifiable measure of success – there might be times when the work appears mundane and improvident. To guide through such tough times, a PM needs to see whether his team is actively working towards impactful deliverables – that should determine the job’s success and satisfaction.
One of my friends (let’s call him P), who worked as a PM this Summer, summarized his final presentation as follows- Mentor: Hey P, great work. I am sorry that you had to change teams thrice in your internship and worked on projects that barely had any roadmap. I wish I could help you navigate through the design meetings better, but I was out of the office for 3 weeks. Manager: What? No! This is exactly how the PM job is, and it’s good that you got a realistic internship. I am not sorry, but happy that you lived up to the expectations.
Reading through the book’s first two chapters, all I could think was, ‘Wow, this book is so fresh and real’. It is interesting to note how the structure of the book is similar to a PM’s job: All the different chapters (responsibilities) hold different substance (need different skills), but they blur and blend into each other (holistically constitute a PM job), with numerous interlinked references in between the chapters (active communication and delicate coordination).
However, is there any specific reason why companies recruit different people under different roles such as Project Manager, Product Manager, and other ‘pro** **er’? All these titles coexist without specific boundaries. Wouldn’t it be better to hire ‘product manager’s, rather than complicate and aim to demarcate between intricate dynamics of these interrelated jobs?
