Zomato PM Interview — Metro Cancellation Spike RCA

It tests whether you can run a disciplined marketplace investigation under interruption. The interviewer drops a 20 percent week-over-week spike in order cancellations in one Indian metro on you with no dashboard. They watch whether you define the cancellation metric and its window first, check if the move is a tracking artifact, segment by zone, cohort, restaurant and payment method before guessing, generate internal and external hypotheses, prioritise them by likelihood and impact, name the exact data pull that confirms or kills each one, and finish with a sequenced action plan and a way to measure it. Reciting a framework without adapting it to Zomato's three-sided India marketplace does not pass.

Start by clarifying what the cancellation metric means, its numerator and denominator, the exact time window, and the baseline being compared. Confirm the move is real and not an instrumentation or tracking change. Then segment the spike across city zone, new versus repeat customers, restaurant cohort, payment method, app version and order stage to localise it. Build a hypothesis set covering internal causes like a release or a fee change and external ones like weather or a competitor promo. Rank hypotheses by likelihood and business impact, and for each, say the one data cut you would request. Close with an immediate mitigation, a durable fix, and the success and guardrail metric you would back-test against.

The biggest is jumping to fixes before defining the metric and its baseline. Close behind is reasoning about the whole metro as one number with no segmentation, so the real driver stays hidden. Many candidates fixate on a single favourite cause and stop generating alternatives even when the interviewer pushes back. Others propose a hypothesis but cannot name the data pull or query that would confirm or eliminate it, so the analysis never converges. Finally, candidates often recommend an action with no success metric, no guardrail and no plan to verify the fix actually moved the cancellation rate.

The behaviour is modelled on reported Zomato PM rounds: it interrupts, pushes back hard, and demands you defend a hypothesis ranking and quantify impact before moving on. The difference is consistency and feedback. It never gives mid-interview praise and never hints at the outcome. It probes every claim for a baseline and a data check the same way each time. Afterwards you get a transcript-backed scorecard that names the specific moment a hypothesis lacked a validation step, instead of a vague rejection email days later.

Scoring is derived only from your transcript, never from tone or accent. The scorecard evaluates dimensions like how cleanly you defined the cancellation metric and baseline, whether you checked for a measurement artifact, the breadth and discipline of your segmentation, how you ranked hypotheses by likelihood and impact, whether you attached a concrete data pull to each hypothesis, and whether your recommendation had a measurable back-test. Multiple valid investigation paths score equally. You are scored on the structure and evidence of your reasoning, not on how polished your delivery sounds.

Do not start solving. Spend the opening exchange pinning down what is being measured: ask whether cancellation rate is cancelled orders over total orders, the exact comparison window, whether the 20 percent is relative or absolute, and whether it is one metro or platform-wide. Ask whether anything changed in instrumentation. Then ask for the first segmentation cut you want, by reason code or by zone, and explain why that cut first. Showing you separate a real behavioural shift from a tracking change before hypothesising is the single strongest opening signal.

Do not accept or reject it on instinct. Treat it as one hypothesis among several and say exactly what data would confirm or kill it. For monsoon, ask whether cancellations rose only on rain-affected days and zones and whether prior rain weeks show the same pattern. For a competitor coupon, ask whether new-customer order share dropped while repeat-customer cancellations stayed flat, and over what window. Naming the specific cut that isolates the claimed cause is what turns the interviewer's pushback from a trap into a point in your favour.

It opens with a crisp restatement of the metric, window and baseline, then a one-line check that the data is real before any cause is named. It segments out loud, narrowing from metro to zone to cohort, and says what each cut would reveal. It produces a ranked hypothesis set spanning a release, a fee change, a rider or restaurant supply issue, and external weather or competitor effects, with likelihood and rough impact stated. Every hypothesis carries the exact data pull that would confirm or kill it. It ends with a same-day mitigation, a durable fix, and the cancellation-rate target and guardrail used to verify the fix worked.

A single-metro metric move almost never has a uniform cause. A fee experiment may have ramped in two zones, a restaurant chain may have gone offline in one area, or rider supply may have collapsed in a specific cluster during rain. If you reason about the whole city as one undifferentiated number, the driver stays averaged out and invisible. Segmenting by zone, cohort, restaurant, payment method and app version localises the spike to where it actually lives, which is what lets you form a testable hypothesis instead of a guess.

Enough to show you know why a cancellation spike is expensive, not a full P and L. A cancelled order can still incur a rider dispatch cost, a refund, and lost contribution margin, so the metric maps directly to city economics. When you propose a mitigation, tie it to the cost it removes, for example reducing rider auto-cancels saves dispatch and refund cost per order. You do not need exact numbers, but anchoring the recommendation in delivery cost per order and contribution margin signals the mid-level business fluency Zomato expects.