How to Build a North Star Metric Framework for Your Product
Most product teams track too many metrics and are aligned around none of them. The north star metric framework solves this by giving every team a single number that captures the core value the product delivers to users — and a structured set of input metrics that explains how to move it. When a team truly aligns around a north star metric framework, product prioritization becomes dramatically clearer, progress becomes easier to measure, and cross-functional alignment becomes less reliant on persuasion and more grounded in shared goals.
Teams that build this framework from scratch, across companies with very different data maturity, tend to hit the same wall: the hard part isn’t picking the north star metric — it’s the input-metric layer underneath it, which is where most frameworks quietly stop working. This guide covers how to build a north star metric framework from scratch, choosing the right north star metric, defining the input metrics that drive it, and using the framework to make better product decisions week over week.
What Is a North Star Metric Framework
A north star metric framework is a structured approach to product measurement that centers on one primary metric — the north star metric — that best captures the value your product delivers to users, and connects that metric to a set of input metrics that explain the levers your team can pull to move it.
The term was popularized by Sean Ellis and developed further by Amplitude, whose North Star Playbook is the definitive resource on the topic, and by Lenny Rachitsky, who has written extensively about how top product teams apply it. For the definitional groundwork on what the metric itself needs to satisfy before you build the framework around it, see our guide on what a north star metric is and how to choose yours. If you’re building out your full measurement stack rather than just this one framework, our product metrics guide covers how the north star sits alongside guardrail and diagnostic metrics.
The framework has three components. First, the north star metric (NSM): the one metric that best represents the sustainable value your product delivers. For Spotify, this might be time spent listening. For Airbnb, it might be nights booked. For a B2B SaaS product, it might be weekly active teams. The NSM should be a leading indicator of business health — something that, if it grows, produces revenue and retention — but shouldn’t be a purely financial metric itself, since revenue is an output, not the value delivered.
Second, input metrics: the three to five metrics the team can directly influence and that together drive the north star metric. These are the levers. For a product whose NSM is weekly active users, input metrics might include activation rate, D1 retention, feature adoption, and reactivation rate. Each input metric should have a clear causal relationship to the NSM.
Third, the connection between the two levels: the framework makes explicit how the input metrics combine to drive the NSM, so the team always knows which lever to pull.
How to Choose Your North Star Metric
Choosing the right north star metric is the most important and most difficult step in building a north star metric framework. The wrong one creates misaligned incentives that push the team toward actions that look good on the metric while degrading the actual user experience.
Amplitude’s criteria for a good north star metric: it expresses value (it measures something users value, not something the company values at users’ expense), it represents breadth and depth (it captures how many users are getting value, not just total volume), it’s a leading indicator of revenue, and it’s actionable — the team can actually do things that move it.
Common mistakes: choosing revenue or subscription count as the NSM (these are outputs, not value), choosing a vanity metric that’s easy to move without creating real value (page views, downloads, registrations), choosing a metric so broad that no single product team can feel responsible for it. Testing whether yours is right: if you were moving the metric in ways that were bad for users, would you know? If the answer is “not necessarily,” it’s probably the wrong NSM.
Defining Input Metrics That Drive Your NSM
Once you have a north star metric, the next step in building the framework is defining the input metrics — the levers your team controls and that drive the NSM.
Good input metrics are specific (tied to a concrete user behavior), measurable (observable in your analytics), actionable (the team can do things that change them), and causally connected to the NSM (there’s a plausible mechanism by which moving this input metric moves the NSM).
To identify your input metrics, start with the user journey and ask: at which stages are users most likely to reach the value your NSM measures? What behaviors predict sustained engagement? What frictions prevent users from getting to value?
At a 40-person B2B collaboration startup, the team set the NSM as weekly messages sent per active user, and the first draft of the input metrics had six candidates on the whiteboard — too many for anyone to hold in their head during planning. They cut it to four by asking, for each one, “does moving this actually change the NSM, or does it just correlate with it?” Two survived that test: activation rate (first message sent within 24 hours of signup) and connection rate (connected to at least 3 teammates in the first week). They killed “total logins” and “profile completeness” because both correlated with the NSM without any team being able to point to a mechanism that caused it. The remaining four — activation rate, connection rate, feature discovery rate, and D7 retention — each mapped to a specific engineering or design team, which is what actually made the framework usable in planning rather than just impressive in a slide.
North Star Metric Framework Examples From Real Companies
Seeing the framework applied to real products makes it clearer how to build your own.
| Company | North Star Metric | Sample Input Metrics |
|---|---|---|
| Spotify | Time spent listening | Activation rate, playlist creation, discovery-feature engagement, D30 retention |
| Monthly active professional exchanges | Profile completion, connection acceptance rate, content engagement rate | |
| Notion | Connected teams (3+ active members) | Invitation acceptance rate, template adoption, daily active editing sessions |
Notice that in each case, the NSM captures the specific value the product delivers — not just usage, but the kind of usage that represents real value exchange. And each input metric represents a specific, actionable step in the journey to that value.
How to Align Your Team Around a North Star Metric
A north star metric framework that lives in a document and never changes team behavior isn’t a framework — it’s a planning artifact. Making it actually work requires building it into how the team plans, prioritizes, and reviews work.
In quarterly planning: every roadmap initiative should have an explicit connection to the NSM or one of its inputs. If a proposed initiative can’t articulate which input metric it moves, either re-examine it or deprioritize it.
In weekly reviews: review the NSM and input metrics weekly. Which inputs are trending well? Which are declining? What’s the current hypothesis about why? This regular review keeps the framework alive rather than a set-and-forget artifact.
In prioritization: when two initiatives compete for the same engineering resources, the framework provides a principled tiebreaker — which initiative has the higher confidence of moving the most important input metric by the most in the time available? At the same collaboration startup, this played out concretely when design wanted to rebuild the onboarding flow and engineering wanted to ship a more powerful search feature in the same sprint. Neither was obviously more important on its own merits. Once both were mapped against the input metrics, the onboarding rebuild had a clear, testable line to activation rate; search had a plausible but unmeasured line to feature discovery. The team shipped onboarding first and instrumented search as an experiment rather than a full build, which turned a subjective debate about “what feels more important” into a question about which bet had better evidence behind it. For connecting the framework to your OKRs, see our guides on OKRs for product managers and how to measure product success.
Where North Star Metric Frameworks Break Down in Practice
Picking the metric is the part every guide covers. The framework itself tends to fail somewhere else entirely, months after launch.
Input metrics start competing instead of combining. When two input metrics can be improved in ways that trade off against each other — connection rate versus feature discovery rate, say, if both compete for the same onboarding screen real estate — teams end up optimizing whichever one their manager mentioned most recently, not whichever one actually moves the NSM more. If this happens, model the relative weight of each input against the NSM with whatever data you have, even roughly, so the tradeoff has an answer instead of becoming a recurring argument.
An input metric gets gamed instead of genuinely moved. “Connection rate” can be inflated by auto-suggesting connections nobody wanted; “feature discovery” can be inflated by a forced product tour that nobody actually uses afterward. One team celebrated three straight weeks of “feature discovery” growth that was entirely explained by a UI change that made a tooltip harder to dismiss. The fix isn’t abandoning the input metric — it’s pairing it with a downstream check (does this input’s growth actually show up in the NSM two weeks later?) so gaming gets caught quickly instead of quietly compounding for a quarter.
The framework doesn’t get rebuilt when the product changes. Input metrics defined for a product’s onboarding flow stop being causally connected to the NSM once that onboarding flow is redesigned, but nobody schedules a review of the framework itself — only of the numbers inside it. Treat the input-metric list as something to re-derive, not just re-measure, every time you ship a structural change to the part of the product it describes. A framework built in month one of a product’s life and never revisited is describing a product that no longer exists by month twelve.
There’s a quieter version of this failure too: the team that built the framework moves on — reorgs, new hires, a founder who originally championed it leaves — and the framework survives as a slide nobody updates rather than a living part of planning. Reviving it usually takes less effort than teams expect. It’s rarely a data problem; it’s almost always that nobody currently has “own the north star review” as an explicit part of their job, and ownership quietly evaporated along with the person who used to informally hold it.
If a team can’t currently say, without checking a doc, what its north star metric is and which input metric each person owns, the framework has already broken down — regardless of how good the original metric choice was. That’s the thing to fix this week, not the metric itself. Asking three people on the team that question today, in a hallway or a Slack DM rather than a meeting, is a fast way to find out. Three different answers, or a pause before an answer, points straight to the next action item.
References
- Ellis, S. (2017). Hacking Growth. Crown Business.
- Amplitude. “North Star Playbook.” amplitude.com
- Rachitsky, L. (2024). North Star Metric Series. lennysnewsletter.com
- Reforge. (2024). Product Metrics Curriculum. reforge.com
