ProductAdvanced8 min read

Product Metrics Tree

A product metrics tree is a hierarchical decomposition of your North Star Metric into the leading indicators that teams can actually move week to week. The root is the outcome the company exists to drive (e.g., 'weekly active hosts' for Airbnb). Each branch breaks the root into mathematical components (e.g., new hosts × activation rate × retention rate). Each leaf is a metric a single team owns. Done well, the tree creates a line of sight from any individual sprint to the company's outcome and prevents 'activity theater' — teams busy shipping features that don't move any branch of the tree. Amplitude's 'North Star Framework' and Reforge's 'Growth Models' both formalize this structure. KnowMBA POV: metrics trees prevent activity theater.

Also known asMetrics HierarchyKPI TreeNorth Star TreeDriver TreeMetric Decomposition

Challenge a friend Browse library

The Trap

The trap is building a metrics tree that LOOKS comprehensive but isn't actually mathematical. Teams brainstorm related metrics and arrange them visually, but the metrics don't multiply or sum to the parent. The result is a wall poster that no one uses for decisions. The opposite trap: a tree so deep and detailed that it has 80+ leaves, each owned by no one in particular. Without ownership, leaves rot — measured but never moved. The third trap: confusing inputs (effort metrics like 'features shipped') with outputs (outcome metrics like 'activated users'). Trees full of effort metrics are the most pernicious form of activity theater.

What to Do

Build the tree top-down: (1) Define the North Star — one outcome metric the company is organized around. (2) Decompose mathematically — each parent = function of its children. New users × activation × retention = active users. (3) Limit depth to 3-4 levels and breadth to 4-6 children per node. (4) Assign every leaf to one team owner. (5) Color-code each leaf by current performance vs target (green/yellow/red). (6) Review the tree monthly with leaders — every roadmap item must connect to a leaf. (7) Re-design the tree quarterly as the business model evolves.

Formula

Active Users = New Users × Activation Rate × Retention Rate (canonical example of a multiplicative tree branch)

In Practice

Amplitude's North Star Framework, codified by John Cutler and Casey Winters, formalized the metrics tree as 'one North Star metric supported by 3-5 input metrics.' For a marketplace like Airbnb, the North Star might be 'nights booked,' supported by inputs like (1) active demand-side users, (2) supply availability, (3) booking conversion rate, (4) cancellation rate. Each input becomes the metric a team owns. Reforge's Growth Models extend this with explicit user-state machines (e.g., 'active → at-risk → resurrected') making the tree dynamic. Companies using these frameworks (DoorDash, Patreon, Notion) report 30-50% reductions in 'orphan' roadmap items that don't connect to outcomes. (Source: Amplitude North Star Playbook; Reforge Growth Models program)

Pro Tips

01
Pressure-test every leaf with the question 'What sprint work would move this?' If the team can't answer, the metric is too lagging — break it down further until the leaf is something a team can move in a quarter.
02
Review the tree's leaf-to-roadmap mapping in every roadmap-planning session. Roadmap items without a leaf assignment are flagged for either re-mapping or killing. This is the single highest-leverage anti-activity-theater habit.
03
When the tree is mathematically sound, you can run sensitivity analyses. 'A 10% improvement in activation produces an X% lift in North Star — vs. a 10% improvement in retention produces Y%.' This data drives where to invest scarce roadmap capacity.

Myth vs Reality

Myth

“Every team should track 10-15 metrics”

Reality

