How to Choose a North Star Metric That Represents Real Customer Value

Most teams do not fail because they lack metrics. They fail because they commit to the wrong one for too long, and then defend it with a workshop story instead of evidence.

The instinct in the current literature is right: start from customer value, not from the dashboard. But the popular three-check version of the advice hides almost all of the hard judgment. "Does it reflect customer value? Does it connect to the business? Can the team influence it?" sounds complete, and it is not. Those questions are the beginning of the reasoning, not the end of it.

A North Star Metric is one measure, at a clearly defined Product or business scope, intended to represent recurring customer value and to serve as a leading signal of sustainable business performance. Choosing one is not a naming exercise: you need a clear value exchange, multiple plausible candidates, an exact metric contract, evidence or an explicit hypothesis for the business link, a credible path for Product influence, and guardrails against harmful optimization.

The metric is not "true" because a workshop selected it. It is a strategic measurement hypothesis that should become more or less credible as the team learns.

That framing is the whole point of this guide. A North Star is a decision about what the team believes value is and how that value becomes a healthy business. Like any decision, it should be inspectable, falsifiable and revisable.

This page teaches the reasoning behind that choice. When a team is ready to define, audit or record the actual candidate, the North Star Metric Finder is built for that job: it turns the framework into an exact metric contract, an evidence state for the business link, inputs, guardrails and a decision trace. This page owns the method behind that choice.

Table of contents

• The direct answer: a North Star Metric is a strategic measurement hypothesis
• A North Star is not a KPI, a target, an input, or a guardrail
• Start from the customer value exchange, not the dashboard
• North Star Candidate Stress Test
• Metric Contract Clinic: a name is not a definition
• Direction is not always "up"
• The business link: correlation is not causation
• Inputs are levers and hypotheses, not a formula
• Gaming and Guardrail Lab
• Guardrails are first-class, not an afterthought
• One North Star or split the scope?
• Company, product and team level: avoid North Star inflation
• A North Star is not a mission and not an OKR
• Candidate Repair Lab: how a weak metric becomes defensible
• Worked example: a productivity product where time spent inverts value
• Worked example: a marketplace where supply growth is not value
• Segments and cohorts: one number can hide a problem
• When to revisit the North Star
• "We do not have enough data yet"
• No false precision
• Common North Star failure modes
• Decision clinic: the situations teams actually bring
• The value-to-metric system, end to end
• References and further reading

The direct answer: a North Star Metric is a strategic measurement hypothesis

A useful North Star does five jobs at once:

1. It represents value the customer actually receives. Not activity, not attention for its own sake, not a count that only looks healthy.
2. It sits at a defined scope. One product, one business area, or one company-level value system, not "everything we do".
3. It has an exact definition. Entity, event, aggregation, window, segment, exclusions and direction are all decided, not implied.
4. It has a credible and honestly labeled link to sustainable business performance. That link can be supported, hypothesized or still unknown.
5. It comes with guardrails. Measures that protect against winning the metric while harming the product.

A North Star is not a law of nature. It is the team's best current answer to: what repeated customer value, if we deliver more of it, should produce a healthier business? If that answer is wrong, the metric becomes an expensive distraction. If the answer is undocumented, nobody can tell whether it was ever right.

The rest of this guide is the machinery for making that answer defensible.

A North Star is not a KPI, a target, an input, or a guardrail

Teams blur six different things into one conversation. Keeping them distinct prevents most North Star arguments.

Some consequences:

• The North Star is a KPI, but not every KPI is a North Star. Revenue is usually an important business KPI; that does not make it a good Product North Star.
• "Reach $10M ARR" is a target, not a metric definition. A target without an exact metric contract is just a wish with a number on it.
• A metric and its target are different objects. You can change the target without touching the metric, and you should be able to change the metric without pretending the target was the definition.
• An input is not automatically a component of a formula. "Onboarding completion influences the North Star" is a hypothesis until someone shows it is a mathematical identity.

When a North Star discussion feels circular, it is usually because two people are using one of these six words differently.

Start from the customer value exchange, not the dashboard

Before any candidate metric, answer two questions in writing.

