For Product Teams

Ship the feature. Prove it moved the metric.

Product analytics tools show you what users do inside your product. They cannot tell you which inputs drive your north star, who owns each one, or whether the last release moved retention.

You shipped the roadmap. The north star did not move.

Product teams are measured on outcomes but run on outputs. The gap between the two is invisible in a product analytics tool, and it is where quarters get lost.

The north star dips and the meeting fills with theories

Activation looks soft, a release went out on Tuesday, marketing changed a campaign, and everyone has a story that fits. Without driver relationships that carry confidence levels and statistical significance, the argument about why is settled by seniority rather than evidence, and the same argument happens again next month.

Shipped is not the same as worked

The roadmap review counts delivered projects. But a feature can ship on time, spike adoption for a fortnight, and leave retention exactly where it was. If nobody measures each bet against the metric it was meant to move, the team learns nothing from a quarter of work, and the next roadmap is built on the same guesses.

Your metric tree stops at the product wall

Some analytics tools now draw metric trees, but they scope them to product events: funnels, cohorts, feature adoption. Your north star does not live in a vacuum. It connects to marketing acquisition, sales conversion, pricing and the P&L. A tree that only covers product is a branch pretending to be a forest.

Decompose your north star into drivers you can defend

Start with your north star and break it down through activation, engagement, retention and monetisation, then keep going into marketing, sales and revenue. Every edge in the tree carries a confidence level and a statistical significance score, tested against your data nightly, so the relationship between onboarding completion and retention is a measured claim rather than a diagram. AI drafts the structure, your product team reshapes it, and the nightly tests decide which edges stay.
  • Describe your product model in plain English and AI drafts the tree, with every node and edge editable
  • Break each level into feature inputs: onboarding completion, core action frequency, time to value
  • Connect product metrics to marketing, sales and revenue on the same canvas, so the tree does not stop at the product wall
  • Every driver edge carries confidence and significance, recalculated nightly, with false positives pruned by your team

Know why the metric moved before the stand-up does

When retention dips, KPI Tree ranks the drivers behind the change by impact, each with the confidence level and statistical significance to back it, and traces the movement through the tree to the input that actually moved. Ask a question that crosses team boundaries, like what is driving the activation decline across regions, and AI analyses the whole tree, querying your warehouse directly so the answer comes from your actual data rather than a plausible story.
  • Drivers are ranked by impact, with confidence levels and statistical significance on every relationship
  • Waterfall change insights show what each driver added or removed against its goal
  • Cross-domain AI analysis connects insights across product, marketing and finance in one answer
  • AI investigations query your warehouse directly, so findings are grounded in the underlying data, not just aggregated values

Give every driver a named owner and a push that fires when it moves

Shared ownership means no ownership. KPI Tree applies RACI to every metric in the tree, synced from your directory, so activation, onboarding and referral each have a named Accountable owner. When a metric crosses a threshold, produces an outlier, goes silent or misses its end-of-period target, the push fires because the metric itself moved, and it routes to that named owner via Slack or email with the driver behind the movement attached.
  • Assign squads or individuals to any node: the activation squad owns onboarding, the growth squad owns referral
  • Triggers fire on threshold crossings, outliers, silent metrics and missed period-close targets, and each push routes to the named Accountable owner
  • Escalation follows your live org chart, so a movement nobody acts on reaches the manager automatically
  • Ask KPI Tree in Slack why activation dipped and the answer lands in the thread, with the driver and the owner attached

Run the roadmap as a portfolio of verified bets

Plan the work as initiatives, each linked to the metrics it is meant to move, with an owner, milestones, budget and spend. Execution is tracked separately from outcome, so a project delivered on time against a flat metric is visible at a glance rather than hidden behind a single progress bar. When objectives sit above the work, each key result is a real metric with a target, so progress is read from the data rather than typed into a status field. Impact is verified from the data, and the portfolio view shows which bets are working.
  • Link every initiative to the metrics it targets, and track execution apart from outcome
  • Impact is measured by the same pipeline that calculates your actuals, so nobody marks their own homework
  • The portfolio view scores each initiative by how far its metrics have moved since the work began, in the direction it intended
  • Model a launch with ramp profiles instead of flat assumptions, and compare the plan against actuals at any granularity
Task assignment loading

“Product analytics tools show you what users do. KPI Tree shows you what drives your north star with confidence and significance attached, who owns each driver, and whether the last release actually moved the number.”

What product analytics tools leave out

