(Really) Cracking The Product Manager Interview by Gojek PM

Bridging the gap between theory and practise

Disclaimer: Views expressed here are my personal thoughts.

Anyone who has interviewed Product Managers (PMs) or interviewed for PM roles would tell you that it’s a pretty crazy role to interview for.

You’re expected to be good at a lot of different things and at the same time, you are expected to influence a team of people where everyone is better at their respective functions than you are.

You are expected to ship software even though you can’t write code as well as your engineers can; you are expected to guide the design process even though you can’t play around with pixels as well as your designers do.

You are expected to act as a leader to these teams even though they technically do not report to you.

Why this blog post?

I recently started a new role as a Product Manager. As I made the leap to product management from being a founder, I went through a set of interviews — some of which worked out and some of which didn’t.

Like anything in life, I learned from the ones that didn’t work and built a set of frameworks that helped me do well in the interviews that mattered.

As I went through this process, I realized that most of the resources around preparing for PM interviews available online, are fairly shallow.

In fact, most of them are really crappy (does the CIRCLES framework really work?). I want to call out Cracking the PM Interview by Gayle Laakmann as an exception because it really is a good book.

That said, I still found it pretty shallow when it comes to areas like Product Design and Data (although it was really helpful in Strategy).

So, I decided to publish a list of missing things I wish someone told me when I was preparing for the interviews.

I also decided to write about this because PM interviews seem fuzzy and daunting at first sight — you’re often told even during interviews that there is no right answer to a question. The set of things mentioned in this post hopefully provide a structure that reduces this fuzziness a little.

In a typical PM interview, you are evaluated on the following areas:

Hard skills

• Product design
• Product improvement
• Product / Business strategy
• Data and metrics
• Engineering

Soft skills

• Communication
• Behavioural questions
• Leadership qualities

Cracking the PM Interview covers the soft skills and product strategy parts pretty well — so I won’t delve deep into it. In this (rather long) post, I will try expanding on how to answer

• Product Design
• Product Improvement
• Data / Metrics
• Problem solving / Root cause analysis

For now, I have fleshed out Product Design; will update this post with Product Improvement and Data/Metrics frameworks soon.

(If you are interviewing for a relatively junior role, Strategy rounds may not be present but I have heard that FAANG companies typically focus on Strategy regardless of level of seniority)

Who should read this

You should read this if:

• You are thinking about applying to Product Management roles at top startups (yeah, the job environment. I know. But still.)
• You have crossed the resume filter in the recruitment lifecycle (the typical PM hiring process goes like Resume filter → Phone interview with hiring manager → 3–5 rounds of onsite interviews → dedicated culture fit rounds (in some companies) → bar raiser round (in some companies) → offer)

A note on soft skills

While the hard skills are important, I have seen that many people screw up the soft skills part. This is an unforced error.

Cracking the PM Interview has a set of good tips on how to answer the standard “Tell me about yourself”, “Tell me about a time when…”, “Why this role” kind of questions.

In fact, regardless of the role you are interviewing for, these questions are important and having structured answers for these can come in handy.

A mistake that I see most people make here is relying on just bullets or ‘ideas in their head’ to answer these. That doesn’t work.

You need to write down the entire answers to these questions and rehearse them so that you don’t have to think during the interview itself. I also recommend recording yourself answering these questions and playing them back so that you don’t sound too robotic.

Fun fact — I rehearsed my “Tell me about yourself” about 40 times.

Here are some items that I had fleshed out, written answers to:

• Tell me about yourself
• Why a PM role
• Why this company
• What makes (you) a good PM
• What makes (you) a bad PM

No matter your answers to these questions or your proficiency in communication, do not wing this.

Product Design

Regardless of the level of seniority you are applying for, a PM interview has a product design round. This round is to suss out how you think about products and whether you can structure your answer in a coherent way without going into tangents.

There are a number of frameworks online (like the famous CIRCLES method) but none of them worked for me, so I generated a structure for myself (of course, it’s loosely tied to how the CIRCLES method looks like, but the questions are more specific) — so instead of CIRCLES, it became CIDALDOSI (should ™️ this 😛).

In any product design question, I try to do the following:

• Clarify assumptions — always
• Identify users and user segments
• Describe the user journey, if applicable
• Assess user needs and pain points
• List current solutions
• Describe shortcomings of current solutions
• Order needs and pain points by priority
• Solve 3–5 pain points and prioritize solutions
• Identify metrics to track

