How did you become a PM?
Part of what I’ve been doing lately is meeting with folks who are looking for their next step in their PM career, and for some of them it’s their first step, they’re transitioning to PM from another role. Many of them hear about my background and want to know the story of how I became a PM, and what tips I’d give others going through that transition. I will try to summarize my journey here as well as pull out some useful nuggets.
I started as PM when I was at Zynga - I had been there two years working primarily as a front-end UI coder for a big Facebook game. This was not exactly the job I was hired to do, but it was what the company needed. Over time as the game launched and became successful, I moved into a “pod lead” role, which meant I was overseeing the work of a small dev team but I wasn’t their manager in the traditional sense, it was closer to a TL role - which is humorous for anyone who’s ever seen me code. I had done the role for maybe a year, but I was pretty miserable, and I knew that because I wasn’t a great developer the chances to move up the ranks of the team were pretty low, I frankly was lucky I had even been given the pod lead role.
In a very specific sense though, I became a PM because I grew so frustrated with my eng role and the company that I told them I’d probably quit. I did this as part of my quarterly self-review, which I wrote the day after getting back from a long vacation. My boss read the review and said (paraphrasing): “wow. you’re much more unhappy than I thought. what can we do?”.
Once I had voiced my displeasure, I talked with my manager and discussed options. There were really two in my mind: The first was to go back to design and prototyping, which is what I had done before Zynga and what I had initially been hired to do. The challenge with this was that it wasn’t really a job function at Zynga, so the situation would have been a one off working on a side project. I knew enough about Zynga at that point to know that being a special snowflake was a great way to get melted, so I didn’t love that idea. The idea to be a PM came from me watching what people in the studio were doing and observing that the PM’s got to make almost all of the interesting design and game decisions. I also knew that Zynga at this point had a reputation for being a really strong PM culture, and I liked the idea of learning “how to PM” at a place known for it.
Over the next couple weeks, I worked with the studio leadership to advocate for a trial period as a PM. I had to convince the PM leads, the studio lead, the org director of PM, and a few other people to give me a shot. There was concern I’d be a distraction from the rest of the PM team and that they’d be losing my productivity as an engineer. The deal I struck was that I’d PM a single feature, but I’d also be responsible for doing the eng work. I’d have a single PM mentor to guide me so I wouldn’t be going all across the team asking for help. By building the feature myself, it wouldn’t take away from other dev teams. In order to do this, I agreed to be the PM during the day where I could get guidance and be the eng at night so I could dig in and work. So, from 10AM-6PM I PM’d the feature and then from 6PM-2AM I did the dev work.
At the end of a month, I launched the feature and did the outcome reporting. The feature was not an overall success, and we missed DAU and Rev targets. Despite this, the team supported the transition to PM full time. I assume that somewhere in the background someone in charge knew I wanted this really badly and was willing to support me even though I didn’t knock it out of the park. The next week we made plans for an official role transition and timeline to moving job families and titles in the org. And then I was a PM!
So, what were the lessons from this? I boil it down the following:
Lessons:
If you want to make a career change within your organization, you can start by talking to the folks around you, both in that role and others who interact with them. Also, when you tell your manager, maybe don’t do it in your self review.
When you’re working out how to make the transition, make it easy as possible for people to say ‘yes’. That could mean doing your old job for a period of time, or other adjustments so there is limited downside to the organization in supporting you.
Take advantage of your strengths to make the transition easier. In my case that was moving to a role on my existing team where I knew the product intimately and had relationships established across the organization. Even more important was that over the previous two years I had established myself as a hard diligent worker willing to put the team first.
Above all else, it’s important to have a sponsor who’s willing to support you in your career transition. I do not know the “behind the scenes” story about how my PM transition was approved but I am sure a big part of it was the leadership being willing to vouch for me. Finding someone willing to take some risk on your behalf is very helpful.