What does the customer receive? The meaningful result, not the click that precedes it.

• Work completed or a job finished.
• A successful, trusted transaction.
• Useful content consumed or a skill advanced.
• Progress toward a goal the customer already had.
• Reduced effort, risk or uncertainty.
• A connection or match that would otherwise not happen.
• A problem resolved.

What does the business receive when that customer value is repeatedly delivered?

• Renewal or repeat purchase.
• Transaction fees or take rate.
• Subscription revenue.
• Monetizable, sustained attention.
• Supply participation or liquidity.
• Referral and efficient acquisition.

The North Star should sit near the customer-value side while staying credibly linked to the business side. It should not be pulled all the way to either pole:

• A pure business measure such as revenue usually cannot be moved by Product directly, and it tells you what already happened.
• A pure activity measure such as page views or logins often rises without any value being delivered.

Do not define a North Star from revenue, page views, signups, raw MAU or clicks unless context makes that metric genuinely represent delivered value. "Active" is not value by default, it depends on what the activity means.

A useful test: write the value exchange as a sentence between two parties.

Customer receives a resolved incident with confidence the fix will hold. Business receives continued subscription because the operations team trusts the workflow.

If you cannot write that sentence, no metric choice will save the discussion, because the team does not yet agree on what the product is for.

North Star Candidate Stress Test

This is the primary decision aid. It does not produce a score, a ranking or an arithmetic winner. Selection is always explicit Product judgment. The point is to make the judgment inspectable.

For each candidate, ask the ten questions below and record the answer. If a candidate fails hard on any one, either repair it, add a guardrail, or reject it.

1. Value representation

When this metric improves, what customer value was actually delivered?

If the honest answer is "more people clicked" or "more sessions started", the metric may represent activity rather than value. Name the value event, not the interaction.

2. Value recurrence and durability

Does the metric represent repeated Product value, or a one-off acquisition event?

Not every product needs high-frequency use. A wedding-planning tool, an annual tax product or a home-sale marketplace may deliver enormous value rarely. Do not blindly prefer frequency; match recurrence to how the customer's job actually recurs.

3. Business link

What sustainable business outcome should move if this customer value keeps being delivered, renewal, transactions, expansion, margin, liquidity, retention?

Record the evidence state explicitly:

• Supported, you have relevant evidence from your own data or a documented mechanism.
• Hypothesis, plausible and reasoned, not yet demonstrated.
• Unknown, you genuinely do not know yet.

Require a rationale for whichever state you choose. "Supported" without evidence is just confidence.

4. Product influence

Can teams influence meaningful inputs that should move this metric?

Do not require direct or weekly control over the North Star itself. A good North Star is often deliberately one step out of reach, so that teams reason about causes instead of yanking the number. If no input is actionable, the metric is not a useful steering signal.

5. Metric semantics

Can the metric be defined exactly enough that two analysts compute the same number?

You need entity or population, aggregation, numerator and denominator where relevant, time window, segment, inclusion and exclusion rules, unit, and direction. If the definition changes by dashboard, it is not ready to be a North Star.

6. Gaming and perverse incentive

How could the team move the number while reducing customer value?

If the answer is "easily", add guardrails, refine the candidate, or reject it. A metric that rewards a behavior the team can inflate without helping the customer is an incentive to harm the product.

7. Segment and mixing risk

Could growth in one segment hide deterioration in another?

A single top-line number can rise because the customer mix changed, even while every segment got worse. You should be able to inspect the metric by the segments that matter.

8. Strategic fit

Does this metric reflect the Product strategy the team is actually pursuing?

A metric that quietly encodes yesterday's strategy will keep pulling the team toward it. If strategy moved upmarket, toward self-serve, or toward a new use case, check whether the metric still points that way.

9. Decision usefulness

If this metric changes, what decision becomes clearer?

A North Star is a steering instrument. If you cannot name a decision that would change when it moves, it may be interesting but not actionable.

10. Closest alternative

Why this candidate instead of the strongest alternative?

Write down the alternative you rejected and the reason. A choice made against a real alternative is a decision. A choice made in isolation is a preference.

Metric Contract Clinic: a name is not a definition

