The readings from Matt Lemay’s book have been quite eye-opening for me to say the least. Previously, I had a limited understanding of what PMs do (most of it stemming from the associated theoretical concepts) and believed that their job had a well-defined scope as was evident from the class interactions during the first two lectures. For instance, defining a vision for what the end-product will look like, the product development timeline and “assigning” responsibilities in such a manner that every person’s output fits like a jigsaw puzzle towards that product vision. However, after reading the first chapter my perspective has shifted significantly. The responsibilities as well as the “expectations” from the person change a lot depending on the environment (for instance, when working in a startup vs a big tech company). The PM role is filled with ambiguity and dealing with this very same ambiguity is often one of the greatest challenges that a PM faces.
I remember quite vividly interacting with a couple of product managers in the big tech firm I was working in (as part of its research wing) how they remarked that they didn’t have a clear go to “manager” above them. While they did have a formal reporting chain (on paper atleast), they were often engaged in working with different teams spread over different orgs of the company with most of their work hours spent in going from one meeting to the other. What I found was that the ability to communicate clearly, getting all the technical members (such as engineers and designers) on the same page and engaging well with the different concerned stakeholders mattered more than mere problem-solving skills in their case. This is something which I wish to pick from this course.
While the chapter gives a lot of templates for what a bad PM looks like, there is a dearth of the same for what a “good” PM looks like. I would be very interested in Matt explaining the same by giving real life examples. Furthermore, with the rise of AI and increased productivity of people, what will be the impact (good or bad) on the PM role in his view? Lastly, Matt touched lightly upon cases where one might have to deal with not-so-compliant team members (say a grouchy engineer/designer). Since PMs have only responsibility and no real power, how do they navigate “managing” such people and ensuring that their behavior does not affect the product and other team members?
