Let's talk about you. Why are you here? Why are you considering becoming a PM or trying to level up your product management skills?
Let me tell you what I like about it and what can be hard about it.
What is hard about being a product manager
Meetings and email
Do you hate meetings and email? Me too.
This job can frequently be a lot of meetings (some companies are better at this than others), but it definitely is lots of writing. You learn to deal with the parts you don't like because what they yield (progress, productivity, happy people, satisfied users, etc.) makes the non-fun part worth it. I eventually have learned tactics (some of which I'll share here) to make those parts less boring/tedious, but yeah, it is definitely meetings and emails.
Feeling Productive
I was a software engineer for a decade before becoming a product manager. My job was pretty simple: write the right code. At the end of the day, my job was to ship code. Every day I woke up and went to work, I did some variety of that. Feeling productive as a software engineer was very predictable and mechanical: I felt productive when I wrote code, merged PRs, and shipped features. When I didn't do those things, I didn't feel productive.
Feeling productive is harder as a PM. You don't have the same frequent milestones on which to base your feeling of forward movement. This was a big adjustment for me. I'd end days feeling like I had done nothing when in reality, I did the correct things to move my projects along. Sometimes the right thing is all-day meetings; sometimes, the right thing is writing a lot of emails; sometimes, the right thing is one exceptionally-crafted document.
You have to rewire your professional brain to feel joyous about passing reviews, driving alignment, and, most definitely, when shipping products. Those are longer arcs than writing git commit and you need to come to terms with that.
Taking credit for work
This was another hard one for me. As an engineer, when I saw my code in production, It felt totally normal to say, "I did that" because I did: I wrote the code that did that. As a PM, I see how many people put work into it: the dev-ops team keeping the server running, the designer, the QA team, the engineer, the eng-manager, etc. It felt disingenuous for me to look at a feature I worked on and say, "I did that," because it felt like stealing credit from deserving credit.
I have since learned it's okay to say "I did that" when I look at those features and products because I did do that. I spent a lot of time making sure we were building the right things and driving a team and a company to work on it. We did that, and as part of that, I did that too. And that's okay to say.
What to do next can be unclear
As an engineer, I could always just pull the next ticket assigned to me in JIRA if I didn't know what to do. If I didn't have a ticket, I could just go work on tech debt or bug my PM for another task.
In general, as a PM, no one is telling you, "Do this" (it does happen, but it's like 5% of my work.) Generally, it's me organizing myself on what to work on and when. This is both empowering (you do what you think is best), but it is also mentally taxing, and you do second-guess yourself a lot if you are working on the right things.
Why I like being a PM
Determining the "what" of what we work on
There are times I have felt like a code monkey in my career: I got my task and was expected to do it without much say as to what I was working on. I just had to do it. As someone who enjoys thinking about how people will use what I was building, this was demoralizing and not something I enjoyed. The better places I worked actively involved me in product discussions and I felt like I got a good say in what I was building.
Product management is that, but all the time. I get to be the decision-maker on what gets built and I love that. It is the part of my job I find most fulfilling: we get to work on my ideas based on a vision I create in tandem with those I work with. This synthesizing of ideas is the most fun part of being a PM.
People, people, people
I would argue that most tech jobs are, at the end of the day, about people but especially product management. If you are not designing with who is going to be using your product in mind, you are going to fail. Products are for people. People build your products. Everything you are doing is about people. As a person who likes the interactivity of work, this is a big plus for me: I spend more time thinking about my users and interacting with my co-workers, which I find enriching.
I like being wrong
I remember the first time I went into a UX research session when I was at Netflix. Netflix has an on-site research lab where users come in, and you get to put your product in front of them and be horrified as they use your product in ways you did not expect at all.
You enter these situations with such strong expectations of "this user is going to do this action this way" and then see users over and over again either get frustrated with not being able to accomplish what you want them to or find novel ways of accomplishing their goals despite your desire.
dankeck, CC0, via Wikimedia Commons
Some folks find this invalidation of their efforts to be frustrating, but I find it exhilarating. Being wrong means you are learning. I learn constantly as a PM and it is so rewarding for me. If that sounds fun to you, then you are in the right place.
I recently read a book about this very topic, Think Again by Adam Grant. A strong recommendation from me. I loved it.
Variety of work
I am rarely bored at work. There are certainly tedious things, and a day full of end-to-end meetings can be tough, but I get to engage in so many aspects of product development that it keeps me engaged. I get to dabble in design, development, UX research, people management, resource allocations, recruiting, administration, legal, accounting, etc. A product manager interfaces with nearly every facet of the business and it ends up being really rewarding.
