For humans · Act

Objectives that answer to the numbers.

Objectives and key results that live on your causal metric tree, not in a parallel spreadsheet.

PlatformMetric TreesBusiness ModelsRoot Cause AnalysisMetric OwnershipAction PlansVerified Impact
Strategy Execution

Strategy on the same model as everything else. Outcomes, work and proof in one place.

Objectives sit on the metric tree. Aligned to cause and effect

Each key result is a real metric with tested drivers beneath it, so the plan aligns to cause and effect you can check, not to a slogan repeated down the org.

Outcome and execution, tracked apart. Two lanes, not one bar

One lane reads whether the metric moved, the other whether the work got done. A shipped project on a flat number can no longer hide behind a single percentage.

Initiatives are the unit of investment. Budget, owners, milestones

The work behind each objective carries its budget, spend, owner and milestones, and the portfolio reads that spend against the movement of the metrics it was meant to move, so where the money is working is observed rather than argued.

The whole strategy on one canvas. The strategy map

Objectives cascade into key results and the initiatives that move them on a single live map, drawn in the same visual language as your metric trees. The dashed edge from work to number is the claim, on screen.

Targets verify themselves. No self-reported progress

A key result reads its own value from the pipeline behind every actual in KPI Tree. Nobody types a percentage into a status field on a Friday afternoon.

Plan around data you do not have. Planned metrics

An initiative can target a metric that does not exist yet, named and tracked as a planned metric, so closing a data gap is a funded piece of strategy rather than a footnote in a backlog.

The gap is not between strategy and execution. It is between strategy and understanding.

Every strategy tool aligns goals and tracks status. None of them tells you whether an objective is failing because the work slipped or because the work was the wrong lever. In KPI Tree, an objective links to the causal metric tree: each key result is a metric with a significance-tested driver beneath it, and each initiative is work aimed at a driver you can name. Alignment stops being a cascade of restated sentences from the company goal to the team goal, and becomes a chain of cause and effect you can follow from the board objective down to the number it moves.
causal · q < 0.05lag 3dq < 0.01Revenue-15%Conversion-23%Traffic+2%AOV-4%Checkout-31%PricingPaidOrganicBasket sizeDiscountsPayment errorsPage speed

One canvas for the whole strategy. Drawn like the rest of your business.

The strategy map lays the entire plan out as a live graph: objectives cascade from company to team, each key result hangs beneath the objective it proves, and every initiative connects to the key result it is meant to move with a dashed edge, so the bet is drawn rather than implied. The cards read like the metric cards on your trees, one number, one owner, one bar, because they are the same product speaking the same language. When a card turns amber the map shows you exactly which part of the org to talk to, and adding the next key result or initiative happens right there on the canvas.
At risk

Reduce labour cost percentage to below 28%

83%

outcome · Department objective · 1/3 tasks done

Labour cost percentage: below 28%

29.4

key result target ≤ 28

Active

Rota optimisation rollout

40%

moves Labour cost % · £12k of £30k

The dashed edge is the claim: this work moves that number.

Outcome and execution are not the same number. Track them apart.

Most OKR tools collapse a goal into one progress bar, which is exactly how a team delivers every planned project and still misses the target. KPI Tree keeps two lanes on every objective. Outcome progress is whether the metric moved, read straight from the data. Execution progress is whether the initiatives and tasks got done. When the two diverge, the objective says so out loud and the review filters straight to it: a plan fully delivered against a metric that has not budged is the most useful thing a strategy meeting can surface, and here it is one click, not a quarter-end surprise.

Reduce labour cost to 26%

Off track
Outcome18%
Execution92%

Every project shipped. The metric has not moved.

Strategy at the top, tasks at the bottom, one model in between.

Objectives and key results are strategic. Tasks are tactical. Most companies keep them in different tools and lose the thread between them, which is how a quarter of work gets done without anyone being able to say which objective it served. Here tasks live inside the initiatives that deliver the strategy, every tier shows how much of the work beneath it is done, and capturing the next task is a single line typed where you already are. The board sees the plan; the team sees their list; both are looking at the same model. The strategic loop reviews the plan, the tactical loop delivers it, and the boundary between them runs through one model, not two tools.

Strategic · reviewed quarterly

At risk

Reduce labour cost percentage to below 28%

83%

outcome · Department objective · 1/3 tasks done

Key result: below 28% by quarter end

29.4

reads itself from the pipeline · nobody types a status

Labour cost %, live

Active

Rota optimisation rollout

40%

execution · £12k of £30k spent · 3 tasks

Strategic/Tactical

Tactical · runs daily

Detect

Up 4.2% this weekLabour cost %

Outlier-checked against seasonality, so it is signal, not noise.

Route

ASarah is told, with the driver attached

RACI from your directory decides who, the tree decides why.

Act

Task: pilot the new rota at Canary Wharf

Filed inside the rota rollout, so the work counts towards the bet.

Verify

Impact measured on the metric

What worked is remembered; next quarter plans against proof.

Canopy, the business context layer, holds both tiers

People and agents read the same model, over the app or MCP.

Causal driversRACI ownershipObjectives and initiativesBudgets and plansVerified impactData quality

Initiatives are where the money goes. Manage them like a portfolio.