Two teams can both say "weekly active teams" and mean different numbers. The name is not the metric; the contract is.

Consider the vague version:

Weekly active teams

Questions it leaves unanswered:

• What counts as active, login, page view, or a meaningful action?
• Which teams, all accounts, or only paid ones?
• Unique teams, or sessions?
• Calendar week, or a rolling seven days?
• Which timezone, and does it reset mid-week for some customers?
• Free and paid together, or paid only?
• Are internal, test and demo accounts included?
• Does one trivial action count the same as a deep one?
• Is higher better, or are we aiming for a healthy range?
• Owned by whom, and sourced from which table?

A defensible contract looks more like this hypothetical example:

Unique paid customer workspaces that complete at least one defined collaborative value event during a Monday–Sunday UTC calendar week, excluding internal, test and demo accounts. Higher is the intended direction. Owned by the Collaboration Product team; sourced from the workspace_value_events table.

That sentence is not bureaucracy. Each clause removes a way the metric could be quietly gamed or computed two different ways.

The fields a serious contract can carry

Not every metric needs every field, but a serious definition usually answers most of these:

• Name, what people call it.
• Scope, the product or business system it represents.
• Entity / population, who or what is being counted or measured.
• Value event / unit, what has to happen to count.
• Aggregation, count, unique count, sum, average, median, percentage, rate, ratio, duration or formula.
• Numerator and denominator, only when the metric is genuinely a rate or ratio.
• Segment, which group the metric is defined over.
• Inclusion rules, what counts.
• Exclusion rules, internal accounts, bots, refunds, cancelled items, test data.
• Time window, calendar week, rolling 7 days, cohort month, and the timezone.
• Direction, higher, lower, target range, context-dependent, or unknown.
• Data source, the table or event that produces it.
• Owner, the team accountable for the definition.
• Baseline, the current value, with a date and context.
• Target, only if you are actively managing to one.

Two errors are especially common. First, adding a second quantity to a metric and silently treating it as a division. A metric with a numerator and a denominator is a rate; many metrics are not, and forcing a division changes the meaning. Second, assuming a direction. Blank definitions should not silently default to "higher is better".

If a contract has open questions that need a real decision, formalize it in the North Star Metric Finder, which is built to preserve exactly these fields and the reasoning behind them.

Direction is not always "up"

Metric culture tends to assume that a higher number is always better. A North Star should state its direction explicitly, and sometimes the honest answer is not "up".

• Higher is better, successful completed transactions, trusted matches, resolved cases.
• Lower is better, time to successful issue resolution, or error rate, when faster or fewer genuinely represents customer value and quality guardrails protect against cutting corners.
• A target range, some marketplace or supply metrics are healthy inside a band rather than maximized. Too little supply starves the market; too much can signal low quality or eroded margins.
• Context-dependent, the meaning depends on the product model or segment, and the team should say so rather than pretend.
• Unknown, not yet determined, and honestly recorded as such.

The trap is optimizing a ratio in the wrong direction. If "cost per resolved case" is treated as a North Star with a naive "lower is better" instinct, teams can starve the support experience. Direction is a decision, not a default.

The business link: correlation is not causation

A candidate often looks attractive because customers with higher metric values also retain, renew, pay more or expand. That is genuinely useful, and frequently misread.

Ask the harder question:

Does the metric cause more business value, or do already-healthy customers simply produce more of the metric?

Common confounds:

• Customer maturity, older accounts have had more time to accumulate the metric.
• Company size, larger customers naturally generate more activity and also have more budget.
• Self-selection, customers who were already committed used the product more from the start.
• Tenure and plan tier, paid, long-tenured customers differ from the base in many ways at once.
• Seasonality, both the metric and revenue may move together because of the calendar.
• Acquisition source, high-intent channels can produce both engaged users and better revenue.

Historical correlation is evidence, not automatic causality. It can strengthen or weaken the choice, and it should be labeled for what it is. A more honest vocabulary:

• Observed association, the two moved together in the data we have.
• Plausible mechanism, there is a reason to think one drives the other, even without proof.
• Supported hypothesis, association plus mechanism plus some discriminating evidence.
• Unresolved causal uncertainty, we do not yet know, and we are saying so.