Teams that track 10+ metrics actually move zero. The cognitive load of tracking dilutes attention. Best-in-class teams track ONE leaf metric (their owned slice of the tree) plus 2-3 guardrails (don't break X) for a total of 3-4 numbers.

Myth

“The tree should be permanent — changing it means you didn't think it through”

Reality

The tree should change every 1-2 quarters as the business model evolves. Stripe's growth tree in 2014 (developer signups → integrations → first transaction) is fundamentally different from its tree in 2024 (cross-product attach, enterprise expansion, regional growth). A tree that hasn't changed in 2 years usually means the business hasn't matured — or the tree is being ignored.

Try it

Run the numbers.

Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.

🧪

Knowledge Check

Your engineering team is shipping features at high velocity. Your North Star (weekly active users) hasn't moved in two quarters. Looking at your metrics tree, which observation is most diagnostic?

Industry benchmarks

Is your number good?

Calibrate against real-world tiers. Use these ranges as targets — not absolutes.

Metrics Tree Depth (best practice)

B2B / consumer SaaS metrics trees

Optimal

3-4 levels deep, 3-5 children/node

Acceptable

5 levels, 4-6 children

Too Deep

6+ levels

Wallpaper (unusable)

80+ leaf metrics

Source: Amplitude North Star Framework / Reforge Growth Models

Real-world cases

Companies that lived this.

Verified narratives with the numbers that prove (or break) the concept.

📈

Amplitude (North Star Framework)

2018-present

success

Amplitude codified the 'North Star Framework' in 2018 (John Cutler, Casey Winters, et al.) as a way to align product organizations around one outcome metric supported by 3-5 input metrics. The framework was published as a free playbook and adopted by hundreds of product teams including DoorDash, Patreon, and Calm. The framework's core innovation: insisting that input metrics must mathematically combine to influence the North Star — no 'related but not connected' metrics allowed. Teams report that the discipline of mathematical decomposition is harder than expected and surfaces hidden disagreements about how the business actually grows.

Framework Released

2018

Inputs per North Star

3-5

Adopting Companies

Hundreds (DoorDash, Patreon, Calm, etc.)

Common First Discovery

Teams disagree on the math

The act of building a mathematically sound tree forces an organization to declare its model of how growth happens. The disagreements that surface are valuable — they reveal that 'we're aligned on strategy' was an illusion.

Source ↗

🔧

Reforge (Growth Models)

2016-present

success

Reforge's Growth Models program, developed by Brian Balfour and team, takes the metrics tree concept further by adding user-state machines: every user is in a state (new, active, at-risk, churned, resurrected) and growth is the net flow between states. Each state-transition rate becomes a leaf metric. The state-machine approach reveals that 'growth' is actually 4-5 separate flows (acquisition, activation, retention, resurrection, churn) and that fixing one flow without the others produces no net growth. Reforge programs have trained thousands of growth and product leaders at companies like Airbnb, Stripe, and Pinterest.

Reforge Founded

2016 (Brian Balfour)

Core Concept

User state machines + flows

Alumni Companies

Airbnb, Stripe, Pinterest, etc.

Key Insight

Growth = net flow, not single metric

Trees that model user states as flows (not stocks) reveal where to invest. A team obsessed with acquisition while losing all gains to churn is invisibly running in place. The state-machine view makes invisible churn visible.

Source ↗

Decision scenario

The Activity-Theater Audit

You're a new VP Product at a 200-person SaaS company. The exec team proudly shows you their roadmap: 47 features planned for the year across 8 product teams. Their North Star (paid weekly active accounts) has been flat for 3 quarters. There is no metrics tree — each team has its own 'priorities.'

Roadmap Items / Year

47 features

Product Teams

North Star

Paid Weekly Active Accounts (flat 3 quarters)

Existing Metrics Tree

None

Roadmap → Outcome Mapping

Implicit / undocumented

Decision 1

You have one quarter to demonstrate impact. The natural play is to start shipping a new high-priority feature. The harder play is to spend 4-6 weeks building the metrics tree and then re-prioritizing.

Trust the existing roadmap and ship the highest-impact-looking item; build the tree later when there's timeReveal

Six months later, the team has shipped 22 of 47 features. North Star is still flat. You realize that several of the shipped features cannibalized each other, two failed to launch into the metric they were supposed to move, and three teams were working on overlapping problems. The activity was high; the outcome was zero. You start building a tree in month 7 — six months too late.

Features Shipped: +22North Star Movement: 0Wasted Eng Capacity: Estimated 40-50%

Spend 4 weeks building a mathematical metrics tree with the leadership team, then re-allocate the 47 roadmap items against the tree's leaves; kill or re-scope items that don't mapReveal

The tree-building exercise reveals that 18 of 47 roadmap items don't map to any leaf — they're activity for activity's sake. 12 items are duplicative across teams. 17 items map cleanly. You kill 18, merge 12 into 5, and proceed with 22 mapped items. Engineering velocity per outcome doubles. North Star starts moving by month 4. By month 12, the tree is the central planning artifact for the company and other VPs are asking how to adopt the same discipline.

Roadmap Items Killed: 18Duplicative Items Merged: 12 → 5North Star (12 months): Flat → +28%

Related concepts