analytical & metrics questions

Analytical questions are the round where interviewers separate PMs who talk about data from PMs who actually think with data. Every company in India — from Flipkart to a 15-person Series A — now asks some version of “how would you measure success for X” or “this metric dropped 20%, what do you do?”

I have watched thousands of candidates answer these questions. The pattern of failure is always the same: they list metrics. DAU, MAU, NPS, retention — a laundry list with no structure, no reasoning, no connection to actual business decisions. The interviewer nods politely and moves on.

The candidates who clear this round do something different. They build a measurement system on the whiteboard — starting from the user goal, not from a metrics glossary.

What analytical questions actually test

There are three types, and they test different things:

Type 1: “How would you measure the success of X?” — Tests whether you can connect product outcomes to business objectives. The interviewer wants to see you define what success means before you pick numbers to track.

Type 2: “Metric Y dropped by Z%. What happened?” — Tests your diagnostic thinking. Can you decompose a number into its components, form hypotheses, and prioritize which to investigate first?

Type 3: “Should we launch this feature? Here is the data.” — Tests your judgment under ambiguity. The data will be incomplete or contradictory. The interviewer wants to see how you reason through tradeoffs, not whether you pick the “right” answer.

Each type requires a different structure. Using the wrong structure is the fastest way to lose the round.

The scene

The candidate’s answer is not wrong — DAU and retention are real metrics. But they are the wrong level of abstraction. The interviewer wanted to hear the candidate define what the savings feature is supposed to do for the user, and then derive the metrics from that definition. Without that anchor, every metric is equally valid and equally useless.

The framework: Goal-Signal-Metric

This is the structure that works for Type 1 questions (“how would you measure success of X”). I teach this to every PM I train, and it comes directly from Google’s product measurement practice. Three layers, in this order:

Goal — What is the product trying to achieve for the user and for the business? Not “increase engagement.” Something specific: “Help users build a savings habit by making it easy to set aside money every week.”

Signal — What user behavior would tell you the goal is being achieved? Not a number yet — a behavior. “Users who set up recurring deposits and maintain them for at least 4 weeks.” Signals are observable actions that indicate the goal is working.

Metric — The quantifiable version of the signal. “Percentage of users who create a savings goal within 7 days of feature launch” (adoption). “Percentage of users with active recurring deposits after 4 weeks” (habit formation). “Average deposit amount as a percentage of stated savings goal” (progress toward user’s own target).

Now watch how the same savings feature question sounds with this structure:

“The goal of the savings feature is to help users build a regular savings habit. The business goal is to increase deposits held in the app, which increases our float revenue.

The signal that this is working is users who set up a savings goal, configure a recurring deposit, and maintain it. The signal that it is failing is users who open the feature, look around, and leave — or set up a goal but never deposit.

So my primary metrics would be: first, adoption rate — what percentage of eligible users create a savings goal within 14 days. Second, activation rate — of those who create a goal, what percentage make their first deposit. Third, retention — what percentage of activated users maintain their recurring deposit for 4 or more weeks. Fourth, the business metric — average deposits held per user per month.

I would also track a counter-metric: are users moving money from their spending account to savings in a way that increases support tickets about insufficient balance? If so, we are cannibalizing the payments experience.”

That answer takes 90 seconds and demonstrates four things the interviewer is grading: structured thinking, user empathy, business awareness, and the sophistication to think about counter-metrics.

The counter-metric: what separates good from great

Most candidates forget this. Every metric can be gamed or can have unintended consequences. The counter-metric is the number that tells you whether your primary metric is being achieved in a healthy way.

When you mention a counter-metric in an interview, the interviewer’s posture changes. It signals that you have shipped products, seen metrics move in unexpected directions, and learned to look at the second-order effects.

Diagnosing a metric drop (Type 2 questions)

The structure for diagnosing a metric drop has four steps. Do them in order.

Step 1: Decompose the metric

Every metric is a product of sub-metrics. Break it apart before you do anything else.

Daily orders = Daily Active Users x Orders per User

• DAU = New Users + Returning Users
• Orders per User = Sessions per User x Conversion Rate per Session

Now instead of one mystery (“orders dropped”), you have specific sub-questions. Did DAU drop? Did conversion drop? Did both drop? The answer tells you where to look.

Step 2: Segment

Do not look at the aggregate number. Break it by:

