Product KPIs and Metrics: From North Star to Metric Tree

Product KPIs and Metrics: From North Star to Metric Tree

Product teams are often asked: "what is your success metric?" Mind the Product emphasizes that the value of metrics is not their quantity but whether they point to real user value. From a North Star metric to AARRR, and then to OKRs and a metric tree, a good metric system turns "are we doing well" from a feeling into a testable judgment.

The North Star Metric: Find the One Metric That Matters

The North Star Metric is the single metric that best reflects the long-term value a product delivers to users. It must point in two directions at once: forward, it corresponds to the product mission and user value; backward, it correlates positively with the business model and revenue growth. Content platforms often use "weekly active readers," while SaaS products use "active workspaces" or "weekly collaborations." The key when choosing a North Star metric: when it moves, the team can judge whether they are truly closer to the vision. The AARRR pirate metrics are a common supporting framework: Acquisition, Activation, Retention, Referral, and Revenue.

Aligning Goals with OKRs

OKR (Objectives and Key Results) cascades the company vision down to teams and individuals: the Objective is a qualitative goal, and Key Results are the quantitative results that measure whether it is met. OKR and KPI are often confused — KPIs are "health metrics" monitored continuously, while OKRs are "change goals" pushed forward in cycles. Taking "improve activation" as an example, a KPI would be "new-user activation rate of 35% per week," while an OKR might be "O: get new users to experience core value; KR1: raise activation to 45%; KR2: 60% of users complete onboarding." When defining business analysis metrics, see the Business Analyst Guide.

Building a Metric Tree

A metric tree decomposes the North Star metric layer by layer into actionable second- and third-level metrics, so every team can find "the number they can influence." For example, "weekly active readers" can be decomposed into "new readers x new-reader activation + returning readers x return rate." When decomposing, distinguish three types of metrics: outcome metrics, behavior metrics, and leading/lagging metrics. Leading metrics predict future results; lagging metrics record what already happened. Healthy products usually track both.

A complete e-commerce example

Let's put the concepts into a concrete scenario. Suppose an e-commerce SaaS uses "Weekly Active Paying Merchants" as its North Star metric. The metric tree can decompose like this:

A matching quarterly OKR could read: O: "get new merchants to their first sale faster"; KR1: raise first-purchase conversion from 18% to 28%; KR2: cut average time-to-first-sale from 11 days to 7; KR3: 85% of merchants finish checkout configuration.

Watch for contradictions between KRs — "shorter time-to-first-sale" and "higher checkout success" can clash: faster checkouts often mean less hesitation, but also more room for skipped verification. A metric tree exists to expose that tension, not to pile up numbers mechanically.

Common steps for building a metric tree

1. Settle the North Star: agree first on "which number is closest to long-term user value", usually decided jointly by the growth team and leadership;
2. Write the formula: expand the North Star with "+" and "×", e.g., "new x activation + existing x return";
3. Assign owners: every term maps to one team and one level-2 metric, avoiding "everyone owns the whole, nobody owns a part";
4. Add guardrail metrics: when pushing a level-2 metric, attach one or two guardrails (activation goes up but the conversion funnel must not degrade) so local optimization does not harm the whole;
5. Review and iterate: at quarter end, look at the actuals and adjust whichever assumption broke instead of clinging to the original targets.

Common Pitfalls

• Vanity metrics: cumulative downloads or page views look impressive but do not guide decisions; focus on activation, retention, and per-user value instead.
• Too many metrics: when everyone watches a different number, the team loses shared direction; unify with a North Star metric first, then give each team two to three supporting metrics.
• Watching numbers without chasing the why: numbers only give a partial picture; pair them with user research to understand the reasons. This is especially true for AI features, where you can use the Evals-Driven PRD to turn "what good looks like" into a runnable check.

FAQ

• What if the North Star metric never moves? Do not rush to swap it. Look back at which branch of the metric tree contributes most and which one drags it down, locate the issue with data, and only then decide whether to change the product, the operations, or the metric definition.
• Can KPIs and OKRs coexist? Yes, and they should. KPIs keep "health metrics" from slipping while OKRs push "change goals" forward; the two complement rather than compete.
• What if too many metrics cause internal friction? Go back to the North Star: any metric that cannot be traced back to the North Star formula should be cut or demoted to internal observation, instead of letting everyone watch a pile of unrelated numbers.

16IDC perspective

For websites and SaaS products, the recommended order for building a metric system is: define the North Star metric first, align goals with OKRs, then use a metric tree so every team finds its lever. For AI-powered site-building products, also fold model-effect metrics (such as generation quality and hallucination rate) into the metric system and validate them continuously with eval sets. For the full analysis workflow, return to the Requirements Analysis category on this site.

Source: https://www.mindtheproduct.com/the-north-star-metric/