I wrote earlier about the Google PM Interview Process & Preparation. That article, although lengthy, was focused on the overall interview and recruiting process. This article is going to be much more targeted on the preparation aspect for the interviews.

Although I focus on the Google PM interview, I hope this is also helpful for folks considering interviewing for PM roles in other tech companies, and even for those interviewing for other related functions.

Interview types

You will get a mix of questions throughout your PM interviews. These will range across many different areas, but you can certainly expect a few of the following types of questions:

• Strategy (“should Google compete in market [X]?”)
• Design (“design an elevator for blind people”)
• Analytics (“how much revenue does company [X] make”?)
• Technical (“how would you design an algorithm to detect duplicate calendar invites.”)

The variances in questions are huge. Your temptation will be to try to prepare by answering a million different questions and getting to the right answer. This is counterproductive.

The real challenge will be structuring your answers

In my opinion, the secret to succeeding in the interviews lies outside of the realm of whether your answer is correct or not. Instead, you should focus on delivery of your answer.

What is your interviewer trying to assess? What is your interviewer likely NOT interested in assessing? Here some things I think are most important, but note that each interviewer and role may be slightly different. However, IMHO, these are directionally correct.

Interested in assessing	Likely NOT a focus
What’s your thought process when breaking down a fuzzy problem?	Do you get to the ‘right’ answer to my question?
How do you approach a very challenging design question?	Do you come up with the best ideas right in the spot, within a 20 minutes interview?
What’s your collaboration approach when working with engineering?	Can you code? (typically)
How do you balance long term vision with short term needs?	Can you be the next Google CEO?
Do you understand technical challenges that a proposed solution may have?	Can you design the best technical implementation for a problem?

Given that, focus your preparation on how you will communicate and how you will structure your answers.

The worst thing that you can do is to give an answer to an ambiguous question without walking through your thought process on how you arrived at the answer.

The interview is not about getting the right answer, the interview is an opportunity for you to show how you get to that answer and your thought process.

Build your own framework

There are plenty of frameworks to structure your answer. Often cited is the CIRCLES method for design questions. I’d suggest that you read through a few frameworks and build your own. Here are the core items that I think are crucial for your success.

Understand the real problem: the question you are asked will likely be ambiguous. Don’t try to answer right away. Think about ways in which you can clarify and make sure you understand the question in detail. Also, understand the goal. What are you trying to accomplish? What are the constraints that you have? What should you consider as ‘in scope’ or within the realm of possibilities for your solution?

Question: “How would you improve Google Search?”

Are we trying to improve revenue? UX? Increase daily users? Repeating visitors? Are we focused on the Desktop version of Google.com? Mobile? Google Home assistant? Is it in ranking the top results? Or on giving answers within the page itself? Or are we focused on improving the ads experience? How much budget do we have for the solution? Is there a particular cost revenue/cost target?

There are a gazillion questions you can ask to narrow down the problem. I’d ask a few of the more crucial ones that will allow you to focus on what matters and understand the goal. If your interviewer readily engages with you in providing additional information, great, keep going. If not, take that as a sign that they expect you to make reasonable assumptions and explain them as you work through the problem.

Structure your solution: Think of how you will solve the problem. Sketch out your solutioning approach. Think of the core elements of how you’ll approach it. If this is a product question, map out the user journey and identify key pain points. Identify your various user personas and how you will prioritize one vs. the other. For technical questions, think of the various alternatives you can think of. Think of complexity of your implementation — what data is needed? Cost of keeping up the feature? Think of privacy concerns.

At this point, you want to set the overall way you will tackle the problem, you are not yet answering the question or solving the problem.

At this stage, you want to present how you will tackle the problem to your interviewer and get feedback. For example, you could say:

To figure out how I’d improve Google Search, I’ll first pick a user segment that I think it’s crucial. I’ll then map out their objectives and key pain points when accomplishing that goal. I’ll then propose a solution that will tackle the key pain points and discuss some alternatives I can think of. Once we agree on a solution, I am happy to discuss the implementation approach I will take.

First, however, I want to clearly establish the goal we are going after, which is X. Knowing that X is our goal will help us narrow down to the right user segments and problem types to solve.