None of this means every North Star needs a controlled experiment before it can be used. It means the team should stop presenting a correlation as proof. Label the evidence state and move forward with a name for what is still unknown.

A useful rule: if you cannot say what evidence would lower your confidence in the business link, you have not really defined one.

Inputs are levers and hypotheses, not a formula

Inputs are the more actionable measures a team believes can move the North Star. They are where day-to-day Product work usually shows up, because the North Star itself is often deliberately out of direct reach.

That does not license invented arithmetic. Keep three kinds of relationship distinct:

• Mathematical identity, an exact relationship that is true by definition. Revenue = transactions × average order value is an identity only when the definitions genuinely support it and units line up.
• Mechanistic or influence hypothesis, a reasoned belief that one thing affects another. Better onboarding may increase repeated value events; that is a hypothesis, not an equation.
• Observed association, the two have historically moved together, with no established mechanism.

Do not write North Star = Input A × Input B × Input C unless that relationship is a real identity. Most input systems are influence systems, and presenting them as formulas creates false confidence and false precision.

Two further cautions:

• No universal count. There is no law that a North Star must have exactly three or five inputs. Choose the inputs that are genuinely actionable and important enough to steer, and accept that the set is provisional.
• Act on inputs, not on the North Star number. A common failure mode is over-focusing on the North Star itself and starving the very levers that move it. Inputs are usually the better weekly conversation.

When you need to model a full driver system, including real identities, decomposed rates and diagnostic scenarios, that is a different job: use the KPI Tree Builder. It keeps mathematical identities, influence relationships, alignment and unknowns semantically separate.

Gaming and Guardrail Lab

A metric is only as good as the behavior it rewards. The table below shows, for plausible North Star candidates, how a team could move the number while reducing customer value, and what guardrail would catch it. The examples are hypothetical and deliberately generic; the specific guardrails depend on your product.

The governing rule: if a metric can be improved while customer value gets worse, the North Star needs guardrails or a better definition.

A guardrail is not proof that a metric is bad. It is the acknowledgment that any single number creates an incentive, and that the incentive should be balanced by something the team also cares about.

Guardrails are first-class, not an afterthought

A North Star should never be presented alone. The first question is not "what should we maximize?" but "what could get worse while this improves?"

Guardrails may protect:

• Quality, correctness, completeness, acceptance.
• Safety and trust, abuse reports, fraud, trust incidents.
• Latency and reliability, response time, error rate, uptime.
• Support burden, ticket volume, escalation rate, resolution time.
• Churn and retention, the outcome you were trying to improve.
• Margin, unit economics that a growth metric can quietly erode.
• Fairness, whether one segment is being exploited to lift the average.
• Supply and demand health, for marketplaces and platforms, liquidity on both sides.

Two cautions:

• Include only contextually relevant guardrails. There is no universal list of five. A B2C media product and a regulated fintech product need different protections.
• Do not collapse guardrails into a single composite score. A blended score reintroduces exactly the arithmetic certainty the North Star conversation was trying to avoid. Keep the guardrails separately visible so the team can see which one moved.

One North Star or split the scope?

The default discipline is one North Star for one coherent Product or value system. Focus is the point. But forcing a single metric across genuinely different businesses produces a number that means nothing everywhere.

Work through these questions for the scope in question:

1. Same customer? Are we measuring the same population, with the same definition?
2. Same value exchange? Does the customer receive the same kind of value?
3. Same Product strategy? Are we pursuing the same strategic direction?
4. Same economic model? Does the business earn money the same way?
5. Same decision system? Would the same people act on the same signal?

If the answer is largely yes: one North Star will create useful focus.

If the answer is materially no: separate North Stars for separate scopes are more honest than a blended compromise.

Situations where splitting may be justified:

• A marketplace whose buyer product and seller product have very different value systems.
• A company with independent business lines that share little more than a brand.
• A product suite serving unrelated customer bases with different jobs.
• A platform where supply-side health and demand-side value cannot be expressed as one measure without destroying both.

What splitting does not mean:

