The other day a friend of mine was explaining the role of a product manager (PM) to another friend using phrases such as “they organize the team, see deadlines are met, and interface with business strategists”. I immediately chimed in, “But that’s a project manager, isn’t it?” I had fallen prey to the idea that I knew what was and wasn’t a product manager from simply reading a handful of websites.
The beauty of the product manager’s role to me is its elusivity. There is no precise answer to the question “what is a typical day at the office for you?” The product manager must be a designer, and engineer, and a business analyst all at once but never fully one over the other. My greatest motivation in education has always been the ability to learn a little about a lot. Diversity of knowledge and the ability it brings to confront many situations with confidence is a powerful skill to have. In a general sense, that to me is the skill the product manager brings to the table.
Before reading the first chapter from Product Management in Practice by Matt LeMay, I had some wrong preconceptions of who a product manager is and what he/she does. Knowing that the PM must be able to wear many hats and is ultimately responsible for a product’s performance, I imagined that the work-life balance of a PM must be terrible. I may not be entirely wrong, but LeMay points out that busy work often leads to little work. Aside from the lesson in time management that a PM must learn, what was compelling to me was that a PM’s example of working long hours as a way to show interest and motivation might actually backfire. If the project is on schedule and the engineers are doing a good job, this could lead to confusion on their part and a sense of stress. From the engineering perspective, I have definitely seen a manager affect me that way, and it worsened my output. Another lesson that I learned was that a PM should not get too involved in the engineering side of things. I had assumed that doing so would garner respect from the engineers, but LeMay points out that it could bring about resentment if it comes across as micromanagement. Ultimately the PM is not an engineer and should not try to be so.
Question: Since the PM role differs so widely from company to company, how can a prospective applicant know which companies are worth applying to without having to speak with numerous employees from each company? Although these conversations would be immensely helpful, they are not always practical from a time perspective.