This might sound too abstract — so I will try to answer this with an example. Let’s say the question is to Design a parking lot for the future. (If this sounds too esoteric, just wait till you see some of Google’s product questions).

You can find the answer to the question using this framework here.

Product Improvement

Although they seem to be lesser asked these days — with interviews turning in favour of product design questions — product improvement questions are still asked. Usually, it takes the form of a follow-up question to the “What’s your favourite product?” question.

As many blog posts note, candidates screw up this questions by mostly rambling about incremental improvements without focusing on a coherent, structured answer.

The framework I use to answer the product improvement question is as follows:

• Describe the product.
• Identify categories of users for the product.
• Define business objective for the product.
• Select one user segment from the category you picked.
• Identify problems faced by those users.
• Map the user journey.
• List possible solutions and touchpoints for problems.
• Prioritize the solutions (I use RICE here).
• Identify metrics to measure improvements.

As with the product design question, let me try to explain this with an example. Let’s say the question is — How would you improve Instagram? — our answer using the above framework could be as described here.

Product Metrics

Product Metrics questions are a definite feature of any product management interview. People want to assess if you can think in terms of data and numbers.

What they are looking for is not a laundry list of metrics but a neat, concise set of numbers that you as a product manager will be watching on a daily basis, to understand how your product is doing.

This is honestly one of the easiest questions to answer but also pretty easy to screw up if you end up going on a tangent or dive too deep into a metric rabbit hole unnecessarily.

The framework I use to answer this question is as follows:

• Define the product in 1 or 2 sentences.
• As a Product person on this product, what would be your main objectives?
• What does the user journey look like?
• What are the list of metrics that you could potentially track (and the time window)?
• What is your focus metric? (You should have just 1 focus metric)
• What are your L1 metrics — metrics that are important and tie back to the focus metric? (You can have 4–5 L1 metrics)
• What are your L2 metrics — metrics that are good to monitor? (You can have up to 8 L2 metrics)
• Summarize your answer with Focus and L1 metrics.

Continuing with our Instagram example, let’s say we want to define the top metrics for Instagram. We can use the framework mentioned above to answer the question as described here.

Problem Solving / Root Cause Analysis

As a product manager, you will often have a crisis to solve — your internal dashboard at Uber shows a dip in number of active rides, your internal dashboard at Amazon is showing that product returns are spiking — your job is to quickly get to the root of the problem by digging deeper.

But these are complex systems and so interviewers want to assess whether you can approach the problem in a structured fashion. Root cause analysis problems are usually structured as a follow-up to the metrics question — interviewers typically ask “OK, we know that <metric> has <changed>.

Can you figure out what happened?” This is a bit of a wild goose chase as the interviewer has an answer in mind and wants you to work towards it, but there’s a way to approach it systemically.

The framework I use to approach these questions is as follows:

Make sure you understand how the metric is measured

Eliminate the obvious

• Is the data source accurate or known to have issues?
• Was the change in metric sudden or gradual over time?
• When did the change start — and is the change seasonal (does it happen every once in a while)

Narrow down your scope

• Is it happening in a specific geo, platform, or some other narrow cohort?

Articulate the system and find what changed (change is most likely in one of the following)

• The product — backend, frontend, apps, etc.
• The business — marketing, pricing, legal, etc.
• The users — suppliers, consumers, etc.
• The environment — competition, regulation, disasters, etc.
• Other elements in the system

Identify root cause and prescribe solution.

This framework might seem a bit ambiguous (it is) and a single question has any number of paths that can lead to any number of answers — it really is at the whim of the interviewer, but by following a skeleton structure, you can avoid going around in circles and make sure that you are not caught in a rabbit hole.

Let’s say you were asked a question like “We know that number of rides with surge on Uber is usually at 30% but it is at 70% now. What could be the reason?”

There could be any number of answers to that question — but using the framework above, we have arrived at one such root cause here.

Closing notes

Preparing for a product management interview can be scary given the ambiguous nature of questions, but I hope the frameworks mentioned above help! Good luck with your interviewers.

You can learn more about Gokul on his blog.

If you're looking for help in cracking Product Management interviews, you can book a practice interview session with Gokul on our Preppa platform. Gokul provides detailed and personalized feedback after conducting a 60 minutes of mock interview.