Choosing a North Star Metric That Captures Value, Not Just Activity

A strong North Star metric measures value delivered to customers, not activity performed near your product. It should correlate with revenue, be predictive of retention, and move when the team ships real improvements — not just when marketing drives more logins. Pick a value-based unit like "weekly active projects created," not an activity count like logins or sessions.

Quick Answer: Choose a North Star that (1) reflects a customer completing a real unit of value, (2) predicts revenue or retention, and (3) is movable by product and engineering work — not just by marketing spend. Then build an input-metrics tree connecting daily team actions to it.

Most teams inherit a North Star metric instead of choosing one deliberately. It arrives from a board deck, a growth playbook, or whatever Amplitude dashboard already existed, and nobody revisits whether it actually reflects the thing the business needs to be true. That's how "monthly active users" — arguably the most activity-shaped metric in software — became the default North Star for a decade of companies that would have been better served by something narrower and more honest.

This matters because a North Star metric is not a KPI you report quarterly. It's meant to function as the organizing principle for prioritization, the tiebreaker in roadmap debates, and the single number a cross-functional team can rally behind. Get it wrong and you don't just have a vanity dashboard — you have a company optimizing for the wrong behavior at scale.

What Makes a Metric Qualify as a True North Star

A true North Star metric satisfies three tests simultaneously: it reflects value the customer actually experienced, it correlates with future revenue or retention, and multiple teams can influence it through real product work. Most metrics that fail as North Stars fail on the first test — they measure that something happened, not that something valuable happened.

Sean Ellis and the growth community popularized the North Star concept in the 2010s, and Amplitude's own North Star Playbook (built from work with hundreds of growth teams) crystallized the framework most companies use today: a North Star should sit at the intersection of customer value and business value, expressed as a rate over time, not a cumulative count.

Three criteria separate a durable North Star from a metric that merely looks impressive on a slide:

1. Value-reflective: the metric only increases when a customer completed a meaningful unit of work in your product — not when they merely opened it.
2. Leading, not lagging: it should move before revenue does, giving the team an early signal rather than a rear-view mirror.
3. Team-movable: at least three or four different functions (product, engineering, growth, content) should each have a lever that visibly moves the number.

The Test That Trips Up Most Teams: "Would a Bot Move This?"

Ask whether a script that logs in and clicks around without accomplishing anything would inflate the metric. If yes, it's activity-based. Daily active users, session count, and page views all fail this test — a curious, confused, or even automated visitor moves them identically to a satisfied one. A metric like "documents completed" or "projects shipped" cannot be faked this way, because completion requires the underlying job to actually get done.

This single test eliminates most of the metrics teams default to, because engagement-tracking tools are built to count activity cheaply, and activity is what gets surfaced first in any analytics tool's default dashboard.

Value-Based vs. Activity-Based North Stars, Side by Side

A value-based North Star measures completed customer outcomes; an activity-based one measures interactions with the product regardless of outcome. The practical difference shows up fastest in what each metric rewards a growth team for doing — pushing notifications to reopen the app, versus building faster paths to the customer's actual goal.

Airbnb's own account of its growth metric evolution — described in public talks by its data science leadership — is instructive: they moved away from raw visits toward "nights booked," because visits could spike from marketing stunts that never produced a stay. That shift from activity to value is the same move you're being asked to make here.

Why Activity Metrics Persist Anyway

Activity metrics survive because they're easy to instrument and easy to grow short-term. A redesigned onboarding email can lift logins in a week; getting more customers to a genuine value-completing action usually takes real product investment. Teams under quarterly pressure gravitate to the metric that moves fastest, even when it's the wrong one.

The honest fix isn't banning activity metrics — they're still useful as input metrics (see below). The fix is refusing to let them sit at the top of the tree as the company's stated goal.

Building the Input-Metrics Tree That Connects Daily Work to the North Star

An input-metrics tree decomposes your North Star into the two or three upstream levers that actually drive it, so an engineer's Tuesday ticket has a traceable line to the company's stated goal. Without this tree, a North Star becomes an abstraction nobody's actual work visibly affects — which is the fastest way for a team to quietly stop believing in it.

The standard structure has three layers:

• Layer 1 — North Star: the single value-based outcome metric (e.g., weekly active projects created).
• Layer 2 — Input metrics: the 3-5 factors that mathematically or causally drive Layer 1 — typically split into breadth (how many customers engage), depth (how much value each gets), and efficiency (frequency or speed of completing the loop).
• Layer 3 — Team-level metrics: the specific, controllable numbers each squad owns — onboarding completion rate, time-to-first-project, template usage rate — that roll up into Layer 2.

For a project-management tool whose North Star is weekly active projects created, a plausible tree looks like this:

