Building a KPI Tree with AI: From North Star Down to the Team

After watching about 30 founders try to translate "we want to grow 2× this year" into team-level metrics, my conclusion is that the gap is almost never strategy. It's structure. They know the north star. They cannot draw the tree.

What is a KPI tree, actually?

Definition: KPI tree — a hierarchical decomposition of a single north star metric into the smaller, owned numbers whose movement mechanically explains movement in the parent.

The word that matters is "mechanically." If the children don't mathematically explain the parent, you have a wishlist, not a tree. Revenue equals customers × ARPU. Customers equals new − churned. New equals leads × win-rate. Each step is an equation, not an aspiration.

The reason most SMB strategy decks fail is that the team-level OKRs at the bottom of the deck have no provable relationship to the top of the deck. The tree fixes that — or exposes it.

How do you pick the north star?

This is the one decision AI cannot help with. The north star encodes your strategic bet: what does this company exist to be best at? Usable revenue per active customer is a different bet from logo growth, which is different from product-engagement time.

Three tests a north star metric must pass:

1. Mechanical decomposability — you can write it as an equation with 3-5 child metrics.
2. Weekly observability — you can measure movement weekly, not just quarterly.
3. Strategic uniqueness — a competitor with a different strategy would pick a different number.

If the candidate fails any test, it's a slogan, not a north star.

The three layers of a working KPI tree

Layer 1: north star. One metric. One owner (usually the CEO).

Layer 2: drivers. 3-5 metrics that mathematically combine into the north star. One owner per driver, typically a function head.

Layer 3: inputs. For each driver, 2-4 input metrics owned at team or squad level. These are the numbers a team can actually change week to week.

Definition: Input metric — a number a single team can move with this quarter's work, no cross-functional dependency required.

If a team-level metric requires three other teams to cooperate, it's not an input — it's a driver. Reclassify it.

Worked example: a 120-person services SMB

North star (Layer 1): Quarterly recognised revenue per active client.

Drivers (Layer 2):

• Active clients (new − churned − paused)
• Average project value
• Project completion rate within quarter
• Margin per project

Inputs for "average project value" (Layer 3, sales-team-owned):

• Discovery-call → proposal rate
• Average proposal size by service line
• Proposal acceptance rate
• Add-on attach rate within first 30 days

Inputs for "project completion rate" (Layer 3, delivery-team-owned):

• Kickoff-to-first-deliverable cycle time
• Mid-project scope-change rate
• Resource utilisation against committed plan
• Client-side delay days per project

Each Layer-3 input has one team and one weekly number. The CEO's quarterly review walks bottom-up: which inputs moved, which drivers responded, what does that say about the north star.

How AI helps: the Socratic critic pattern

AI is excellent at adversarial review of a tree someone already drafted. The prompt below uses it the right way.

You are an experienced operator reviewing a draft KPI tree.

Company: [E.g. "$8M ARR B2B SaaS, 60 staff"]
North star: [metric + 1-line definition]
Drivers (Layer 2): [3-5 metrics, each with definition]
Inputs by driver (Layer 3): [list]

Please attack this tree:
1. Where does the math NOT mechanically hold (parent ≠ function of children)?
2. Which Layer-3 inputs actually require multiple teams to move? (Should be drivers.)
3. Which metrics double-count the same underlying behaviour?
4. Where is there a strategic bet hidden as a metric definition?
5. Which inputs cannot be moved in a quarter — too slow for team-level ownership?

Be specific. Cite the metric names in your critique.

Three of those five questions will surface something the founding team missed. The fourth — "strategic bet hidden as a metric" — is the highest-leverage. Half of all metric arguments are really strategy arguments in disguise.

Tool tip (AIAdvisoryBoard.me): A KPI tree only earns its keep when the weekly review for each layer shows Plan → Fact → Gap — what each owner committed, what the input metric did, where the gap is. Our daily-management OS rolls Layer-3 movement up to Layer-2 and surfaces which driver explains the gap at the north star. The 7-day diagnostic builds the first version of your tree from the data you already have. See it at https://aiadvisoryboard.me/?lang=en.

Manager scan (2-minute digest example)

• North star written as one metric, one owner, one equation — no compound goals
• Layer 2 has 3-5 drivers, each with an explicit definition and unit
• Every driver has exactly one function-head owner — no committee ownership
• Layer 3 inputs are single-team movable in one quarter, not cross-functional projects
• Each input has a Plan, a Fact, and a written Gap explanation weekly
• The tree fits on one page — if it doesn't, drivers are too granular or too many
• Tree is reviewed quarterly; small edits monthly; no edits mid-month without a written reason
• Math is checked: pick a quarter, recompute parent from children, confirm reconciliation
• Vanity metrics live outside the tree, on engineering or ops dashboards
• New strategic initiatives must attach to an existing driver, not create a new branch

Micro-case (what changes after 7-14 days)

A 110-person B2B services firm had three OKR sets — company, function, team — that no one could mathematically reconcile. We ran the AI-critic prompt against their draft tree on day one. It surfaced four issues: "client satisfaction" appeared twice as both a driver and an input; "sales velocity" required marketing, sales, and customer-success to move together; "team utilisation" was already being moved by recruiting cycles, not weekly team work; and the north star ("annual recurring revenue") wasn't observable weekly. By day five they had a revised tree with a weekly-observable north star, four real drivers, and Layer-3 inputs that each team could actually move. By week two the Monday all-hands started with one Layer-2 chart and three Gap explanations from the function heads who owned the misses. The CEO described it as "the first time the strategy slide actually predicted the operating reality."

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

Tool tip (AIAdvisoryBoard.me): The reason most KPI trees die in month two is that no system propagates Plan → Fact → Gap from team level up to driver level automatically. Our system does that propagation daily and writes the gap narrative in plain language so the CEO review reads the tree, not the spreadsheets. The 7-day diagnostic shows you where the math currently breaks. Start at https://aiadvisoryboard.me/?lang=en.

FAQ

Can I have more than one north star? You can have a primary and a guardrail (e.g. revenue + retention). You cannot have two co-equal north stars; the team will trade them off in opposite directions and you'll never know.

What if my business is too complex for one tree? Then you probably have two distinct business units. Draw two trees, one per unit, and a portfolio-level summary above. Forcing a single tree onto a multi-business company is what produces the cross-functional inputs nightmare.

How is this different from OKRs? OKRs are commitments; the KPI tree is the underlying causal structure. OKRs without a tree are aspirational. A tree without OKRs is descriptive. You need both, but the tree comes first.

Do I need a data warehouse to do this? No. The first version can be built in a spreadsheet from your operational systems. The warehouse becomes useful when you want to automate the Plan → Fact → Gap propagation across the tree weekly.

What about leading indicators? Layer-3 inputs are your leading indicators — that's the design. The drivers are mid-cycle; the north star is lagging. The tree gives you a leading-to-lagging cascade by construction.

Conclusion

A KPI tree is the structure that turns strategy from a slide into an operating system. North star at the top. Drivers in the middle. Inputs at the bottom — owned by single teams, moved weekly, mechanically explaining the parent.

Draft the tree. Run the AI critic against it. Ship the first version this quarter and refine quarterly thereafter.

If you want a system that surfaces the Plan → Fact → Gap automatically — every day, across every layer of your tree — see how the 7-day diagnostic works at https://aiadvisoryboard.me/?lang=en.