'Our DAU dropped 20% last week — walk me through how you'd diagnose it.' The most common, highest-signal PM analytical interview question, with a structured seven-step answer.
▸ Try the interactive tool'Our DAU dropped 20% last week — walk me through how you'd diagnose it.' This is the most common and highest-signal PM analytical interview question, and it has a structured answer. The metric-drop root cause analysis is a step-by-step framework that, used consistently, demonstrates exactly the structured analytical thinking the question is designed to test.
The framework moves systematically from clarifying the problem to isolating the cause: clarify the metric (what exactly dropped, how it's defined), check for data/measurement issues first (is the drop even real?), characterise the drop (sudden vs gradual, which segments, when), segment to isolate (platform, geography, user type, new vs existing), distinguish internal from external causes (a release vs a seasonality or competitor effect), form and test hypotheses, and arrive at the likely root cause. The key signals interviewers look for: checking data integrity before chasing causes, segmenting systematically, and considering both internal and external explanations — not jumping to a guess.
1. Clarify the metric · 2. Check it's a real drop (data issues first) · 3. Characterise it (sudden/gradual, when) · 4. Segment to isolate · 5. Internal vs external causes · 6. Hypothesise & test · 7. Root cause.
The metric-drop question tests structured analytical thinking — and the most common failure is jumping straight to a guessed cause instead of systematically working toward it.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Jumping to a cause | Guessing 'it must be the release' skips the diagnosis. | The framework works systematically to the real cause. |
| Not checking data first | Chasing a 'drop' that's actually a measurement error. | Checking data integrity first avoids the wasted hunt. |
| Not segmenting | Treating the drop as uniform misses where it's concentrated. | Segmenting isolates the cause dramatically. |
| Ignoring external causes | Assuming an internal cause and missing seasonality/competitors. | Considering both internal and external covers the real space. |
Pin down exactly what dropped and how it's defined — which DAU, measured how, over what window. Clarifying questions show structured thinking from the first moment, and prevent diagnosing the wrong thing.
Before chasing causes, ask: is the drop even real, or a data/measurement/logging issue? Interviewers specifically look for this — checking data integrity before the hunt is a top signal.
Is it sudden or gradual, and when did it start? Then segment — by platform, geography, user type, new vs existing — to isolate where the drop is concentrated. A drop in one segment narrows the cause enormously.
Consider both: internal (a release, a bug, a changed flow) and external (seasonality, a competitor, a market event). Assuming internal and missing external is a common, revealing mistake.
Form hypotheses from the segmentation, test them against the data, and arrive at the likely root cause. The structured path from clarification to conclusion — not the guess — is what the question rewards.
Asked the classic metric-drop question, a candidate immediately guessed a cause — 'probably the recent release broke something.' It might even have been right, but jumping straight to a guess demonstrated none of the structured analytical thinking the question exists to test, and skipped the most basic check: whether the drop was even real.
A strong answer worked the framework instead: clarified exactly what dropped, checked first for a data/logging issue (is the drop real?), characterised it (sudden, started a specific day), segmented to isolate it (concentrated in one platform), considered internal and external causes, then formed and tested hypotheses to reach the root cause. The same possible answer — a release — might emerge, but now via a rigorous diagnosis that demonstrated exactly the structured thinking the interviewer was assessing.
The deliverable is a systematic diagnosis — clarify, verify, characterise, segment, internal/external, hypothesise — demonstrating structured analytical thinking.
| Signal interviewers want | Demonstrated by |
|---|---|
| Don't jump to a cause | Clarify and verify first |
| Check data integrity | 'Is the drop even real?' |
| Systematic isolation | Segmenting the drop |
| Full cause space | Internal AND external causes |
The metric-drop RCA is the highest-signal analytical interview question because it directly reveals whether a PM thinks in structured diagnosis or jumps to guesses — and the framework is how you demonstrate the former.
What makes this question so revealing is that the obvious move — guessing a plausible cause — is exactly the wrong one, even when the guess happens to be right. The interviewer isn't looking for the answer; they're looking for the process, because a PM who can systematically diagnose a metric drop can systematically diagnose anything. The framework demonstrates that process: the discipline of checking whether the drop is even real before chasing causes (a data-integrity check that separates rigorous PMs from impulsive ones), the systematic segmentation that isolates where a drop is concentrated, and the consideration of both internal and external causes rather than assuming it's something the team did. This is the same diagnostic discipline as the funnel drop-off diagnostic from Module 5, applied to the interview — and it's the specific framework for the analytical question type from the interview taxonomy.
Even a right guess fails the question. Work the framework systematically.
Chasing a measurement artefact wastes the diagnosis. Verify the drop is real.
A drop concentrated in one segment reveals the cause. Segment systematically.
Assuming internal misses seasonality and competitors. Consider both.
It's the specific framework for the analytical type in the taxonomy (Tool 24).
The same systematic diagnosis as Module 5's funnel diagnostic (Module 5, Tool 12).
Segmenting to isolate draws on cohort/segment analysis (Module 5, Tool 09).
Structured diagnosis embodies being data-informed (Module 5, Tool 01).
AI is a useful thinking partner for the metric-drop question — generating hypotheses and the queries to test them.
The judgment that stays yours: The question tests structured diagnosis, not a memorised answer — and jumping to an AI-suggested cause is the same failure as jumping to your own guess. Use AI to rehearse the discipline and generate hypotheses, then reason to the cause yourself.
Take the classic prompt: 'a key metric dropped 20% last week.' Before guessing any cause, write your first two moves — and make sure step one checks whether the drop is even real.
Then sketch how you'd segment it to isolate the cause, and name one internal and one external possibility.
If your first move is to verify and clarify rather than guess a cause, you've demonstrated exactly the structured thinking the question tests — and avoided the trap that fails even correct guesses.
Related · The Drop-Off Diagnostic →