I’d strongly encourage you to write down your framework on a large piece of blank/white paper as you’re talking through it and write down the core pieces of your solution (pain points, user personas, core constraints, etc.) and refer back to it as you work through the solution.

Your goal at this stage is to be structured. Remember, you’ll have 10-20 minutes to walk through your solution and you don’t want to be all over the place. A structure is crucial for this.

Propose an option and an alternative: here is where you work through your framework, as you’ve explained it in the last step. You’ll actually identify a persona, identify use cases and user flows, identify unmet pain points, etc.

The core things that I’d stress about this stage is that it’s crucial that you communicate clearly.

• Don’t just jump through to a solution. Instead, talk about how you’ve arrived at that solution.
• Don’t simply say “I’m going to assume X”. Why do you think X is a good assumption. How would you validate or double check in the future if X is, indeed, a good assumption. If there isn’t a way you can think of to validate X, how will you test for it or minimize the risk of getting it wrong?
• Write down key reasons why a particular part of your solution may be difficult to accomplish. Discuss (and write down!) ideas about alternatives you may consider to mitigate some of those difficulties.

Evaluate the pros/cons of your solution. Consider the components of an ROI here. What are the costs, complexities, and risks of your solution? What are the potential benefits? How do you get the most of the latter while minimizing the former?

Talk about implementation & potential complexities and challenges. Time permitting, discuss how you’d implement a solution. If this is a technical interview, pseudocode may be great at this stage, or a general framework of the algorithm component, data sources, etc. that you’d tap into. If a design question, consider sketching out a solution / design or writing down Critical User Journeys and key requirements. Call out complexities of the solution. If it is a strategic question, get tactical about how you’ll implement it. How will you go to market? What parts of your strategy would you implement in the short term, medium term, long term (draw out a roadmap!). How will you mitigate key risks in personnel, execution complexity, costs, PR, etc?

Finally, wrap it all up by discussing next steps. Refer back to your pain points. Discuss, how have you solved the pain points? How have you solved the problem? Moving forward, how will you measure and make sure that your solution works? What will you measure to determine whether you should continue to go down the path you’ve outlined or you need to pivot? What signs will you get that your solution or proposal is good? How will you validate key risks you outlined previously.

How to practice

The above was a very long way to explain what you should be focused on when preparing for your interviews. I focused on the above since I don’t believe it is productive for you to focus on fundamentally acquiring new skills or knowledge you are completely unfamiliar with to pass the interviews. The interview questions are complex and varied enough that such preparation will likely yield OK but uninspiring answers. Instead, prior to an interview focus on what may actually get you from OK answers to an excellent discussion with your interviewer. Focus on what can get you to shine.

Practice with a friend. The best way to practice is to have a friend who has gone through the process practice with you. Ideally another product manager, since they’ll have a ton more context on what makes for a good answer.

Practice by recording yourself. In addition to practicing with a friend, record yourself using your phone/computer as you answer practice questions. Then play back the recording. This is way more helpful than people initially expect.

Review fundamentals. While I think that you’ll succeed mostly by capitalizing on your existing strengths, as you get stuck answering a sample question review the fundamentals behind it. If it’s a technical question, review the algorithm, data structure or infrastructure concepts that would have helped you. If it’s a design question, run through a few design frameworks that may have helped and tweak your overall response framework.

Get plenty of sleep! Personally, I perform 10x better at any task when I’ve gotten plenty of rest the two nights before. I suggest that you prioritize sleep over obsessively reviewing things in the last stretch before your interviews.

Don’t forget the soft stuff

I didn’t talk at all in this article about the soft questions, such as “why do you want to work in PM?” or “why Google?”. I also didn’t touch upon behavioral discussions such as “tell me about a time in which you faced difficulty, etc.” Be prepared to answer any of these, but don’t stress too much about it.

The only tip I’d give is to pick ahead of time a few projects or efforts that you’ve worked on in the past that show your diligence, ability to communicate cross-functionally, rise up when there’s a challenge, and collaborate well. Review your past accomplishments and challenges so that, if a question like that comes up, you have fresh in your mind a list of potential activities to talk about.

Closing Thoughts