• Every team does not need its own North Star. That is North Star inflation, not focus (see below).
• Splitting the scope is not an excuse to avoid agreeing on what value means. Each scope still needs a defensible value exchange.
• A single company-level North Star can coexist with product-level or area-level North Stars, as long as the levels are explicit and not competing for the same decision.

The scope router test is simple: if two candidates would lead two different teams to opposite decisions, they probably belong at different scopes.

Company, product and team level: avoid North Star inflation

Levels are useful. Confusing them is not.

• Company North Star, a broad anchor for the customer value the whole business ultimately delivers. Often closer to a portfolio-level statement than to a single product behavior.
• Product North Star, appropriate when a product has a coherent, independent value exchange. This is the level most of this guide addresses.
• Team metric, driver or input, what a team usually should own. A team normally does not need to invent a "North Star" simply to have a local goal.

A team can own an input, a driver, a guardrail or an outcome that ladders to a larger Product North Star without claiming a separate one. This keeps the metric system honest and prevents the situation where every squad declares its own North Star and no one can tell which one matters.

If every team has a North Star, the organization effectively has none.

A North Star is not a mission and not an OKR

Two adjacent concepts are worth distinguishing briefly.

Mission is a qualitative, long-term purpose. A North Star is a measurable representation of Product value at a defined scope. No metric fully captures a mission; the metric is a useful operational abstraction, not a substitute for purpose.

OKRs are a time-bounded goal system:

• An Objective is a qualitative goal for a period.
• A Key Result is a measurable result used to assess that objective.

A Key Result may reference the North Star, an input or a guardrail. But the North Star itself is not the OKR system. The North Star is the durable anchor; OKRs are how a team commits to moving something for a quarter. If you need the full goal-setting method, use the OKR guide rather than stretching the North Star to do that job.

Candidate Repair Lab: how a weak metric becomes defensible

The fastest way to learn the framework is to watch a metric get better through reasoning. This example is hypothetical and deliberately labeled as such.

Context. A B2B workflow product helps operations teams resolve incidents.

Candidate 1: Weekly Active Users. Weak. Activity may reflect incident volume rather than customer value. If incidents increase, users may open the product more while the customer's life gets worse. It says nothing about whether incidents were actually resolved.

Candidate 2: Incidents resolved. Better, still incomplete. A trivial incident counts the same as a severe one. There is no quality dimension, so the team could close tickets rather than solve problems. And it mixes team size and volume: a big customer will always "win" on raw counts.

Candidate 3: Customer workspaces completing at least one qualified incident resolution within the defined service window. Closer to value. Now walk it through the stress test:

The candidate is not finished just because it sounds better. It still needs an exact contract and guardrails. But the reasoning has changed the question from "what number looks good?" to "what does this number actually claim, and what would make it wrong?"

Guardrails for this example:

• Reopen rate, resolved incidents that come back.
• Severity handling, whether serious incidents are being resolved, not just many trivial ones.
• Customer satisfaction or support escalation, the human outcome behind the ticket.
• A quality measure appropriate to the domain, for example, resolution accuracy where it can be checked.

None of these is a universal rule. The point is that the guardrails answer the question "what would this metric let us get away with?"

Worked example: a productivity product where time spent inverts value

Another hypothetical, chosen because it breaks a common instinct.

Context. An AI document-analysis product. The customer's job is to get a reliable answer from a document quickly.

Weak candidate: minutes spent in app. In a productivity product, more time can mean the product is failing. If the analysis is good, the customer leaves sooner.

Candidate direction: successful analysis jobs completed to a user-accepted output. Now the reasoning:

• Success definition. What makes an analysis "successful"? A completed run is not enough; the output has to be trusted and used.
• Entity. Are we counting documents, jobs, users or accounts? A single user analyzing 50 documents is a different signal from 50 users analyzing one each.
• Quality. Confidence, accuracy and false positives matter, because a fast wrong answer is worse than a slow right one.
• Latency and cost. A "completed job" that takes too long or costs too much is not durable value.
• Repeat usage. Does accepted output lead to a second job? That is the recurrence signal.
• Paid value. Does accepted output relate to conversion, expansion or renewal? That is the business-link hypothesis to test.