A metric tree you can look at is a feature. A closed loop that maps drivers with statistical confidence and significance, routes each movement to its named owner and verifies whether shipped work moved the number is a system. KPI Tree is the system.

The closed loop, delivered

A metric moves. The named Accountable owner is notified with the driver edge behind the movement attached. The action is tracked against the metric it was meant to move. The impact is verified weeks later by the same pipeline that calculates your actuals. Every vendor claims this loop. This is the mechanism.

Evidence that outranks seniority

Every relationship in the tree carries a confidence level and a statistical significance score, tested nightly against your data for lag and seasonality, with false positives pruned by your team. When you argue for a bet on activation, the evidence is on the canvas, not in a slide.

AI answers with an owner and a track record

The same tree serves the people who own the metrics and the AI tools they already use. Over MCP, agents read significance-tested driver edges with their confidence levels, RACI ownership and verified impact history, so an answer arrives with an owner and a track record instead of a plausible story.

Common questions

How is this different from our product analytics tool?

Product analytics tools are built for event-level analysis: funnels, cohorts, user flows, feature adoption. KPI Tree sits a layer above. It connects the metrics those tools produce into a causal model that spans the whole business, with confidence levels and statistical significance on every relationship, named ownership on every metric, and verified impact on every action. Keep your product analytics tool for event analysis. KPI Tree is the layer that says what drives what, who owns it, and whether the work moved the number.

Our analytics tool already draws metric trees. Why is yours different?

A tree you can look at is a visualisation. KPI Tree is built around the tree as a system: whole-business scope rather than product events only, driver edges that carry confidence and statistical significance and are retested nightly, RACI ownership with pushes that fire when a metric moves and route to the named Accountable owner, actions tracked against metrics, and impact verified over time. Shipping the picture does not ship the loop.

Is the driver analysis causal or just correlation?

Correlation is only the first gate. Driver relationships are statistically proven over time, tested nightly against your data for lag and seasonality, and every edge carries a confidence level and a significance score. Your team prunes relationships the statistics cannot rule out but you know have no causal link. The draft comes from AI, the corrections come from your team, and the verdict comes from the nightly tests, with the model telling you how sure it is rather than overclaiming.

Can we run our objectives and key results on it?

Yes. Objectives live on the same tree as the metrics. Each key result is a real metric with a target, so progress is read from the data rather than typed into a status field, and outcome is tracked apart from execution, so a fully delivered plan against a flat number is visible rather than hidden behind one bar. Initiatives carry the budget, the owner and the metrics they target, and the portfolio view shows which bets are moving their numbers.

Can the AI tools we already use read the model?

Yes. Connect Claude, ChatGPT, Cursor and other MCP clients and your assistant reads the tree: significance-tested driver edges with confidence levels, RACI ownership, targets and verified impact history, scoped to what the asker is permitted to see. This surface is Canopy, the business context layer, and it is the same model your team uses. Because comparisons and correlations are precomputed around every metric, an agent gets the full picture in one call instead of ten warehouse queries.

What do we need in place to get started?

A warehouse or a semantic layer is enough. KPI Tree calculates metrics where your data lives, syncs definitions from dbt, Looker or Snowflake Semantic Views, and reads aggregation semantics automatically. Metrics that live outside the warehouse can come in through any MCP-compatible source, so numbers from tools like Stripe, HubSpot or Linear sit in the same tree, owned and targeted like any warehouse metric. If you have no metric definitions yet, describe your product model in plain English and AI drafts the first tree.

Related guides

KPI Tree

Metric trees for product teams

Connect every feature, experiment, and initiative to the outcomes that matter

Read guide
KPI Tree

North Star Framework vs metric trees

Comparing and connecting two approaches to strategic measurement

Read guide
KPI Tree

How to run an A/B test with metric trees

Connecting experimentation to the metric tree framework

Read guide

Bring your north star. Leave with its drivers.

Book an hour. We map your north star to the inputs that drive it, across product, marketing and revenue, with confidence and significance on every relationship, and show you the loop from a metric moving to a verified action. Your analytics stack stays exactly where it is.

Book a demo

Experience That Matters

Built by a team that's been in your shoes

Our team brings deep experience from leading Data, Growth and People teams at some of the fastest growing scaleups in Europe through to IPO and beyond. We've faced the same challenges you're facing now.

Checkout.com
Planet
UK Government
Travelex
BT
Sainsbury's
Goldman Sachs
Dojo
Redpin
Farfetch
Just Eat for Business