I’ve seen incredibly talented people not get a job offer after going through the Google PM interview process. The process is optimized to minimize false positives, that is, sometimes even if a candidate seems ‘good’ they may not get an offer if the hiring committee has doubts. Some of these folks that don’t get an offer in the first try interview again, usually 1+ years later, and do get an offer, so make sure you keep that option in mind.

FAQ

Do I need to code during the technical interview? 

While there’s no hard rule I have read about online, for PMs the focus should be in demonstrating:

• That you recognize technical challenges and scalable vs. non-scalable solutions
• Can smartly talk through how you’d design an algorithm/solution to a problem
• Understand data structure and internet infrastructure fundamentals

I haven’t heard about PMs being asked to code during interviews, although pseudocode does seem to come up.

Other resources

Cracking the PM Interview*: best ~$15 I spent when preparing.

Thepminterview.com: specifically their Estimations, Product Design and Strategy questions.

My article on Google interview process: for a general overview of the process.

Update: this article is now also available as a Google Doc (link) so you can easily add comments and help us improve it.

* Note: I use some affiliate links in this post, marked with an asterisk. If you click through and purchase products I earn a small referral fee at no cost to you.

I was recently reflecting on the following quote

Don’t ask yourself what the world needs; ask yourself what makes you come alive. And then go do that. Because what the world needs is people who have come alive.

Howard Thurman

The first thing that came to my mind was, languages. I’ve had some of the richest experiences by being able to communicate with people in their native language. For example, traveling around Japan in 2009. I want to continue having such experiences.

It takes a very long time and effort to get to fluency in a language. The rewards, however, are immense.

If you talk to a man in a language he understands, that goes to his head. If you talk to him in his language, that goes to his heart.

Nelson Mandela

Language is a strong unifying force, and when two people speak the same language, it helps them build bridges, build rapport, and accomplish much more than we can imagine.

What does this means for product management?

Someone recently asked, as a Product Manager do you ever find ourselves wanting to learn more about design?

My answer, unsurprisingly after this preamble, is “absolutely, 100% yes.”

As a product manager, you are trying to speak many languages on a daily basis. The language of marketing, the language of engineering, the language of design, the language of partnerships. You bounce from team to team and, as you do so, you translate ideas, thoughts and feelings from one language to the other. The success of your product depends in large part on your ability to coherently bring these ideas together into a coherent strategy.

You will never become quite as fluent in any of those languages as your counterparts who are immersed in that discipline. Languages rapidly evolve and your colleagues will be fully immersed in the latest slang for their group, while you’ll dabble in it for a few hours here and there. However, to the extent possible, try to speak to your counterparts heart by speaking their language. And never stop learning about the various disciplines’ languages.

One caveat: remain humble. Don’t lose sight of where your limits are. When having a difference in opinion about design with someone who’s much more fluent than you in design, be careful not to overly push your point of view simply because you’ve passed the beginner phase in design knowledge. Propose ideas and explore alternatives together. When at an impasse, suggest getting additional input from users and/or other team members. Resist the urge of contributing too much to disciplines outside of your core language. For engineers turned into PMs, don’t try to dictate your engineering team’s technical design when writing your PRD.

Your core language

There is one language in which you should have primary command of and hone the most: the language of storytelling.

Human beings are able to organize and accomplish amazing things when they all believe in a story that is worth pursuing. You should work the hardest at figuring out why is it that your product matters and tell that story. What will the future look like with your great product initiative implemented? How will your users benefit? Tell that story day after day.

Everyone should understand that picture. Everyone in your team should be able to listen to it, understand why it matters, and be inspired to show up every day to help make that vision into reality.

As a PM, that’s your primary job. It is also your responsibility to drive towards the accomplishment of that vision by doing whatever you can to contribute to the story, as a core believer and participant in it.

Continuously refine the story as the world around you changes, your users change and your product evolves. Don’t forget to evolve your product story, or soon you will find yourself driving towards a vision that’s no longer needed in the world. You will be driving towards irrelevance.

Lastly, you should build an instinct for how your users will react to your product. Speak their language as much as possible and represent your users in your daily conversations. And remember, not all of your users speak the same language, so learn more and more about their language as you go and represent them throughout your company in all of your meetings.

Bringing it all together

