How to Answer 'How Would You Measure Success?' in PM Interviews
North Star metrics and AARRR explained for product managers: what they are, how they work together, and how to structure a strong answer when an interviewer asks how you'd measure success for a product or feature.
By The Cala Voice Team ·One of the most common questions in PM interviews sounds like a softball: "How would you measure the success of this product?" or "What metrics would you track for this feature?" Most candidates answer with a list: daily active users, retention rate, conversion rate, NPS. The list is usually correct. It is also almost always insufficient.
Not because the metrics are wrong, but because a list of metrics says nothing about how you think. Metrics without a hierarchy are vocabulary, not reasoning. What an interviewer is testing is whether you can identify the single metric that matters most, how secondary metrics relate to it, and what you would refuse to trade away in pursuit of it.
That structure (one primary metric, a supporting hierarchy, and explicit guardrails) is what the North Star Metric and AARRR frameworks are built to produce.
Why "List Your Metrics" Is the Wrong Answer
Before the frameworks, it is worth understanding the failure mode they solve.
When asked what metrics they would track, most candidates default to the same set: DAU, MAU, retention, conversion, revenue, NPS. These are all legitimate metrics. They are also completely generic. Every product team tracks some version of them. Listing them signals that you know what metrics are, not that you understand what this specific product is trying to do.
The deeper problem is that these metrics are frequently in tension with each other, and candidates who list them without acknowledging that tension reveal they have not thought through the tradeoffs. A growth tactic that increases DAU can decrease retention if it brings in low-intent users. A monetization change that increases revenue can increase churn. A feature that improves NPS can have no effect on retention because users appreciate it and still don't come back.
Good metric design resolves this tension by establishing a hierarchy: one metric that represents the core value the product delivers, and a set of secondary metrics that explain how and why that number moves. When metrics conflict, the hierarchy tells you which one wins.
The North Star Metric
The North Star Metric is the single number that best captures the value your product delivers to users. Not to the company. To users. Revenue is what the company gets when value is delivered. The North Star is the value itself.
Sean Ellis, who popularized the concept while building growth teams at Dropbox and later at GrowthHackers, described it as the metric that best captures the core value your product delivers to customers. The practical test: if users are getting genuine value from your product, this number goes up. If they are not, it does not, regardless of how much you spend on acquisition.
Some well-known examples:
| Product | North Star Metric |
|---|---|
| Spotify | Time spent listening |
| Airbnb | Nights booked |
| Slack | Messages sent within a team |
| Cursor | Code changes accepted per active developer per week |
| NotebookLM | Research sessions where user saves at least one insight |
| Duolingo | Days of active learning streaks |
Notice that none of these are DAU, revenue, or NPS. Those metrics are consequences of the North Star going up. DAU measures whether users open the product. It does not measure whether they got anything from it. A product can have high DAU and be failing on every dimension that matters: users open it, find nothing useful, and close it within seconds.
Why one metric, not a scorecard
The instinct to track a balanced dashboard of five or six important metrics is understandable, but it creates a coordination problem. When a team has six equally important metrics, they optimize for whichever one is easiest to move right now, which is usually not the one that matters most. The North Star forces a hard conversation: if we could only improve one number this quarter, what would it be? The answer to that question is the real reveal of what a team believes their product is for.
A second reason is that a single metric creates a shared decision rule. When two features are competing for engineering time, the team with a clear North Star can ask "which one moves it more?" rather than debating priorities on subjective grounds. It does not answer every tradeoff, but it makes the core one explicit and prevents the organizational drift that happens when different parts of a team are optimizing for different things.
The Goodhart's Law problem
The North Star also needs to be resistant to gaming. This is the problem Goodhart's Law names:
When a measure becomes a target, it ceases to be a good measure.
Marilyn Strathern, 1997 (paraphrasing Charles Goodhart)
Applied to product: when teams optimize hard for a metric, they find ways to inflate it that do not require delivering value. Facebook's use of "time spent" as an engagement proxy led to algorithmic decisions that maximized attention without maximizing genuine user value, because time spent can be inflated through addictive design patterns rather than better product experiences.
A well-chosen North Star is difficult to inflate without genuinely helping users. Nights booked on Airbnb is hard to game without actually facilitating stays users want. Code changes accepted per developer is hard to inflate without the AI actually writing useful code.
How to find the North Star for an interview question
Ask: at what point does a user actually get what they came for? Not the sign-up moment. Not the session start. The moment the product delivers on its promise.
For a navigation app: arriving at the destination without getting lost. For a job board: accepting an offer. For an onboarding flow: completing the action that makes a user confident enough to come back tomorrow. The North Star is usually close to that moment, or the most reliable proxy for it that is measurable at scale.
AARRR: The Hierarchy Below the North Star
Once you have a North Star, you need a way to understand why it is moving or not moving. That is what AARRR provides.
Introduced by Dave McClure in 2007 (in a presentation called "Startup Metrics for Pirates," which is where the name comes from), the framework organizes user behavior into five sequential stages that map the full arc of a user's relationship with a product.
The value of organizing metrics this way is diagnostic. When the North Star is not moving, AARRR tells you where to look. You cannot fix a retention problem by improving acquisition. You cannot fix an activation problem by optimizing referral. The funnel structure forces you to identify which stage is broken before reaching for solutions, which is the discipline most product teams skip when they are under pressure.
Acquisition: how users find and reach the product. Channels, traffic sources, sign-up volume. The question at this stage is whether you are reaching people who actually have the job the product serves. High acquisition volume with low activation usually means the wrong people are arriving, and scaling acquisition will only waste more budget.
Activation: the moment a user first experiences the product's core value. Often called the "aha moment": the first time the product demonstrates it can do what it promised. Activation is frequently the most important and most neglected stage. A product that acquires a thousand users but activates fifty of them has a 95% waste rate before the North Star has any chance of moving. Most teams underinvest here because activation happens early and is less visible than DAU or revenue dashboards. Yet fixing the activation rate typically outperforms scaling acquisition by a significant margin, because every improvement compounds across all future users.
Retention: whether users come back. This is the stage where the North Star lives for most products. A retained user is one who found enough value the first time to return for more. Retention is the primary signal of product-market fit: everything else can be bought, but users coming back on their own cannot. It is also the most honest signal in the funnel: a user who retains is voting with their time.
Revenue: whether the product captures value from users, directly or indirectly. For most products, revenue follows retention closely. Users who retain and get genuine value are the ones who convert to paid, upgrade their plan, or generate advertising value. If revenue is weak but retention is strong, the problem is monetization mechanics, not product value.
Referral: whether satisfied users bring other users. Word-of-mouth and virality are functions of the gap between what users expected and what they received. Products with strong referral typically have a genuine activation moment and a clear North Star. Referral cannot be manufactured from a weak product: tactics like referral bonuses or sharing prompts only amplify what is already there.
One useful reframing worth knowing: growth practitioner Brian Balfour proposed RARRA (Retention, Activation, Referral, Revenue, Acquisition) as an alternative ordering. The argument is that for growth-stage products, retention is the foundation everything else depends on. Building referral or acquisition loops on top of a product that does not retain is filling a leaking bucket. AARRR is the right diagnostic sequence. RARRA is the right prioritization sequence.
The AARRR framework does two things in an interview answer. First, it gives you a way to organize secondary metrics without listing them randomly. Second, it tells you where in the funnel to look when the North Star is not moving. If retention is flat, you diagnose by stage: is acquisition bringing the right users? Are they activating? If they activate, do they retain? The hierarchy converts a vague "our metrics are down" into a specific investigation path.
Guardrail Metrics
A metric hierarchy tells you what to optimize for. Guardrail metrics tell you what you will not sacrifice in pursuit of that optimization.
The concept addresses a predictable failure mode: any sufficiently optimized North Star will eventually be gamed, not maliciously but because teams find shortcuts. Consider an AI coding assistant using "code changes accepted per developer per week" as its North Star. A team optimizing purely for this number might lower the confidence threshold for suggestions, surfacing lower-quality completions more aggressively to drive acceptance rate up. The North Star metric improves. Code quality degrades. Users start reverting more AI-suggested changes, and trust in the tool erodes over months without the primary metric showing any warning sign.
A guardrail metric (code change revert rate, user-reported error rate, session abandonment after accepting a suggestion) puts a floor on what you will not trade away. Breaching the guardrail is a stopping condition, not a tradeoff to weigh. It changes the conversation from "how much do we sacrifice X to gain Y?" to "we will not proceed if X falls below this threshold."
Good guardrails share three characteristics. They are monitorable in near-real-time, not quarterly. They connect to a real harm, not a theoretical one. And they are set as thresholds rather than targets: the goal is to not breach them, not to improve them.
The guardrail question to ask in any interview answer is: what is the second-order harm that could occur if this North Star is optimized without constraint? For consumer products, common guardrail categories are user wellbeing signals, content quality, and support volume. For AI products, model trust and output accuracy are frequent candidates. For marketplace products, supply-side health (creator satisfaction, seller quality, host reliability) matters as much as demand-side metrics.
Naming guardrail metrics in an interview answer signals that you have thought through second-order effects. Most candidates do not get there.
How to Structure the Interview Answer
When an interviewer asks how you would measure success for a product or feature, a strong answer follows this sequence:
1. Clarify the goal. Before naming any metrics, establish what success means in this context. What user behavior is this product or feature trying to change? What problem is it solving? This step alone separates candidates who think in problems from candidates who think in dashboards.
2. Name the North Star. Identify the single metric that best captures the value delivered to users. Explain briefly why this metric and not the obvious alternatives (DAU, revenue, NPS).
3. Sketch the AARRR hierarchy. Walk through the relevant funnel stages in terms of this product. You do not need to cover all five in depth: focus on the two or three stages most relevant to the question.
4. Add one or two guardrails. Name the metrics you would monitor to ensure optimization does not produce second-order harms.
5. State what you would focus on right now. Given the product's stage and the question's context, which metric in the hierarchy is the highest-leverage place to look? This is where prioritization judgment shows, not just framework knowledge.
Example: "How would you measure success for a new onboarding flow?"
Without structure: "I'd track completion rate, time to first action, DAU, and retention. I'd also look at NPS to understand satisfaction."
With North Star + AARRR: "The goal of onboarding is activation: getting a new user to their first genuine experience of the product's core value. I'd define success for this flow as activation rate: the percentage of new users who reach the moment where they've understood what the product does and taken a meaningful first action that predicts they'll return.
Below that, I'd use AARRR to organize the supporting metrics. At acquisition: how many users are starting onboarding (and what's their source, since high-intent channels will activate differently). At activation: step-level completion rates to find where users drop, and then the specific first action most correlated with day-7 retention, which is my proxy for the 'aha moment.' At retention: day-7 and day-30 retention as downstream validation that activation actually happened and held.
Guardrails: time-to-activation (if I make onboarding shorter but users arrive confused, activation rate holds while retention drops), and support ticket volume for onboarding-related issues.
Right now, I'd focus on step-level completion and the aha-moment action. Until I know where users drop and whether the first valuable action is happening, everything else is optimizing in the dark."
Example: "How would you measure success for Cursor's AI code completion?"
The product's core value is helping developers write better code faster. The North Star is probably something like code changes accepted per active developer per week: it requires the AI to be producing output worth keeping, not just output that gets shown.
Acquisition: developers installing the extension and completing their first session. Activation: developers who accept their first meaningful suggestion in a real project (not a tutorial or demo). Completion is a much stronger signal than an install. Retention: developers still using it actively at 30 days, meaning it has become part of their workflow, not just a novelty they tried once.
Revenue contribution is mostly indirect: acceptance rate drives retention, retention drives seat expansion in team plans. I'd track it as a leading indicator of expansion revenue rather than a direct conversion metric.
Guardrails: code revert rate after AI suggestions (if developers are undoing what the AI wrote, trust is eroding), and error rates introduced in AI-assisted sessions compared to a non-assisted baseline. If the North Star is going up but these guardrails are drifting, the product is getting worse in a way the primary metric will not catch.
The leading indicator I'd watch most closely is acceptance rate on suggestions in real projects, because it is the most direct signal that the model is calibrated to what developers actually want to keep.
The Mistakes That Look Like Good Metric Thinking
The most common advanced mistake is not listing random metrics. It is picking the wrong North Star. Two choices come up repeatedly.
Revenue as the North Star. Revenue is the most tempting choice because it feels strategic and because companies care intensely about it. But revenue is what happens when the product works, not proof that it is working. A product that raises prices will increase revenue while losing users. A product that bundles unwanted features into a premium tier will convert free users while degrading their experience. Revenue, LTV, and margin belong in the AARRR hierarchy at the Revenue stage, or in the business case, but not as the metric against which everything else is measured. When they are the North Star, teams start optimizing for the company's interests at the expense of the user's, and eventually, through churn, reputation damage, or competitive substitution, the business suffers anyway.
DAU as the North Star. Daily active users measure whether users are opening the product. They do not measure what users are doing when they get there. A product with 10 million DAU where users open and close in frustration within 30 seconds is not healthy by any useful measure. DAU as a North Star tends to produce features optimized for re-engagement (notifications, streaks, FOMO mechanics) rather than features optimized for the actual value the product exists to deliver. The result is products that are "engaging" in the sense that users open them, without being useful in the sense that users get something from them.
Both of these mistakes have the same root: confusing a business outcome metric with a user value metric. The North Star has to be a signal of value delivered to the user. Business outcomes follow from that, and only from that, sustainably.
The Connection to Jobs to Be Done
Metric design and Jobs to Be Done are the same question approached from different directions.
JTBD asks: what is the user trying to accomplish, in what circumstance? Metric design asks: how do you know whether they accomplished it? If you do not know the job, you cannot define the North Star. If your metrics do not connect to the job, you are measuring activity instead of progress.
This is why the interview answer structure above starts with "clarify the goal" before naming any metrics. The goal is the job. The North Star is the job expressed as a number. Everything else in the hierarchy is an explanation of how that number moves and what might prevent it from doing so.
A team that writes "users want faster search" will measure search speed. A team that understands the job ("users want to stop looking incompetent when they cannot find something quickly in front of colleagues") will measure whether users actually find what they need under time pressure. A different metric, with a different improvement direction, one that connects the feature to the user's actual situation.
What to Read and Do Next
For the companion question on metric drops, the PM Metric Drop Guide covers the diagnostic framework in detail. Success metrics are also the final step of any product design answer: the Product Design Interview Guide covers the full structure, and CIRCLES goes deep on the framework where metrics appear as the closing recommendation. For the broader set of interview question types and how metrics questions fit alongside product design, strategy, and behavioral questions, see PM Interview Frameworks.
Cala Voice covers North Star Metrics and AARRR in its audio brief library, alongside PM book summaries, interview guides, and framework deep dives. For interview practice, the voice coach lets you work through metrics questions with immediate feedback on whether your answer has a clear hierarchy and the reasoning behind it.