Upon starting at Stanford, I had a similar outlook on what product management entails as the author titles “product management in theory.” Through my years working for several companies and on projects in various classes, I found that product management in practice feels exactly like the author states: playing a hundred simultaneous games of checkers. I had the opinion that being a product manager (PM) requires one to be a jack-of-all-trades, one who ‘owns’ a product and is in charge of its development, delegating work to appropriate team members, incorporating feedback to consistently iterate/improve said product, and most of all, motivate myself and those under my leadership to take joy in ‘small wins.’ They’re the leader, the sounding board, the key problem solver. This was all prior to reading the preface and Chapter 1. Afterwards, I find that my perception of a PM needing to be a jack-of-all-trades is echoed by the author’s note: “If it needs to get done, it’s part of your job.” One of the hardest parts in my work experiences when acting as a PM, as the author aptly points out, is that I somehow found myself saying “never mind, I’ll just do it.” Delegating work and trusting teams I worked with to bring our vision to reality is still one of the most challenging aspects of working in this role. Secondly, when I worked as a PM, I often felt a sense of incompleteness in my work, because my work was hard to quantify; what did I accomplish when most of my day was spent advising others or solving problems on a big-picture scale? The author directly addresses this feeling and further highlights the nuances between being a PM in theory vs in practice. From this reading, I’ve augmented my understanding, that a PM ultimately has a hand in every part of the development process to complete milestones with the end goal being to improve our product and put the company in a more promising position.
If I could speak with the author, I would like to ask how to handle the situation when your expectations do not match up with the capabilities of the team? I’ve been in teams where I have to just do it myself, because I’m not even sure the appropriate person will/can do it, yet pursuing a hiring campaign to replace that person is more trouble than it’s worth. Is that a slippery slope? Secondly, how do I distinguish successes for my team from us just doing our job? If an engineer on my team deploys a code-fix for a bug as part of our product-update milestone, is that considered a ‘win’ or just them fulfilling a job responsibility? At a large scale, what is the difference between a ‘PM-success’ and me steering our team to deliver on what we were hired to do?
