🌏 中文版
Today's Focus
A metrics interview has never really been about reciting AARRR or "North Star metric" — anyone can look those terms up in five seconds. What it actually tests is this: when an interviewer hands you a scenario where some number just dropped, can you run a repeatable process to pull it apart, rather than reaching for whatever story sounds plausible and calling it done? This question type is known in PM interview prep as "diagnostics," one of five major flavors of metrics case alongside success metrics, experimentation, metric definition, and trade-off analysis. Today's drill uses the North Star metric tree to work through a real diagnostics question.
Framework Cheat Sheet
Framework 1: The North Star metric tree
A North Star metric is usually too abstract for any single team to move in a two-week sprint. The fix is to break it down into four input levers a specific team can directly influence: breadth (how wide the reach is, across users or workspaces), depth (how much value a single use delivers), frequency (how often people come back), and speed (how fast they get to that value). The diagram below shows a real worked example from an AI writing platform, whose North Star is "weekly successful AI drafts completed."
Framework and example adapted from productspur.substack.com, "Deconstructing the North Star Metric."
Once the North Star is broken down, each lever becomes a team's OKR — growth owns breadth (improve workspace onboarding to raise invites sent within 48 hours), core product owns depth (ship context-aware template suggestions), platform owns speed (cut inference latency from 4.5 seconds to 1.2). When an interviewer asks how to turn an abstract North Star into something a team can actually execute against, this decomposition is the answer's skeleton.
Framework 2: What the interviewer is actually scoring
PM interview coach Aakash Gupta's breakdown of how most companies grade metrics questions splits scoring into four independent dimensions — weakness in any one drags the whole answer down, and strength elsewhere can't buy it back:
| Dimension | What it tests |
|---|---|
| Structured problem approach | Did you ask the right clarifying questions and surface every stakeholder and every positive/negative metric before jumping to a conclusion? |
| Strategic metric selection | Did you pick a metric that actually represents the core of the problem, not just whatever number was easiest to grab? |
| Technical operationalization | Is the chosen metric sensitive, trustworthy, cheap to compute, debuggable, interpretable, and fair across groups? |
| Trade-off evaluation | Did you name both the upside and downside, and any guardrail or tripwire metric the change might need? |
Today's Practice Question
The question
"Instagram Stories usage dropped 7% today, and DAU is down 5%. How would you investigate?" (Source: a diagnostics-type question compiled by PM interview coach Aakash Gupta, one of five major metrics-case categories he documents, widely reported in Meta-style analytical/execution interview rounds.)
How to break it down
- Pin down the metric's definition: Before anything else, clarify what "Stories usage" actually counts — posts, views, or interactions? Is the 7% drop versus yesterday or the same day last week? Is it global or confined to one market? Get the denominator wrong here and everything downstream is built on sand.
- Rule out instrumentation first: Before chasing user behavior, confirm the dashboard itself isn't lying — has tracking logic changed, is there a pipeline delay, has a calculation definition shifted quietly? This is the step most candidates skip, and the one most likely to send the whole answer in the wrong direction.
- Segment to localize the problem: Cut the data by geography, platform (iOS vs. Android), user cohort (new vs. returning), and entry point. If the drop concentrates in one slice, the search space just shrank dramatically.
- Line up the timeline against events: Match the exact moment the drop started against internal changes (a feature launch, an A/B test rollout) and external events (a platform policy change, a competitor move, seasonality). Let the timing point you to the explanation — don't pick a conclusion first and go looking for evidence to fit it.
- Commit to a conclusion and define next steps: State the most likely cause, your confidence level, and what additional data would confirm it. Then propose whether this metric needs an automated alert threshold so a future drop like this gets caught faster next time.
Sample answer (how this could actually sound in the room)
Frame the question first: "I'd start by confirming exactly which action that 7% refers to — posts, views, or replies — and whether the drop is global or concentrated in one market, because that changes everything about where I look next." Rule out a false signal: "Before digging into user behavior, I'd check with the data team whether tracking logic or a calculation definition changed in the last 24 hours. I've seen plenty of 'metric drops' turn out to be a broken instrumentation change — that check takes minutes and can save a lot of wasted investigation." Localize with segments: "Assuming the data's clean, I'd cut the drop by platform, region, and new versus returning users. If it's concentrated on iOS among new users, I'd look at a recent App Store update or onboarding flow change; if it's broad-based, that points more toward an algorithmic distribution change or an external event." Line up the timeline: "I'd match the exact moment of the drop against anything the company shipped this week and any external news, and look for whichever explanation fits the timing best." Converge and recommend: "I'd close with my best hypothesis and how confident I am in it, and I'd propose setting a daily automated alert threshold on this metric so a drop like this gets caught within hours next time, instead of waiting for someone to notice it manually."
Self-check
| Check | Covered? |
|---|---|
| Did you pin down the metric's exact definition and comparison baseline before anything else? | |
| Did you proactively rule out an instrumentation or logging bug instead of jumping straight to user behavior? | |
| Did you use at least one segmentation dimension (geography, platform, cohort) to localize the problem? | |
| Did you line up the timeline against internal releases or external events? | |
| Did you state a confidence level instead of presenting your conclusion as the only truth? | |
| Bonus: did you propose a monitoring alert or guardrail metric to catch this faster next time? |
Today's Case
Spotify: choosing listening time over sign-ups as its North Star, early
In its early growth years, Spotify faced a familiar fork: the growth team wanted to chase sign-ups, the commercial team wanted to chase paid conversions. Had Spotify made total sign-ups its primary operating metric, the product org would have poured its energy into harder onboarding funnels, heavier promotional discounts, and more invasive referral loops — and users who opened the app once, found it confusing, and never came back would still count as "growth" on a dashboard, even though it was dead weight. Spotify instead centered the organization on active users' listening time, a single number doing three jobs at once: proving users had actually folded Spotify into daily life (commuting, working out, studying), feeding recommendation models like Discover Weekly and Daily Mix (more listening means more behavioral data, which means better recommendations, which makes the product harder to leave), and directly driving the business model (more listening on the free tier means more ad inventory; high usage builds product dependency that pulls people toward paid tiers without needing an aggressive paywall). It's one of the cleanest real-world illustrations of the gap between a vanity metric and a value-capturing one: sign-ups make a team feel good in a status update, but listening time is the number that actually tracks retention and business outcomes.
Interview angle: when asked to design a North Star metric for a given product, or to choose between two candidate metrics, this case is a ready-made piece of evidence — first lay out where each candidate metric would push the team's effort, then converge on which one actually represents value delivered to the user rather than a vanity number at the top of the funnel.
Further Reading
- Product Metrics Interview: GAME Framework and 93 Questions — Aakash Gupta's full landscape of the metrics interview, including the five case categories and the scoring-dimension breakdown.
- Every Product Needs a North Star Metric — Amplitude's own North Star framework writeup, useful context for where the metric-tree decomposition comes from.
- Your product team doesn't need a "North Star Metric" — a contrarian take from former Tinder/Vimeo product leader Ravi Mehta, a useful reminder of how hollow a North Star gets when it's misused.
References
- Lesson 51: Deconstructing the North Star Metric (NSM) — primary source for the breadth/depth/frequency/speed metric-tree framework and the Spotify case, used in "Framework Cheat Sheet" and "Today's Case."
- Product Metrics Interview: GAME Framework and 93 Questions — source of the "Instagram Stories dropped 7%" question and the four-dimension scoring table, used in "Today's Practice Question" and "Framework Cheat Sheet."
- Product Execution PM Interview - Reddit Root Cause Analysis Case Study — source of the internal/external/system-technical categorization used in steps 2 and 4 of "How to break it down."