Menu

Product Management: The Good, the Hard, and How to Know If It’s Right for You

An engineer recently sent me some questions about the Product Management role. I took a long time to respond because I saw it as a great opportunity to reflect on the role and what it means to me. I decided to share my answers below, in case it’s useful for anyone else!

What did you like the most about your job as a PM? (I say past tense because Director can be different)

The joy of shipping, and shepherding products and features from ideas all the way through execution and user feedback and continuous iteration.

To me, the PM role is a people job. How do we get people to work together to do amazing work? How do we get the best ideas out, how do we make them real? How do we build things that people genuinely enjoy using, and don’t mind paying for? How can we understand how our products make people feel, and how can we make that better?

If you’re able to get into a product loop that does that over and over, it’s the best job in the world. You get to understand complex user, business, and technical needs, make sense of it all, and support a team of people to get useful products into the world. And then you get to talk to the people who use those products about how to make them even better.

Daniel Pink says we are all motivated by 3 things: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). At the best of times, I can’t think of another job that combines those 3 things as thoroughly as Product Management does.

What is the one aspect of the role that makes you from time to time (but consistently) say “I don’t think I want to do this any longer”? Or “I need a break from this”?

When we get caught up in the human tendency to forget about what we’re trying to do (that purpose from the previous question), and focus on our own needs instead. When I interact with teams and people who find their identity in their work to such an extent that it overshadows how cool it is that we get to do this stuff together. In short: when internal politics take over.

I don’t resent this tendency any more, to be honest. I used to, but not any more. This is normal human behavior—I am not immune to it, no one is. We want to feel heard, we want to feel useful, we want to be seen as competent and smart. But I now recognize very quickly when a discussion about a project or a product becomes about self-preservation vs. what is best for the team and the product and its users, and I am allergic to it. It makes everything more stressful. It requires having to “read between the lines” every minute of the day. It slows everything down. It makes everyone grumpy and wary of each other. It is poison to healthy teams and products, and it affects me deeply (too much).

I deal with it by losing myself in side projects, and spending deliberate time with the work people who don’t succumb to that behavior.

How do you advise me if I were considering either an EM or PM role to decide on which is more suitable to try out first?

I think the best starting point is to reflect on where you naturally find energy, especially when things get hard. Do you find satisfaction in crafting elegant systems and seeing the architecture click into place? Or do you come alive when you hear someone articulate a pain point and you can immediately imagine a better experience? Do you find yourself trying to optimize team throughput and code quality, or do you have an interest in clarifying ambiguity, getting people to work together happily and effectively, and shaping decisions through influence rather than control?

PMs and EMs both lead, but in different ways. Engineering Managers lead through technical insight, mentorship, and a responsibility for the velocity, health, and growth of the team. Their scope is often constrained by the product strategy/roadmap and what’s possible technically, and their main outcome is helping the team build the right thing in the right way.

Product Managers lead through context, clarity, and storytelling. They untangle complex ambiguity, and they create clarity when everyone sees the world differently (which happens on every project…). Their main outcomes are making sense out of too many chaotic inputs, aligning everyone on the problem to be solved (and how to solve it), and keeping the team connected to each other and customers.