How I Transitioned from Data Scientist to Product Manager at Google

Years ago I was hired as a Data Scientist at Google. Receiving that offer was a monumental, epochal moment in my life. Flashing forward several years, you’d find that I was doing pretty well, securing a few promotions along the way. Despite my success in data science, I grew more and more intrigued with the notion of transitioning into product management. I’ve since moved on from Google, but that’s the topic of a future article!

Curiously, I soon realized during my transition that there was a true dearth of information around data scientist → product manager transitions. Even today, when you throw a few keyword searches out there, there’s still not that much directly relevant material. In many ways, this experience was the genesis of my article. I became determined to share my story and connect with people in the same or similar boat.

Before I dive in, a few things to call out. My transition was, obviously, at Google, so my experience may not apply or have a strong parallel with all other companies. To that end, I’m going to try to stay high level and not be Google specific. Moreover, since I did the transition a few years ago, the process may have already be significantly different. In summation, please take my descriptions as a reference point, but not as the source of truth.

First, Try Product Management Out If You Can

I cannot emphasize this enough: try out product management in any capacity if you’ve ever remotely entertained the idea of being a PM. The grass is always greener on the other PM side… mostly. Look, certainly the grass is greener in many respects, but I found people (including myself) had some false assumptions or expectations about everything a PM role entailed.

At Google, there’s a “PM Rotation Program” for people who want to scratch their Product Manager itches. Naturally, your original team needs to be okay with a rotation like this, and one of the first orders of business would be to figure out time allocation between current responsibilities and the rotation program. You’ll get a tenured PM to mentor you for the rotation. The support letter from this person, coupled with your achievements during the rotation, both will become important components for your formal transition process.

If there’s no such program, be creative. Talk to your manager and see if you can work out something. That’s the path I took. I worked 50% as a data scientist and 50% as a product manager on my team for a few months before I made the transition decision. If that’s not possible either, find some PMs to talk to, especially those who have internal transition experience. Barring that, at least read about these types of transitions. Find multiple articles or books to get a comprehensive view about becoming a PM and then actually being one.

The Exhausting Preparation

There’s a lot that goes into this… what’s worse, you’ll probably never feel ready. That’s the case for everyone though. Set a plan, execute against it, practice with friends, find people (real PMs are the best) to do mock interviews with. Learn. Optimize. Repeat ad nauseam. Don’t delay sending applications out, even if you don’t feel categorically ready. You can learn a ton from real interviews, even if you fail. Some would say especially if you fail. The point is to find out where you need to improve most.

I owe a lot of my preparation strategy to this book: Cracking the PM Interview: How to Land a Product Manager Job in Technology. To put it as bluntly as possible, if you’re serious about becoming a PM, just read it! At a very high level, you need to at least be able to answer product design questions (e.g. an alarm for blind people), estimation questions (e.g. how many tennis balls fit into a 747 plane), analytics questions (e.g. what metrics to measure and if one metric is dropping, why?), behavioral questions (e.g. your biggest failure and what you learnt), and of course, questions about yourself and your favorite products.

Note that I say at least, because sometimes you also get technical questions (e.g. explain insertion sort to a 5-year-old) and/or questions specific to the company, or even the product you’re interviewing for (e.g. three ideas to improve Booking.com). Different companies pay different degrees of attention to these, especially the technical part, which Google values a lot.

I was able to get a few mock interviews with Googlers who were PMs. They either started out or transitioned into the role. Some even had reoccurring calendar holds every week to help mock interviewing PM wannabes like me. Reflecting back on those times, I’m truly grateful. These mock interviews subsequently lead to real interviews. I threw my hat in the ring with a bunch of other companies and fortunately landed a handful of offers (e.g. Pinterest). My mindset being that if it were a great opportunity, there would be no reason to not start a new adventure. I came really close to joining Pinterest. If the offer wasn’t good or if I had simply failed, it’s still the best practice I could have had.

Interview Time!

It definitely took time (1 month+) to get the transition interviews scheduled at Google, so plan ahead. The number of interviews you get depends on a few factors. The most important ones are: if your original role is technical, and if you participated in a PM rotation program (or equivalent). Based on those, you get three to five interviews that cover product design, product analytics, and your technical skills.

Since I was a data scientist and did a few months of PM work on my team, I landed three interviews: two with PMs and one with an engineering director. The first one focused on my favorite product and the analytical questions that extended from it. My answer was MoviePass… RIP… since I am an avid theater goer. I was asked why I liked it, why it was special, and then to estimate the number of people who go to theaters in the U.S. in a year.

The second interview focused on product design. I was asked to come up with “Uber for Kids”. I first had to define “kids”, validate there’s a business market, then design the product out for primary and secondary personas. I was asked to prioritize features and explain why. Finally, there were questions around why I wanted to become a PM and how I handled some challenging scenarios.

The last interview, which I thought would be a breeze with my technical background, was conversely the one I thought I did the worst on. It came down to me not understanding the question well enough. I was chomping at the bit to code, but in actuality the interviewer was expecting more analysis and maybe some pseudo code. I finished that interview feeling absolutely awful.

The Transition

Some say it’s easier to get a PM job at another company than making a transition internally at Google. To a certain degree, this is true. You have to put together a transition application packet that requires so much more effort than merely being a great interviewee! Interview results, of course, are still paramount, but you would not want to lose points on other application materials.

You need three to five support letters from people that can speak to your PM competency. This group preferably consists of ~60% PMs and ~40% engineers. First, you have to identify the right folks to engage with. Then persuade them to help you. Following their consent, you likely would want to coordinate with them to ensure they focus on your desired points of emphasis. The operative goal here is to highlight different aspects of your PM skills.

You also need to collect your top materials that showcase your product vision, strategy, insights, leadership, creativity, execution, user empathy, technical knowledge, management of organization complexity, and so on. The list can be quite extensive. I dug through pretty much everything I had done at Google to pick out my top accomplishments. I made sure they were buttoned up and wrote a short description for each to highlight key achievements. It was a time consuming process.

The Result

After I submitted my packet, it took around three weeks to get my results. I recall vividly I was at a huge workshop with customers when I got the news. It was one of the most exciting moments in my life! Not only did I make the transition, but I also wasn’t downgraded. Unfortunately, this happens quite often at Google, especially when your original role was not a software engineer. I even heard people saying that in this case, being downgraded a level is all but guaranteed. From my experience, I can tell you that’s not true.

This was the end of my journey. It was a very stressful period. I was still fully working whilst simultaneously going through the transition. I received a lot of help and grew closer with some coworkers during the process. My final advice is to be persistent and reach out for help when you need it. Persistence is required, because you’ll likely want to give up during this exhaustive and daunting process. On the other hand, getting help can advance you faster and further. You might even be surprised at how many people are willing to help you! 😊