Lesson: engagement duration can invert customer value in productivity products. "More time" is not a safe default; the value event has to be named.

Worked example: a marketplace where supply growth is not value

One more hypothetical, because marketplaces tempt teams toward volume metrics.

Context. A two-sided marketplace.

Weak candidate: listings created. Supply growth is not value. More listings can mean more spam, lower quality and a worse buyer experience. The number rises while trust falls.

Stronger candidate family: successfully completed matched transactions, with the recognition that even this needs quality guardrails.

Guardrails to consider:

• Cancellation rate, matches that fall apart.
• Refund rate, transactions the customer regretted.
• Trust and safety incidents, the cost of ignoring fit.
• Repeat rate, whether buyers and sellers come back.
• Supply concentration, whether a few large sellers are masking a thin market.

There is no single universal marketplace North Star. A services marketplace, a goods marketplace and a rental marketplace have different value exchanges. What they share is that raw supply and raw transaction counts are incomplete on their own.

Segments and cohorts: one number can hide a problem

A single top-line North Star can improve while part of the business gets worse. Composition changes are one of the most common forms of metric theater.

The question is not "should we split the North Star by every segment?", usually not. The question is whether the metric should be inspectable by the segments where a mix shift could change the story:

• Customer segment or tier.
• Plan or pricing level.
• Geography.
• Acquisition source.
• Tenure or cohort.
• Use case or job.
• Customer size, for B2B.

Use segment views to detect:

• Composition shifts, the average rose only because the mix changed.
• Simpson's-paradox-like effects, ahead overall, behind in every segment, or the reverse.
• Growth masking deterioration, one large segment carrying a declining core.

Do not split the North Star merely because segment reporting exists. Split the view, not the anchor. And when the segment analysis itself becomes the hard part, that is a method job for the cohort analysis guide.

When to revisit the North Star

The old advice was a universal cadence: review weekly, diagnose monthly, recalibrate quarterly. That is not a law. Cadence should follow the product cycle, data latency, metric frequency, business model, decision rhythm and seasonality. Reviewing the metric operationally on a schedule is fine; changing it should be evidence- or strategy-triggered, not calendar-driven.

Revisit the choice when:

• Product strategy changes, the metric points at yesterday's direction.
• The value exchange changes, what the customer receives is no longer what the metric measures.
• The business model changes, a new monetization model can invalidate the business link.
• Go-to-market or customer mix changes, a new segment can make the old metric unrepresentative.
• The product expands into materially distinct lines, one metric may no longer fit the scope.
• The metric becomes gameable, the team found a way to move it without helping customers.
• Guardrails deteriorate while the North Star improves, the clearest warning sign.
• The business outcome stops moving with the metric, the hypothesized link is not holding.
• The definition loses relevance or becomes impossible to measure consistently.
• Instrumentation changes, a new event model can silently redefine the number.
• New evidence contradicts the assumed mechanism.
• The market changes, customer behavior can move in ways the original choice did not anticipate.

A North Star should be durable enough to align the team, and honest enough to be replaced when reality changes. Those are not in conflict: durability is a property of the reasoning, not of clinging to the first metric.

"We do not have enough data yet"

Early products rarely have enough history to prove a retention, revenue or causal link. That is not a reason to avoid choosing. It is a reason to label the uncertainty.

Write down three things:

• Known, the value behavior you have observed, and what it suggests.
• Hypothesis, why you believe this behavior connects to sustainable business health.
• Unknown, what evidence would strengthen, weaken or settle the belief.

Then choose a provisional North Star if it helps the team focus, and document the uncertainty alongside it. Revisit as data accumulates. This is consistent with the view, reflected in Amplitude's North Star guidance, that the first North Star is a hypothesis, and that a strong one can and should evolve.

A provisional metric with a named unknown is far more useful than a confident metric with a silent assumption.

No false precision

Do not invent rigor the evidence does not support. Specifically, avoid:

• A minimum correlation coefficient for the business link.
• A "70% retention correlation" style rule.
• A minimum sample size required before choosing.
• A "three to five inputs" requirement.
• A universal review frequency.
• A minimum historical window.
• A universal guardrail count.
• A North Star readiness score.
• A confidence percentage on a judgment.

