Today, we're lucky to sit down with Satyajeet Salgar.
Satyajeet is a Group Product Manager at Google where he oversees the team responsible for media experiences on Google Search and Google Assistant, as well as the Google Knowledge Graph.
In our conversation, Satyajeet talks about focusing on your strengths rather than weaknesses as a PM candidate and how to build your own framework for analyzing products in PM interviews.
Kenton Kivestu: Where did it begin for you?
Satyajeet Salgar: I stumbled into product management.
My first job was as a software engineer at a startup that did storage security. A few weeks before I left for business school, the company hired its first PM (this was around employee 100). This was 2005 and there weren't many PMs back then and I recall asking her what her job was, learning about it, and thinking: "that's cool, maybe that is what I want to do."
In business school, I did an internship in consulting and realized pretty quickly that I wanted to go back into tech. I joined Google as a technology program manager. There were some PM-like aspects of the job because I worked with engineering to build things, but my primary focus was to ensure that our partnership programs were operationally ready and scalable.
KK: Got it. You still felt a pull toward product management though - why was that?
SS: I think the role is really compelling because it's at the intersection of three things I really like doing. 1) Thinking about business problems, 2) Understanding how users interact with products, and 3) Figuring out how technology can enable solutions now and in the future. These are all things I love thinking about.
KK: Was it easy to transfer into product management? You have a lot of the credentials that people are looking for (e.g., CS degree, Stanford educated).
SS: I didn't struggle with the technical bit, but it still wasn't easy even though I was transferring internally and people knew my work. I should caveat this with that this was over a decade ago and things have gotten a little better now.
At first, I interviewed for one role internally but the process took so long that by the time I finished the interviews, the role had already been filled! And so even though I was an internal transfer, I had to do fifteen interviews before I transferred to role that I ended up taking.
I also realized through the process that I tend to hesitate a lot more than I should have.
KK: Tell me more about that. What were you hesitant about, and why?
SS: Well, some people seem to approach the process with the mindset of, "I want to be a PM, I'd be great at it, let me do the job!" That was not me. My default was to identify the gaps in my own experience and think about why I might not be a great candidate.
Once I became a PM though, I realized that because of my past experiences I had some clear areas where I was stronger than my peers. Working with and managing external partners was one example.
The lesson there was that instead of looking at gaps in your own resume and experience, think about what strengths you'll bring to the product management role. Those will likely shape your performance. Understand what you're missing and have a plan to fill those gaps, but don't let those stop you.
KK: That's a good way of looking at it. Play to your strengths.
SS: Yes, exactly. In fact, one of my first PM offers (though I ended up not joining that team) originated from me reaching out and pitching a "20% project" to them on something I knew a lot about. That worked well. Basically, the idea is: show what you can do first, which makes it easier for others to take a leap of faith and give you the title. It was also a good way to overcome my hesitation since I wasn't saying, “I can definitely PM this product.” I was offering to help on a component I was really confident I could add value in.
KK: Awesome. Let's switch gears and talk about your advice to others looking to become product managers. What advice do you give to non-technical people looking to break in?
SS: Many of the best PMs I have worked with don't come from technical backgrounds, and in some ways, not having a technical background is an advantage because you don't make the mistake of trying to understand the technical complexities first and you often bring a unique lens from the humanities or design or whatever your strength is. It's critical to be able to communicate with engineers and even understand engineering complexities and tradeoffs and you need to commit to being able to learn those skills, but that rarely is what distinguishes the best PMs.
My thinking on how to prepare has evolved. Previously, I'd recommend taking a specific classes (e.g., a class on data science or algorithms). Now, my core recommendation is just to focus on learning three things: what products should be built, how should they be built and how do you bring them to market?
More than any class (though I recommend good marketing, strategy and economics classes!), the way to learn is by working on a project. If you're in school, it can be easier to do this, but in any situation, you can always take on a side project.
KK: I agree, but I'd like to hear more about why you think a side project is so helpful.
SS: The simple answer is that there isn't a standard educational program to learn to be a PM. For example, if you go to undergrad, get a CS degree and then get an entry level engineering job, you'll likely have a lot of the tools needed for success. For product management, there isn't an equivalent clear cut path, but a doing side project where you're forced to write a product requirements document (PRD) and build something is a great learning experience.
For PMs, PRDs are the closest we've got to a work product - and any experienced PM will know that's still a flawed proxy! But, writing things down is concrete. It forces you to organize and communicate your thoughts, so it's a good way to teach yourself to think about product.
KK: Agreed. How about when it comes to preparing for interviews. What is your advice?
SS: Build a framework to analyze products because if nothing else, you need something to fall back on.
To do this, I recommend picking a few products and really thinking carefully about them. Ask yourself a series of questions: Why is this product built this way? What customer needs does it serve well? How could it be improved further? In what ways might it break? What is the overall goal of the product? How does that bubble up nicely (or not) to the company strategy?
There are a ton of questions you could ask. The point is to really hammer on the problem. Over time, you'll find that different products raise different questions and you can iterate on your framework.
KK: Why is that a good approach?
SS: Because interviews will always surprise you! The model helps you cope with that.
For example, I change my interview questions a lot. I have a friend who used to bring a bag of various products, ask someone to pull out a random product and then discuss that product. How do you prepare for that?!
If you've solidified a model, you've got a way to think about that product or product problem.
KK: Where do most people get tripped up?
SS: Often, people don't think big enough or they lack specificity in how they think about the user problem. Sometimes, people don't demonstrate enough creativity in thinking about the problem. People are pretty good about preparing for the analytical and technical part, but demonstrating a good product eye is tougher.
KK: What sets great candidates apart?
SS: Well, the best interviews become increasingly conversational as the interview progresses - it feels like he/she is a colleague already and we're going through an open ended product brainstorming.
To get to that though, they often move quickly through the initial questions and demonstrate that they can think systematically and work through options.
The best candidates are just a lot of fun to interview!
KK: What final thing should aspiring PMs know?
SS: A lot of people are attracted to the job because they think PMs are mini-CEOs. That's problematic.
As a PM, you are the custodian of the product and you help ensure the right decisions get made - but it's not glamorous. The best PMs are those that step up and take the blame when things so south and deflect and distribute credit when things go well. Enjoy what the role allows you to work on and how you can grow in it vs thinking it's a position to aspire to in itself.
To recap, three key takeaways jump out in our conversation with Google product manager, Satyajeet Salgar:
Finally, if you're considering a career in product management, we encourage you to check out our Getting started guide, which is chock full of insights from PMs at companies like Google, Amazon, Stripe, Facebook, Twitter and more. If you're interested in learning more about Satyajeet, you can follow him on Twitter here.