PM Quest learning library

How to Approach Root Cause Analysis Cases

A practical guide to approaching root cause analysis PM cases.

Root Cause Analysis Cases

A Product Manager, especially in a data-driven B2C startup, spends a significant amount of their time investigating why metrics go down or spike unexpectedly. Being able to reach the root cause of a problem is an essential PM skill.

A typical example of a product analytics case is: "Imagine you are a PM at Ola and there's been a 20% increase in ride cancellations. What would you do about this?"

These cases often work in a "role-play" style. You ask questions about the context of the problem, the product, and any relevant metrics. Using the information you gather, you'll iterate through increasingly precise hypotheses until you identify a root cause.

What good product thinking looks like

Your ultimate goal is to identify the root cause, but the most important signal is your approach. RCA cases are different from product design cases in that they do have a correct answer, but a logical approach still matters even if you don't nail the exact solution.

Strong RCA cases test whether you can:

  1. Make sense of ambiguity - Turn a vague situation into a solvable problem
  2. Generate hypotheses - Come up with reasonable and testable explanations
  3. Gather information iteratively - Ask for the right data at the right time
  4. Think structurally - Communicate your thought process logically

The RCA Framework

RCA cases are typically designed to be worked through in 25 minutes. Follow this process:

  1. Clarify and gather context

    • Break down the problem into keywords (What is "ride"? What does "decreased" mean?)
    • Understand the metric being used and what it signifies
    • Determine the nature of the change - is it sudden, gradual, seasonal, or recurring?
    • Ask about customer segmentation - are specific platforms or user segments affected more?
    • Don't ask more than 2-3 clarifying questions. Be prepared to answer your own.
  2. Form high-level hypotheses using MECE

    MECE (Mutually Exclusive, Collectively Exhaustive) helps you cover all bases. The 4 major categories:

    • System - Metric logging errors, calculation changes, pixel/tracking issues
    • External - Competitors, market trends, seasonality, demographics, external platforms (Google, Facebook)
    • Internal - New features, UI/UX changes, product cannibalization, bugs, device-specific issues
    • Out of Control - Political changes, natural disasters
  3. Gather data

    • Ask for specific data points to test each hypothesis
    • Be concrete: "Can I see the drop-off rate at the payment screen before and after the change?"
    • Strong PMs ask for actionable data, not vague requests
  4. Refine hypotheses and repeat

    • Based on the data, eliminate unlikely causes and dig deeper into promising ones
    • Narrow down systematically until you reach the root cause
  5. Identify the root cause

    • State your conclusion clearly with supporting evidence
    • Tie it back to the data you gathered
  6. Propose next steps

    • Suggest how to validate your finding (heatmaps, user feedback, A/B tests)
    • Recommend potential solutions if time permits

Tips for Success

  1. Keep the interviewer informed - Narrate your thought process as you go
  2. Don't jump to conclusions - Check system and external factors first before diving into internal changes
  3. Be specific with data requests - Ask for conversion rates, drop-off by funnel stage, device/platform breakdowns
  4. Connect everything to the user journey - Map out the user flow and identify where issues might occur
  5. Stay structured - Use MECE to ensure you don't miss important categories

Sample Cases

RCA cases usually have a cause the interviewer wants you to uncover. A structured approach matters because it helps you reach that cause efficiently rather than guessing.

A concise answer structure

First validate the metric definition and instrumentation. Establish the baseline, size, start time, duration, and whether the change is sudden or gradual. Segment by platform, geography, user lifecycle, acquisition source, and funnel stage to localize the movement. Then build hypotheses across data quality, internal product or operational changes, and external conditions.

Ask for one discriminating data point at a time and say how each possible answer changes your next branch. Once evidence supports a cause, summarize it, propose an immediate containment step, a durable fix, and monitoring that would confirm recovery. Do not propose solutions before the problem is localized.