This structure is what lets a systems-thinking view of the product actually hold together — each layer is a causal input into the one above it, so tracing loops and second-order effects, the same discipline covered in a broader look at systems thinking for product teams, becomes tractable instead of hand-wavy.

Watch for Metrics That Look Causal but Aren't

A common trap: choosing an input metric that correlates with the North Star only because both are driven by a third factor (e.g., account size), not because the input causes the output. Before locking an input metric into the tree, ask whether moving it in isolation — through an A/B test, not just an observed correlation — actually moves the North Star. If you can't test it, treat it as provisional.

Where the North Star Metric Should Show Up in Product Decisions

A North Star metric only earns its name if it's visibly present at the moment decisions get made — in prioritization debates, in spec reviews, and in the retro where a team asks whether the last quarter's work actually moved anything. A metric that lives only in a quarterly slide isn't a North Star; it's a report.

Three places it needs to be load-bearing:

1. Prioritization frameworks. When scoring initiatives with something like RICE or Kano, the "impact" input should be explicitly tied back to the North Star's input-metrics tree, not left as a gut-feel 1-5 rating.
2. The customer's actual path to value. The North Star should describe the moment in the customer journey where value was genuinely delivered — which is the same moment covered in depth in analyses of the aha moment and time-to-value as the first key action a customer takes.
3. Retros and post-launch reviews. Every shipped feature should be checked against whether it moved a Layer 2 or Layer 3 metric — not just whether it shipped on time.

A Quick Diagnostic for an Existing North Star

If your company already has a North Star, three quick questions test whether it's actually doing its job: Would a bot moving through your product inflate it? Does it show up in your last five roadmap prioritization decisions? Has anyone on the team recalculated it manually in the last quarter, rather than just glancing at a dashboard? Two "no" answers suggest it has drifted into a vanity number worth revisiting — a process closer to running the customer-journey mapping exercise fresh than to a spreadsheet tweak.

Keeping the North Star Honest as the Company Scales

The hardest part of a North Star metric isn't choosing it — it's keeping it as the team's actual shared reference point once a company has multiple squads, multiple roadmaps, and multiple stakeholders each pushing their own priority. The metric doesn't decay because the definition changes; it decays because nobody keeps it visibly attached to the decisions being made day to day.

This is the same problem a living PRD is meant to solve at the feature level, and it's the honest version of the Prodinja tie-in: Prodinja's Spec Studio living PRD, with its readiness gates, is designed to keep a team's stated goal front-and-center through every stage of a spec's life — mirroring how a North Star metric is supposed to anchor every roadmap and prioritization decision, not just headline a slide once a quarter. Neither is a substitute for choosing the right metric in the first place; both are mechanisms for making sure the choice actually gets used.

Key Takeaways

• A true North Star reflects delivered customer value, not activity — test it by asking whether a bot clicking through your product would inflate the number.
• Value-based metrics correlate with revenue; activity-based metrics like logins or DAU are easy to game with notifications and marketing pushes.
• Build a three-layer input-metrics tree (North Star → input metrics → team metrics) so every team's daily work has a traceable line to the company goal.
• Verify causality, not just correlation, before locking an input metric into the tree — a metric can move alongside the North Star without actually driving it.
• A North Star only works if it shows up in real decisions — prioritization scoring, customer-journey analysis, and post-launch retros — not just a quarterly slide.
• Revisit the North Star periodically using a simple diagnostic: does it appear in recent roadmap decisions, and has anyone recalculated it by hand recently?

Frequently Asked Questions

What is a North Star metric in product management?

A North Star metric is the single measure a company uses to represent the core value it delivers to customers, chosen so that improving it also grows the business. It's meant to align prioritization, roadmap, and cross-functional decisions around one shared, value-based number rather than department-specific KPIs.

Should DAU or MAU ever be a North Star metric?

Rarely, and only as a proxy when nothing better exists yet. DAU/MAU measure that someone opened the app, not that they got value from it, so they're easily inflated by notifications and marketing pushes without reflecting real customer outcomes — better used as an input metric than as the North Star itself.

How many input metrics should feed a North Star?

Most frameworks recommend 3-5 input metrics split across breadth (how many customers engage), depth (how much value each one gets), and efficiency (how quickly they get it). More than five tends to dilute focus and make the tree hard for teams to actually track.

How often should a company change its North Star metric?

Rarely — a North Star should hold steady for at least a year or two so teams can build genuine muscle memory around it, but it's worth revisiting during a major business model shift (e.g., moving from single-player to collaborative use) or if a diagnostic check reveals it's stopped predicting revenue.

Can a B2B company use the same North Star approach as a consumer app?

Yes, with a different unit — instead of consumer engagement loops, B2B teams often anchor on a value-based unit tied to the buying team's job-to-be-done, such as "reports published" or "workflows automated," which is where framing the metric through the lens of jobs-to-be-done rather than raw usage tends to produce a more honest choice.