What is a North Star Metric?
A North Star Metric measures the value your product delivers to customers over a defined period.
For a collaboration platform, that value might be teams completing work together. For a marketplace, it could be completed bookings. For a learning app, it might be users completing meaningful lessons and returning to build a habit.
The metric should connect 3 elements:
Customer value: the outcome users receive.
Product strategy: the customer problem the product chooses to solve.
Business outcome: the result the company wants to improve, such as retention, expansion, revenue, or margin.
The North Star Metric sits inside a wider system of product success metrics. KPIs, retention, satisfaction, quality, conversion, revenue, and operational measures still matter. The North Star gives these measures a clear centre of gravity.
A high number of logins rarely proves that customers are getting value. The team must define the meaningful action or outcome behind the activity. That often requires customer research, journey analysis, and better product engineering consulting before the metric can be stated precisely.
The North Star Metric framework
There is no universal formula for choosing a North Star Metric. The framework works best as a sequence of questions.
Start with the customer value exchange
Ask what customers hire the product to achieve.
A user of a project-management platform may want to complete work with fewer delays. A payment product helps customers complete transactions. A streaming service helps members find and watch content they enjoy.
The metric should describe the value moment, rather than a low-level action that happens on the way to it.
“Monthly active users” may be useful for a consumer product. It becomes more meaningful when the product defines what active means, such as completing a lesson, making a purchase, or finishing a workflow.
Connect customer value to a business outcome
The metric should have a credible relationship with the company’s product strategy and business model.
For example, a product might choose:
Weekly active teams completing a core workflow
That metric says more than “weekly active users.” It identifies the customer group, the frequency, and the outcome that signals value.
If teams repeatedly complete the workflow, the product may see better retention, account expansion, or renewal. Those relationships remain hypotheses until the company checks them across customer cohorts and time periods.
Check whether the metric is usable
A candidate metric should meet a few practical conditions:
Teams can define and calculate it consistently.
Product decisions can influence it.
It changes when customers receive more or less value.
Its unit, time period, and exclusions are easy to understand.
It can be segmented by customer type, product area, or lifecycle stage.
It works alongside quality and customer-health measures.
Many teams describe the North Star as a leading indicator. That is a useful goal, but the label alone doesn't prove that a metric predicts retention or revenue. The relationship must be tested through cohort analysis, experiments, and other forms of evidence.
North Star Metric examples by product model
Examples are useful when they show the reasoning behind a metric. They become misleading when presented as universal answers.
Product model | Possible North Star Metric | Customer value represented | Guardrail or limitation |
|---|---|---|---|
B2B analytics | Weekly Learning Users, meaning users who share a learning that others consume | The customer turns product analysis into shared knowledge and decisions | The metric must account for the usefulness of the learning, not only the number of shares. Amplitude has described this as a historical North Star Metric. |
Streaming subscription | Watch time or meaningful viewing sessions | Members find and consume content they want | Total hours can reward long content or passive viewing. Pair it with retention, satisfaction, content quality, and cancellation data. Netflix publicly connects engagement with member happiness, although it doesn't present one fixed formula as its formal North Star Metric. |
Marketplace | Completed bookings or nights booked | A guest successfully finds and books a stay while a host receives demand | Booking volume needs quality measures such as cancellations, reviews, trust, safety, and host earnings. “Nights booked” is a widely attributed Airbnb example, but teams should distinguish historical attribution from a current company statement. |
Mobility or delivery | Completed trips | A customer successfully receives transportation or delivery | Trip volume can rise while cancellations, safety issues, service quality, or driver economics worsen. Uber publishes trips as a core operating measure, but its North Star status is an interpretation rather than a confirmed corporate label. |
SaaS activation | Trial accounts with 3 or more active users in the first week | A team reaches an early collaborative value moment | The threshold should come from the product’s own conversion and retention data. It is an illustrative SaaS example, not a universal benchmark. |
These examples share one pattern: they measure a customer outcome or a strong proxy for one. A raw count of downloads, sessions, or messages gives less information when the connection to customer value is unclear.
How to define your North Star Metric
1. Write down the product strategy
Start with the customer segment, the problem you solve, and the outcome your product promises.
A product strategy that says “increase engagement” is too broad. A stronger version might state that the product helps distributed teams complete approval workflows faster and with fewer errors.
That statement gives the team a starting point for finding the value event.
2. Identify the value event
List the actions that show a customer has received the promised benefit.
For an invoicing product, the value event may be a paid invoice reconciled without manual correction. For a learning app, it may be a completed lesson followed by a return visit. For a marketplace, it may be a completed, non-cancelled booking.
Write the event in plain language first. Then define the data conditions that make it count.
3. Create and compare candidate metrics
Develop several candidates instead of selecting the first attractive number.
For each candidate, ask:
Does it represent a real customer outcome?
Can customers receive that outcome repeatedly?
Can product teams influence it?
Does it connect to retention, expansion, or another business outcome?
Can the data be collected with consistent rules?
Could teams increase it while damaging quality?
A metric that looks good on a dashboard may fail when customers receive little benefit from the activity.
4. Define the calculation
A usable North Star Metric needs a written definition.
Document:
The unit being counted
The eligible users or accounts
The qualifying event
The time window
The minimum quality condition
Exclusions and duplicate handling
The reporting frequency
The owner responsible for maintaining the definition
For example:
Weekly active teams completing at least 1 approved workflow, with no failed submission during the reporting period.
The wording may change as the product develops. The discipline of writing it down matters from the start.
5. Validate the relationship with retention and business outcomes
Compare the candidate metric across customer cohorts.
Do customers who reach the value event retain longer? Do accounts with repeated value expand more often? Does the metric move before renewal, conversion, or revenue changes?
Use “associated with” or “predicts” when the evidence supports those claims. A correlation between the North Star Metric and retention does not prove that one causes the other.
Customer interviews also matter. Data can show that a behaviour predicts retention while failing to explain why customers find it useful.
Input metrics make the North Star actionable
A North Star Metric gives the product organisation a direction. Input metrics show the behaviours and product conditions that teams can influence.
For the example “weekly active teams completing a core workflow,” inputs might include:
Teams completing onboarding
Users reaching the first successful workflow
Invitations accepted by teammates
Repeat workflow completion
Failed workflow rate
These inputs can guide product experiments, roadmap decisions, and team-level objectives. They should remain connected to the customer outcome.
A simple metric tree might look like this:
North Star Metric
Weekly active teams completing a core workflow
Input metrics
Onboarding completion
First successful workflow
Invited teammates who participate
Repeat workflow completion
Guardrails
Workflow errors
Support contacts
Account churn
Customer satisfactionMetric trees describe relationships that teams believe matter. They don't turn every relationship into a proven formula. Product development support can help teams improve the customer journey behind the metric, especially when design, engineering, and data quality issues affect the value event. Product engineering consulting can support this work.
Use product success metrics without losing context
The North Star Metric works alongside other measures.
Retention can show whether customers continue receiving value. Revenue can show whether the business model converts that value into financial results. Quality measures, support contacts, satisfaction, reliability, and margin can protect against short-term decisions that damage the product.
Guardrail metrics are especially useful when the North Star can be increased in harmful ways. A delivery product may increase completed orders by accepting late or inaccurate deliveries. A media product may increase watch time through low-quality recommendations. A collaboration product may increase messages while making work harder to complete.
Different products or customer segments may need different North Star Metrics. One company-wide number can hide important differences between a self-serve product, an enterprise platform, and a marketplace. A single primary metric is a useful default for a coherent product, not a rule that every portfolio must follow.
When should you review or replace the metric?
Review the metric when the product strategy, customer segment, business model, or core value exchange changes.
A metric can also become weak when teams learn how to increase it without improving customer outcomes. New channels, pricing models, product features, or regulatory requirements can create the same problem.
Set a review cadence and document the reasons for keeping or changing the metric. The goal is a measure that remains connected to customer value as the product grows.
When the metric crosses design, development, data, deployment, and continuous improvement work, external support may help. Mantu’s product engineering consulting can support organisations that need to turn product strategy into a working digital product and a measurable customer experience. A well-defined North Star Metric gives that work a sharper direction.