• Platform: Did it drop on Android, iOS, or web? If only Android, the app update is your prime suspect.
• Geography: Did it drop in all cities or specific ones? If only Bangalore, look for local events — rain, strikes, competitor promotions.
• User cohort: Did it drop for new users, returning users, or both? New user drop points to acquisition or onboarding. Returning user drop points to product experience or competition.
• Time of day: Did it drop during specific hours? Lunch orders fine but dinner orders cratered? That is a supply problem, not a demand problem.

Step 3: Hypothesize and rank

Based on decomposition and segmentation, form hypotheses and rank them by likelihood and ease of validation.

Step 4: Investigate in order of effort, not drama

Start with the cheapest hypothesis to validate. The app update crash log takes 15 minutes. If that explains the entire drop, you are done. Do not waste a day building a complex analysis when the answer might be a regression in the Sunday deploy.

This sequence — decompose, segment, hypothesize, investigate cheapest first — is exactly what interviewers want to see. It is also exactly what you do in real war rooms. The interview question is testing whether you have been in that room before.

Worked example: “Instagram Reels engagement dropped 12% week-over-week”

Here is how a strong candidate walks through this in an interview.

Decompose: Reels engagement = Users who watched at least one Reel x Average Reels watched per user x Average watch time per Reel. Which component dropped?

Segment: Check by country (India is 40%+ of Reels usage — if India dropped, that is the story). Check by content type — did a specific category of Reels drop? Check by source — did Reels from the Explore tab drop while Reels from Following stayed flat?

Hypothesize:

1. Algorithm change — a ranking model update surfaced less relevant content, users bounced faster.
2. Creator supply — fewer Reels posted this week due to a competing platform launching a bonus program.
3. Technical — video load time increased, causing abandonment before first play.
4. Seasonality — exam season in India, students (a major Reels cohort) are offline.

Investigate: Check if the drop is uniform across geographies. If India-specific, check the academic calendar. If global, check recent algorithm deploys. If only Explore-sourced Reels dropped, it is almost certainly a ranking model change.

A candidate who walks through this in three minutes, on a whiteboard, has demonstrated more analytical capability than one who recites the definition of DAU and MAU.

The “should we launch?” question (Type 3)

These questions give you data — often a table or chart — and ask you to make a recommendation. The data is always incomplete. That is the point.

The structure: state your recommendation, then defend it with the data, then name what is missing.

“Based on this A/B test data, I would recommend launching to 100%. Here is why: the test group shows a 14% improvement in activation with no statistically significant change in 7-day retention. The sample size is 12,000 users over 3 weeks — sufficient for this effect size at 95% confidence.

However, I would flag two risks before full launch. First, we do not have data beyond 3 weeks — if retention diverges at week 4 or 5, we would not see it in this test. Second, the test was run only in Tier-1 cities. Behavior in Tier-2 and Tier-3 may differ significantly, especially if the feature depends on network speed. I would recommend launching to Tier-1 immediately and running a separate 2-week test in Tier-2 before expanding.”

That answer structure — recommend, defend, flag risks, propose next steps — works for every Type 3 question.

The branching scenario

Five traps that kill your analytical round

1. Listing metrics without a framework. DAU, MAU, retention, NPS, CSAT — rattling off metrics without explaining why each one matters for this specific product tells the interviewer you memorized a glossary. Use Goal-Signal-Metric to derive your metrics from first principles.

2. Ignoring the business context. The savings feature exists because the company wants float revenue. The food delivery feature exists because the company needs higher order frequency to justify rider costs. If your metrics do not connect to the business model, the interviewer will wonder if you understand how companies work.

3. No counter-metrics. If every metric you mention is a “more is better” metric, you are not thinking about tradeoffs. Every optimization has a cost. Name it.

4. Treating all segments as equal. “Our users” is not one group. Power users and casual users behave differently. Tier-1 and Tier-3 cities have different infrastructure. New and returning users have different needs. Segment everything.

5. Confusing correlation with causation. “We launched the feature and retention went up” is not evidence that the feature caused the retention increase. The interviewer will test whether you know the difference — and whether you know how to design an experiment that isolates causation.

Where to go next

• Build the metrics intuition these questions require: Metrics That Matter
• Practice diagnosing metric drops systematically: Diagnosing Metric Drops
• Combine analytical thinking with product cases: Product Sense Questions
• See the full landscape of PM interview types: Interview Types