The work behind an objective is an investment, so it is modelled as one. Each initiative carries a budget, actual spend, an owner, milestones and the objectives and metrics it is meant to move, including the direction it should move them: up, down, or mitigate, holding a number steady as a guard-rail while you push elsewhere. A dedicated portfolio view then reads the evidence across all of them on one chart: how far each targeted metric has moved since the initiative started, signed by the direction it bet on, plotted against the share of spend behind it, so where the money is working is something you can see. Every initiative earns a verdict from the same rules, from double down through too early to judge, and because outcome and execution are tracked apart those verdicts can tell a funded initiative that is not working from one that has not really started, which is the difference between killing the wrong lever and killing the right one too early. Work that has not begun is not judged at all. Prioritisation stops being an argument about opinions and becomes a question you can answer from the model.
See budgets as business models

Where the money is working

Bubble area = budget

Metric movement since each initiative started, signed by the direction it bet on.

Menu engineering programme
Rota optimisation rollout
+25%0%-25%

Share of portfolio spend

Double downToo early to judgeNot startedEvery initiative earns a verdict

The data you do not capture yet belongs on the plan too.

Some of the most valuable initiatives in a data-led business exist to create data: the coverage you do not have, the field a supplier never passes through, the process nobody instruments. KPI Tree lets an initiative target a planned metric, a metric that does not exist in your warehouse yet, named now and wired in the moment it goes live. Data gaps stop being an aside in an engineering backlog and become funded, owned, reviewable strategy, and the moment the metric lands it starts verifying the work that created it.

Metric links

RevenueLive metric
% bookings with consented emailPlanned

Not captured yet. The initiative exists to change that.

Every objective has a name on it. RACI, not a single owner field.

An objective without a named owner is a wish. KPI Tree applies the same RACI model it holds on every metric to objectives and their key results, kept current from your directory provider, so Responsible, Accountable, Consulted and Informed move with people as they change teams. When a key result drifts, the same push-and-escalate accountability that runs on every metric takes over, climbing the live org chart until someone acts, which is the difference between a status update and accountability.

Conversion rate

Marketing · daily

R
A
C
+4
I

Nobody marks their own homework. The metric is the referee.

A key result tied to a metric completes when the metric hits the target, read from the same pipeline that calculates your actuals; progress is observed, not reported. When an initiative is meant to move a metric, its impact is measured against that metric, not against what someone claimed at quarter-end. That verdict feeds the next quarter: work that proved out is recommended with its verified track record, and objectives are planned against levers that have actually moved before.

Fix checkout flow

Verified · +£32k

Linked to Revenue · measured by the actuals pipeline

Pause underperforming ad sets

Measuring…

Strategy that runs the loop. Not a document nobody reads.

An objective drifts off track. The named owner is notified with the driver behind it attached. An initiative is funded against the metric it targets, tracked, and its impact verified. Then the model learns and the next plan is sharper. It is the same loop the rest of the platform runs, applied to strategy, which is why objectives here do not sit in a silo away from the numbers, the ownership and the proof. They sit on top of them.

Common questions

How is this different from a standalone OKR tool?

Standalone OKR tools track goals in their own system, disconnected from where the numbers live. Here, objectives link to the causal metric tree, so a key result is a real metric with a tested driver, outcome and execution are tracked apart, and impact is verified by the same pipeline as your actuals. Alignment is to cause and effect, not to a parallel document.

What is the difference between outcome and execution progress?

Outcome progress reads whether the metric moved, straight from the data. Execution progress reads whether the initiatives and tasks got done. Keeping them apart is what stops a fully delivered plan from hiding a flat metric behind a single bar.

What is an initiative?

An initiative is the funded work behind an objective: the budget and what has actually been spent, a named owner, milestones, and links to the objectives and metrics it is meant to move. The portfolio view reads across all of them, and each one's impact is verified against the metric it targets.

Who owns an objective?

Objectives and key results use the same RACI model as every metric, synced from your directory provider. The named Accountable owner is pushed the driver context when a key result drifts, and escalation follows the live org chart.

Where do the numbers behind a key result come from?

From your warehouse, through the same calculations pipeline that produces every actual in KPI Tree. A key result completes when its metric hits target, so progress is the data, not a self-reported status.

How do tasks relate to objectives and initiatives?

Objectives and key results are the strategic tier, initiatives are the funded bets that deliver them, and tasks are the tactical work inside those initiatives. Every tier rolls the work beneath it up into an execution count, so the same model serves the board view and the team list.

Can we plan around data we do not capture yet?

Yes. An initiative can target a planned metric, a named metric that does not exist in your warehouse yet. The gap is visible on the plan with a budget and an owner, and the link goes live the moment the metric does.

Can AI agents read our strategy?

Yes. Objectives, key results, initiatives and tasks are part of the same business context layer agents consume over MCP, so an agent can answer which objectives are at risk, which funded initiatives are targeting them and who owns the next step, with your permissions applied.

Metric Trees

The causal model objectives align to.

Metric Ownership

The RACI that names every owner.

Verified Impact

Did the work move the number?

Business Models

Budgets and reforecasts against actuals, one pipeline.

Canopy

The context layer agents read strategy from.

OKRs and metric trees

Why OKRs and KPIs are not a choice.

See it on your own metrics.

Book a demo