When I was a budding, zealous product manager, I had the same overconfidence when stepping into my first role. Reading up on product management guides (such as the infamous “Cracking the PM Interview”) and youtube interview walkthroughs from Exponent, PM to me at the time was indeed just a term dump in interviews. Like the reading states in the preface, it felt like the questions we often asked our superiors surrounding KPIs and roadmaps are never given to us. Product management in practice was far from the frameworks used in interviews, and I often questioned how much I could move the needle in a junior role or internship. Unlike the HCI classes I took where we took a product idea from 0 to 1 after 12 interviews and a myriad of iterations for a brand new, “dark horse” feature, my first product management role was in an SDK platforms team for the adtech side of a gaming company (the one that made Overwatch!) – and I was more than ready to design a new feature for any game.
The role couldn’t have been more technical and foreign to my UX-wired brain. Based on the PM archetypes outlined in the reading, I was the “Jargon Jockey” that realized very soon that my surface level metric and scrum definitions were quite useless in practice. The features that were feasible and accepted by my manager were ones without any Figma prototypes that could be attached to it. In a platform product manager role, I wasn’t designing new user experiences, doing competitive analyses for breakthrough features, or even conducting customer interviews. Working on internal tooling/platforms meant “optimizing workflows” and documenting the intangibles surrounding change management and developer productivity. The audience for any of my documentation wasn’t a UX designer but rather QA and dev teams, and I had to come to terms with the fact that just designing a new feature wasn’t always the solution. In reality, product management, as the book states and what I heavily relate to, is “fighting for incremental improvements”.
Sometimes, you can’t really tell when you move the needle or gather all the data you need to be confident in your product decisions. Most of the time, I had to spearhead all the research I needed and conduct my own internal interviews to both understand and map current processes along with aligning with higher-level business goals.
So how does a product manager deal with ambiguity? The relieving realization I’ve come to after multiple product manager roles is that you’re never expected to know everything about the product. In fact, the product manager is the “connecting” role, who should instead know who to point to that does know the answer to different questions. Of course, the product manager never has to make a decision alone. The reading makes several good points about what more a product manager is – they are in the middle, there’s lots of responsibility but little authority, and they don’t really build the product themself. As an extension to this notion, I would define product management as a role focused more on the soft skills, not dependent on any hard, technical expertise. It is a role where your day-to-day activities are focused on communication and research to give more clarity to yourself and the company about existing problems/solutions. At least for me, not having all the answers right away is what made this role take a longer time to “click” – but again, that’s what the role is all about.
