Root cause analysis interview questions for product managers

A metric dropped and the panel wants to know why. Below are 27 practice cases, the method most PM panels expect, and the cuts that usually crack the problem. Each case can be practised as a free mock interview.

What the round tests

Root cause analysis (RCA) questions give you a vague symptom, such as orders down 12% or success rate down four points, and hold the data back until you ask for it. The panel is watching whether you narrow the problem in a sensible order, whether every question you ask has a reason, and whether you can prove the cause instead of naming the first plausible story. Most candidates know the facts they need. They lose points by guessing early, asking for data in a random order, or stopping at "what" without the mechanism and the fix.

The method, step by step

1. Clarify the metric: how it's defined, since when, sudden or gradual, where, and whether the data has been checked.
2. Break the metric into a tree before asking for any data, for example orders = users × sessions per user × conversion.
3. Rank where you'll look first and say why: the top of the tree, then the broken step, then segments such as platform, app version, region and user type.
4. Ask what launched or changed around the start date.
5. Prove the cause with a fair comparison: same place, same time, only the change differs.
6. Explain the mechanism and size the impact out loud.
7. Close with the cause, proof, impact, fix, success metric, guardrail and trade-off.

Start with a metric tree

Write the metric as a product or sum of parts before you ask for a single number. Orders can be users × sessions per user × conversion; a success rate is successes ÷ attempts, so check both the top and the bottom; an average like watch time per user can move because the numerator fell or because the denominator grew. The tree tells you which number to ask for first and turns "why did it drop?" into "which part moved?".

Cuts worth making, and why

• Platform and app version: a release that reached some users but not others is one of the fastest ways to find a cause.
• Region or city: operational problems (supply, delivery partners, local competitors) are usually local.
• User cohort: new versus existing users separates a change in who is using the product from a change in how it works.
• Funnel step or entry point: find the one step that leaks, then cut only that step further.
• Time of day and reason codes: peaks and failure reasons often point straight at the mechanism.

Pick the order out loud and say what each result rules in or out before asking for the next one.

A worked example answer

The question: "Repeat orders fell from 41% to 37% of last month's buyers. Find out why." (Practice scenario; the company and numbers are made up.)

1. Clarify. Repeat rate = buyers last month who ordered again this month. The drop happened over four weeks, not overnight. The data has been checked, there's no sale or holiday in either month, and it's all cities.
2. Tree. Repeat rate = share of last month's buyers who came back to the app × share of those who ordered again. Return visits are flat, so the leak is in re-ordering.
3. Rank the cuts. City first, because operations differ by city; then first-order experience (late, cancelled, refunded), because a bad first order is the usual reason buyers don't return; then category and app version. Saying why each cut comes next is half the marks.
4. Read the data. Six cities account for almost all of the drop. In those cities, the share of first orders that arrived late went from 12% to 30%. Buyers whose first order was on time re-order at 44%; buyers whose first order was late re-order at 22%. Check: 0.70 × 44% + 0.30 × 22% ≈ 37%, and 0.88 × 44% + 0.12 × 22% ≈ 41%.
5. What changed? Five weeks ago, those six cities moved to a cheaper delivery partner.
6. Prove it. The cities still on the old partner are the control: same weeks, same app, same prices. Their late share stayed at 11% and their repeat rate at 41%. Only the partner differs.
7. Mechanism. The new partner batches more orders per trip, so first deliveries arrive late. A first-time buyer who waits forgets the app or tries a competitor, so the damage shows up a month later as lost repeat orders.
8. Size it. With 400,000 buyers a month, four points is about 16,000 fewer repeat buyers a month. At one order of ₹350 each, that's about ₹56 lakh of monthly sales, recurring, against the per-order saving from the cheaper partner.
9. Close. "Repeat orders fell because late first deliveries more than doubled after the partner switch in six cities; the old-partner cities prove it. I'd route first orders to the old partner now and hold the new partner to an on-time SLA. Success metric: repeat rate of first-time buyers. Guardrail: delivery cost per order. Trade-off: we give back part of the saving to protect retention."

Proving the cause

Timing alone is not proof. A strong answer finds a fair comparison: a holdout group that didn't get the change, users still on the old app version, regions on the old partner, or the same users on a different path. Same place, same time, only the change differs. Then explain the mechanism in one or two sentences, size the impact in money or users, and close with the fix, the metric you'd watch, a guardrail and the trade-off.

See all 57 product manager interview questions