A Simpler Approach to Product Management Case Interviews

After a setback six months ago during internship recruitment, I successfully recruited for a Google PM role this year. One of the critical aspects of the interviewing process at Google is product case interviews.

Personally, I'm not a big fan of the case interview frameworks. In the real interview, sticking to these frameworks when bombarded with pointed cross-questions seems forced and robotic. Instead, over time, I have come to rely more on design thinking frameworks and real-life problem-solving skills to approach casing. I am writing this to share my somewhat different approach to PM case interviews.

I will share five learnings that helped me improve my casing skills:

1. Solve like a real-life problem

Setting a clear goal for the product and the timeline at the start is critical. Any change in goal or timeline could have a huge impact on the kind of customer segment, problem and solution we come up with in later stages.

Goal: Some examples of goals include gain market share, increase engagement, increase repeat customers, increase referrals, etc. It is also a good idea to decide what would be your success metric.
Launch Date: within a year, 2–3 years or 10 years (futuristic). If the launch date is more than 2–3 years out, then we are expected to come up with more 10X kind of solutions.

To define goals and metrics, I love Google's HEART frameworks. It helps in deciding what should be the goal of the product. Before I started using this tool, I used to get stuck with just engagement or adoption as goals, which seemed forced.

HEART stands for Happiness, Engagement, Adoption, Retention and Task success.

It's also crucial to ask clarifying questions and not rush to tick buckets. One of the popular abstract questions I came across during my prep was: "Google has built mood-tracking API. How would you design a product using it?"

Here are some of my probing questions to understand this topic:

Is it applicable to all living things or just humans or just animals? (Interviewer: Animals only.)
Is the result an accurate emotion or some bucketed scale, for example, angry, happy or sad? (Interviewer: 1–20 scale where each point corresponds to a different type of emotion.)
What's the latency in getting in the result? Do we get the mood in real time or after days? (Interviewer: 1-second lag. )
What's the cost per API call? Is there any device required for making this call at our end and the animal's end? (Interviewer: Central device cost is USD 10 million, but it's a sunk cost. Every animal will require a tagging device, which costs $1,000.)

2. Customer — problem — solution

At the core, you have to figure a specific solution for a specific problem for a specific customer segment. Every other part of casing, whether suggesting metrics for success or talking about trade-off, is a dispensable piece.

Often, we propose a pretty creative solution, but it doesn't solve the problem we have highlighted. As case interviews are often used to test analytical and logical skills, making such logical errors could put us at a disadvantage.

While traversing from customer to problem to solution, please keep the following in mind:

Keep customer, solution and problem space distinct: For example, mixing problem and solution space don't only confuse your interviewer, it also constrains your solutions. It's one of the key lessons of the Lean Product Playbook by Dan Olsen. You can read my summary of the book here.
Come up with a clear problem statement: After identifying and prioritizing the problem, it's important to come up with a clear "How might we" statement before jumping to a solution. This statement will bring clarity to both you and your interviewer as to what you are solving. Refer to Google's design thinking material to solidify this concept.

For example, in the case of redesigning Woebot: Let's say I decided to target refugees. Then after analyzing and prioritizing problems, my final HMW statement could be something such as, "How might we help refugees cope with post-traumatic stress disorder by helping them track their emotions?"

3. Go broad to go narrow

I learned this design thinking concept during a workshop conducted by Intuit's product management team on campus. At each step of the process in product design, enumerate options, then prioritize these options to select one.

First, mention three customer segments, then pick one.
Second, highlight three problems associated with the identified customer segment, then pick one.
Finally, enumerate three solutions for identified problems in the previous step, then pick one.

Ideally, I try to mention three options at each stage. (Rule of three: A trio of events or characters is more humorous, satisfying or effective than other numbers.)

Prioritization is one of the key skills of a product manager. Therefore, it's important to give a solid rationale for prioritizing.

4. Build a deep understanding of the customer

One of the key tenets of design thinking is customer empathy. Sometimes, we just do a lip service in the name of customer segmentation. For example, using age-based (Millennials, adults, senior citizens) or job-based (CXOs, working professionals, students) in all product cases isn't right. Choosing the right customer segment helps a lot in coming up with interesting insights and solutions.

For example, three customer segments for "Self-Driving Car for Blind" is:

Independent visually impaired person who isn't dependent on help or family member to assist.
Dependent visually impaired person who has a friend or family member who takes care of them all the time.
Situationally blind person. For example, on a dimly lit road, we all face situational blindness while getting into a car.

Other segments could be color-blind people or people with a problem in seeing far-off objects, but I believe highlighting three segments is often apt.

Also, it's important to be specific in describing these segments. It not only shows customer empathy but also helps in bringing deeper insights.

I often find describing the customer journey useful in figuring out the pain-point and insights about the customer. I used to imagine myself as a customer and describe the whole journey. This exercise is effective in empathizing with the customer.

For example, in the case of designing a self-driving car for the blind, I would close my eyes and try imagining the whole experience. I have to find my phone, then probably use "OK Google" to call the car, but then I would struggle in finding the car when it arrives, and so on. Similarly, if I am designing for kids, I would try imagining myself crawling to see from the perspective of someone with a lower height.

5. Offer variety in solution

One way to showcase creativity in a solution is to offer variety. If you have offered two software solutions, then offer one hardware solution. In general, offer three solutions in increasing order of complexity.

There is a notion prevalent in Google candidates I have spoken to that interviewers love crazy ideas (moonshot or 10X ideas). While it's more important to show customer empathy and solve the problem, I do believe there is an upside to giving stretched solutions at Google.

For example, here are solutions for tracking exercise:

Simplest solution: an app where users have to select the number of reps or time spent in doing particular kinds of exercise. Based on the input, app will calculate calories burned.
A medium-complexity solution: a mobile app that uses a camera to detect the kind of exercise using object detection algorithm (video action recognition) and accordingly logs the number of reps or time spent.
Futuristic solution: Maybe we design a "robo-trainer," which is available as a subscription service in the gyms. Similar to a treadmill, it helps you train and record exercise. When you approach this robo-trainer, it gets synced with your mobile app and starts performing exercises you have to repeat. It uses computer vision to track your movement and suggests improvements in the way you're doing exercises: Maybe your hand isn't at 45 degrees when doing certain exercises. In a way, this robo-trainer becomes your personalized fitness coach.

The variety shouldn't just be in the complexity of the solution, but in the medium of delivery of the solution.

I will solve a PM case question to walk through the concepts in my next post.

If you found this useful, you might want to checkout this course: A Simple Approach to Product Management Interviews.