Before reading Chapter 1 of “Product Management in Practice” by Matt LeMay, I had a solid understanding of what it means to be a product manager. This role is about leading a product to successful implementation and rollout. From working closely with users to understand their needs, to defining product roadmaps, milestones, and KPIs, to collaborating with designers and engineers, the role of a PM is simply not straightforward. As a product design major, being a PM makes sense because a PM is essentially a jack of all trades, master of none. I have a good understanding of user needs and design, and little to moderate understanding of the engineering and business side of things, so that makes me a good product manager, right?
Something that I didn’t know until reading LeMay’s piece was that PMs essentially do what is needed to be done to keep things afloat. This kind of scares me because I don’t know how to really code… so what if that is something that I have to do as a PM down the road? A PM might be a jack of all trades, but is he/she/they truly a jack of ALL trades? Probably not.
It’s also interesting to consider that the role of the PM varies widely not just by company, but size of company. Whereas a PM in a big company may be siloed into a particular product feature to enhance a single product, a PM in a small startup will have to pick up on many more responsibilities to keep the company afloat.
Being a PM is an ambiguous role that deals with ambiguous responsibilities and functions. Thankfully, PD has made me a master navigator of ambiguity (hopefully).
Question: If you’re a PM at a tech company, to what extent are coding skills and knowledge beneficial? How do you build rapport with engineers if you don’t speak their language?