If a real statistical analysis supports a choice, explain the method, the data scope, the uncertainty and the limitations. But the framework does not require a quantitative model, and adding numbers the team cannot defend makes the choice weaker, not stronger.

Common North Star failure modes

These are the patterns worth naming in a review.

• Vanity North Star, the metric grows without delivered value: signups, page views, raw MAU when untethered from value. These are not always vanity; context decides.
• Revenue-only North Star, captures business value but not customer value. Often a fine company KPI, usually a weak Product North Star.
• Engagement trap, optimizes time or usage even when efficiency would create more value.
• Input masquerading as North Star, a local lever is mistaken for the durable anchor.
• Target masquerading as metric, "reach $10M ARR" is a goal, not a precise Product value metric.
• Definition drift, different teams compute the same metric differently.
• Segment mixing, the top line rises because the composition changed.
• Gaming, teams learn to move the metric without improving the product.
• Causality theater, historical correlation is presented as proof.
• North Star inflation, every team invents its own North Star.
• Frozen North Star, strategy changed, the metric did not.

Each of these has a specific repair: sharpen the value exchange, relabel the evidence, add a guardrail, fix the contract, or revisit the scope.

Decision clinic: the situations teams actually bring

A quick reference for the cases that come up most often.

The value-to-metric system, end to end

Put together, the reasoning looks like this:

Customer value exchange
        |
        v
North Star candidate(s)
        |
        v
Exact Metric Contract
  (entity, event, aggregation, window, segment, exclusions, direction)
        |
   +----+----------------+------------------+
   |                     |                  |
   v                     v                  v
Inputs              Guardrails          Business link
(levers and         (protect against    (Supported /
 hypotheses)         known harm)         Hypothesis / Unknown)
   |                     |                  |
   +----------+----------+------------------+
              |
              v
   Product decisions / learning
              |
              v
   Revisit if evidence or strategy changes

Four things to read into that diagram:

• Inputs are not automatically a mathematical formula; they are levers and hypotheses.
• The business link can be a hypothesis or unknown; it does not have to be proven on day one.
• Guardrails protect against gaming; they are part of the decision, not a footnote.
• Learning can cause revision. A North Star that never changes may be a North Star nobody is testing.

If you want to make the actual decision concrete, generate candidates, write the contract, record the evidence state, define inputs and guardrails, and keep the decision trace, the North Star Metric Finder turns this framework into an inspectable artifact. If you need the full metric system underneath it, including real identities and driver decomposition, continue into the KPI Tree Builder. If the harder problem is the strategy itself, start with the Product Strategy One-Pager instead of forcing a metric to carry a strategy that does not exist yet.

Related specialist jobs: the activation metric guide owns early-value signal design, the retention strategy guide owns repeated-value system design, and the product analytics instrumentation guide owns the measurement contract behind the events. Use them when the next job is theirs, not this page's.

References and further reading

• Amplitude, North Star Playbook: About the North Star Framework. Framework for representing customer value in a metric that is within Product and Marketing's sphere of influence and acts as a leading indicator of revenue. Treated here as an influential framework, not as an immutable law.
• Amplitude, What Makes a Good vs Bad North Star Metric (original publication 2024-08-15; live 2026). Current guidance that the first North Star is a hypothesis, that the metric can evolve, that inputs are influential factors rather than required arithmetic, and that vanity and lagging metrics are poor candidates.
• Amplitude, North Star Playbook: Troubleshooting and Changing your North Star. Guidance that over-focusing on the North Star instead of inputs is a failure mode, that separate lines of business may justify separate North Stars, and that the North Star can change as strategy, market and product evolve.

Company-specific North Star examples circulate widely, but they are context-specific, often historical and frequently unverified. This page deliberately avoids repeating them as current facts. Where an example is used, prefer a clearly labeled hypothetical or a framework owner's documented case.

If you are preparing for a metrics interview rather than choosing a metric for a real product, the PM metrics interview guide owns that job. If you need to define or audit your actual candidate, the North Star Metric Finder is the next step.