I consider communication a PM’s superpower. As someone often seeking to drive initiatives forward through influence rather than authority, having a compelling story to tell and being able to distill it and translate it into what matters most to different audiences is crucial.

Time spent honing a compelling story, figuring out how to best communicate it, translating it for your various audiences, refining it, and lastly driving towards accomplishing it, is never wasted time.

Do this, and allow your teams to contribute their talents and skills towards helping you refine and accomplish that great story, and you’ll delight your users with a great product only a great story could have inspired.

I always remember a song I heard as a child by Guatemalan singer Ricardo Arjona. It said (with a profanity substituted) “aquí no es bueno el que ayuda, sino el que no [molesta], acuérdese.” This translates to “here the good are not those who help, but those who don’t [bother], remember that.”

Having recently completed my first 3 months as a PM at Google, I’d say that this is good advice to keep in mind in the beginning of a new job. Instead of having a grandiose plan to make a big difference and impact, start by learning as much as you can without disturbing others.

Here are the things that I’d keep in mind as you ramp up on a new product or team.

Admit that you’re in a learning phase

As a new PM to an existing product, your focus must be in learning. Even when there is an improvement that seems obvious to you, a product idea or process tweak, you should abstain from trying to make your ‘quick win’ or contribution too hastily.

Consider that:

• You lack context. Your new colleagues have been working on the product area for months, maybe years. They have tried many ideas that failed, talked to many customers, and learned a lot in the process. Try to gain that context quickly.
• You have zero reputation. You can only go far if your team actually cares about what you have to say. You can quickly tarnish your reputation if you babble ideas or decisions before thoughtfully thinking through problems and considering all aspects of a problem.

So, focus on learning. How do you get started? Instead of trying to revolutionize the team’s dynamic, I suggest that you pick a small project or initiative and use that to prove yourself.

Picking up a few small initiatives

The most important thing I’ve done while ramping up on a new product or area has always been to dive in and pick up a small, non-critical project. It doesn’t matter how small or uninspiring the project might be. What matters is that it is an initiative with the various phases that a typical project will go through.

Your goal is not to amaze everyone by how well you did on this first project. Your goal is to maximize learning by getting through a full cycle of contribution. You will learn many of the quirks of working with your new team.

Going through a small initiative end-to-end will help you figure out the many tactical things that will later on make you much more productive:

• What template should you use to write product requirements?
• Who should you consult in the process?
• How do you communicate impacts to other teams?
• How do you break down your requirements into stories? Where do you file bugs?
• Will you have help from other teams (design, eng, user research, etc.)? If so, how much?
• How often do you need your manager’s input while working through the initiative?
• Do you need to get approvals or reviews by other teams? Which ones?

Going through the process will help you see gaps in knowledge that prevent you from moving a project forward. Try to maximize the number of times you go through this cycle in your first few months by picking many small, tiny initiatives and owning them. It doesn’t matter if the initiative is ultimately built or makes a big difference.

As you go through the initiatives, just remember that you’re trying to learn, so look for learning opportunities. As why things are the way they are, but don’t try to offer solutions or change things. What you’re looking for is opportunities to learn what’s effective and to tune yourself to make a bigger contribution within your team’s established processes.

Which brings me to my next point.

Tweak your habits, not your team’s process.

It is easy to look at any process and find ways to improve it. There’s a reason that’s the case, most processes just need to be ‘good enough’ to allow the team to work effectively. Constantly tweaking processes so they are ‘better’ is often more distracting than it is worth.

As such, instead of trying to change how your team does things, first accept their processes and tools and use them. Give them a genuine try and, as you do so, observe the pros and cons of sticking with them. Often I’ve seen new PMs reject a team’s way of working, just to come around months later to admit that it’s the easiest ‘quick and dirty’ way to get it done and not worth changing. Prioritizing using a simple Google Doc may feel inefficient when all your requests are in JIRA (or some other tool), but if that’s what your team does, try it out.

Unless something is an impending disaster, wait a few months before trying to change existing team tools and processes.

If and when you do try to change something, make sure it’s something that is worth trying to change. It must be a pain point that’s frequently observed and big. Also, since your change may fail, look for solution that is easily reversible if it doesn’t work out for your team.

Meeting your team

