You've probably heard that being a product manager is like being a mini-CEO (minus some really important details), but, when it comes to making sweeping executives decisions and taking liberties with product strategy, that sentiment simply isn't true. In fact, I was humbled by how little direct influence I had, which was a big shift away from when I was lord and master over a code base. After all, I had spent the first five years of my professional career as a software engineer.
If you find yourself with an opportunity to move laterally into product management from something hands-on like engineering, you may soon be faced with the same challenges that I worked through. Despite making some big changes, I found that product management became a wonderful and stimulating career in its own way.
Change #1 - Letting go of control
As an engineer, finishing tasks was only a factor of how fast I could type and how much my manager trusted that my code edits weren't hiding catastrophic bugs. The software I coded was the stuff that real customers used to get real value. The impact of my work was easy to follow.
Once I began work as a product manager, I quickly discovered how detached I was from the development process. I wasn't designing solutions in the way I liked best. I wasn't coding things that made the product immediately better. If the team decided to pick up a project I thought would be valuable, I had no control over when that design would be finished or when that code would be shipped. Stepping in to lend a hand (aka exert control) was usually a poor use of my time.
Since a key facet of effective product management is setting expectations with stakeholders about timing, having no control over timing sounds like a nightmare. Luckily, there are ways to make educated guesses about everything from delivery delays to possible bugs by doing a little people-watching.
After working with my team for a few weeks, I started to get a sense of how ideas were turned into projects and ultimately into product updates. I learned more about who builds fast and who codes to perfection. I noticed the patterns of last-minute design changes or bug fixes that added days or weeks of development time. It was with these observations that I felt comfortable letting go of control and letting work happen.
Another way to put it is that I had to get comfortable with a "set it and forget it" mentality, that is, set up a project and forget about it until some time has gone by or until my team gave me an update.
Change #2 - Proactivity and over-communication
Product managers are often the only point of contact between their immediate team and the rest of the organization. If you work in a software company that ships software every day, it's easy for the product to change without salespeople, support reps, or even the CEO knowing until they are embarrassingly corrected by a customer.
When I was an engineer, I didn't need talk to anyone on a regular basis except for surrounding members of the product team. The ripple effects of changing the product, besides from the occasional bug or missed requirement, didn't often cross my mind. Support docs were magically updated, sales reps were automatically informed, and I was already moving on to the next project.
It turns out that any product manager I worked with was doing 100% of the heavy lifting to prime stakeholders of upcoming changes and notify them when releases eventually happened. As soon as I became a product manager, I realized how much of that pressure fell on me. I needed to become a communication machine.
If nothing else, the most important thing I could do was prevent surprises by communicating often and in as many ways as possible. Different stakeholders responded better to different types of communication; some people would read my weekly emails and some wouldn't; some people would take notes when I shared a future release date and some would forget about it until I mentioned that a release happened; some product team members prioritized work based on in-person conversations and others preferred to work though the Jira tickets top to bottom. Personalizing message delivery will become a regular part of your job as a product manager.
Change #3 - Taking notes about everything
If you believe that a product manager is a glorified note-taker... then you're on the right track. Most of my job involves observing something, taking a note about it, then serving it up later to the relevant party. These notes are everything from customer quotes to engineering's ideas to what the CEO wants to see in the product next quarter.
Software engineers take notes too, but typically those notes are translated into programming decisions, like ideal pixel dimensions or a checklist of things to clean up. The majority of notes that product managers takes don't help them build anything; their notes are meant to be regurgitated back to the team and stakeholders. The collection, analysis, and distribution of information by a product manager helps to set expectations and keep everyone aligned on the status and future state of a product.
In my past experience, I have seen product managers take notes but keep those notes locked away in a personal app or notebook. This looks like a product management activity, but it misses the point. Keeping information in your head makes you a bottleneck. It's better, in my opinion, to draw conclusions from notes and get those conclusions onto paper where teammates can see them. If some notes become irrelevant, I prefer to simply delete them.
Change #4 - Smoothing out operational problems
Your goal as a product manager is, for the most part, to help teams ship the right products to your target customers. You have done your research and are confident that you are building the right product, but what if your team struggles to ship?
I've found that, unlike when I was a software engineer, being a product manager puts me in a perfect position to deal with intra-team operational issues. Usually, the root of coordination problems is poor communication, and since I need to act as an example of excellent communication, I can always pull together a meeting to get a diagnosis. It's amazing how much little things like incorrect assumptions or favoritism can build up to the point where team members can't work with each other.
Is it really my responsibility to be a therapist? No, but it is my responsibility to help teams ship. The skills that let product managers communicate with people all over the company are the same ones that can build bridges between immediate team members. I figure that, without a cooperative team, all of my notes are moot.
Change #5 - Logging my own work alongside dev and design
Before I become a product manager, I spent a lot of time wondering what the PM on my team was doing. Engineers value physical output over communication (you feel this every time someone says "I have too many meetings"), so I struggled to see how talking to people all day was a useful skill. I was, and still am, unimpressed by calendars with 50 hours of meetings booked in a 40-hour block of working time.
So it wasn't until I began a role that involved moving information between parties that I realized I would quickly become as mysterious as the product managers that I used to work with. To combat these optics, I found ways to log my work in the same places that the rest of my team was logging theirs.
All of a sudden, standup wasn't all about reporting updates directly to me, it was about team health and accountability. When possible, I would add my own tasks into Jira, especially if they were research or analysis tasks. Best of all, during the small number of times that I opened a PR in Github or built a crude prototype in Figma, I would experience the processes that my team was going through every day–experiences which would later return as discussion topics during the bi-weekly sprint retrospective.
The transition to product management takes lots of work
Effective communication is hard. Systems thinking is hard. Trusting others is hard. Making the transition can feel like learning how to swim by swan-diving directly into the deep end of a pool.
Being a product manager can be like riding a bike, except the bike is on fire – you’re on fire, everything is on fire. (source)
Yet, if you're a self-starter, product management can still be a rewarding career move no matter which role you left behind. You'll learn the ropes in no time.
Oh, and don't forget to read The Modern Good PM/Bad PM, an updated version of the original Ben Horowitz post from the late 90's.
Banner image is a collage of three photos from my time working at Filtered as a product manager between 2018 and 2020.