You will need a lot of help over the coming months and years from the people you are meeting now. Meet them as people. Try to learn about their personalities, what they are interested in, what they like and dislike about their job.

You will soon find yourself in meetings and discussions where decisions will be made that will impact the work your team does. You may be working with the engineering lead to decide how to distribute work among the team. Or in a meeting where an initiative is about to get killed or swapped by another one. Knowing your team will help you weigh their feelings and likes/dislikes into the process. It may not change the outcome, but it can surely help you make the process smoother for everyone and provide the right amount of context.

One thing I like to do when meeting people for the first time is to let them know that I’m here to help. “I don’t know anything right now, but if there’s something that you think I can be helpful on, just let me know.” It’s simple, recognizing that you are unlikely to be helpful, but shows your willingness to step up and assist others.

Remember, you’re a PM. You’re not the CEO of your product. You are not here to issue commands or speak of visions for the team to execute. You probably won’t be hiring or firing anyone. You’re here to collaborate with your team to come up with a direction that will make the product awesome. You should be very involved and willing to help your team’s life easier. Make it clear to them that you’re here to do that.

Ask your manager and coworkers for ‘braindumps’

When ramping up, my manager and I lovingly started to use the term ‘braindumps’ for many of our conversations or exchanges. These would be sessions in which she would give me a ton of information and context and I’d just soak it all up while asking clarifying questions. These sessions would be unstructured and we would often jump from one topic to the next.

The idea during these sessions was to surface all sorts of information that may be helpful later. Information such as:

• How does the product work?
• How does the product initiative fit within the overall product and company strategy?
• What are the known issues with a given feature?
• Why hasn’t an important issue been fixed?
• Why do these two parts of the product feel so disjointed?
• What did the team try and succeeded with? How did they start down that path?
• Who are the players involved in making your product area a success?

Keep these sessions flexible. They are best in person, but often we’d do these asynchronously by using a Google Doc. My manager would type up a bunch of thoughts about an area or topic I needed context around. We’d then discuss.

During these braindump discussions you will have many ideas, thoughts, and potential solutions. Don’t jump into looking for solutions. Remain focused on surfacing issues and tidbits of knowledge.

What you’re after is building a foundation of knowledge around the team and product. At first, all the information that you’ll gather will be in a disarray. That’s OK. You will then take time on your own to organize all this new information in a way that’s useful to you. As you do, try to explain in your own words the things that you’ve learned. Ask “why” until you’ve hit on a point that is easily understandable and actionable.

For example, consider that your note says that your product feature A has stability issues. Ask why? Is it due to a component of the system that it leverages? If so, what are your options to rewrite/substitute/improve that component? How much effort would it take? Why hasn’t it been done? Processing your notes from your braindumps, asking why, and finding the answer to those questions should take several times longer than the braindumps themselves.

The biggest benefit I find of getting ‘braindumps’ from co-workers is that they will naturally gravitate towards talking about things that are currently or were recently relevant to them and the rest of the team. This will make your learning process more focused, since you will quickly uncover the substance of the various discussions that your team has been having over the past 6-12 months, which will allow you to more easily understand what’s going on as you join team meetings and work on new initiatives. This is much more helpful than reading an internal documentation portal with information that hasn’t been updated in 3 years because no one cares about that topic any longer.

Observe your users

I could, and probably will at some point, write an entire article about the importance of getting first-hand exposure to your users. You can learn a lot from talking to your coworkers. But, ultimately, your goal is to build a product for your users. Deeply empathise with those users. Observe them. Talk to them. Find ways to watch them in action. The more you can identify with your users and understand their real goals and needs, the better of a product that you’ll be able to build.

Bringing it all together

Your first few months as a PM can be quite unsettling. You are brand new, want to make a contribution, may have a lot of relevant experience to bring to the table, yet have little to no knowledge or context about your new team and product area. There are major gaps in your understanding that will prevent you from making a large contribution. Thus, focus on learning by picking up many small initiatives, assimilating your team’s processes and tools, asking your co-workers for braindumps, digging deep into the ‘why’ behind what you’re told, and observing your users. After a few months consistently doing this you’ll be ready to take on larger initiatives and will be much more effective at helping your team.