Goal systems in e-commerce: OKR, Balanced Scorecard, or just a KPI tree?

There is a sentence that reliably comes up in strategy workshops and sounds as though something had been decided: "We're doing OKR now." Six months later, two quarters' worth of objectives sit in a Confluence space, half the key results never had a value entered against them, and the monthly meeting argues about the same revenue figures as before.

The problem was not OKR. OKR works — in organizations whose data and decision tempo fit it. The problem was that the system question was never treated as a question. It was treated as a matter of taste, and the answer came from the conference talk someone had seen in the spring.

The first part of this series covered why goals without numbers are not goals. The second part covered what a metric has to look like for nobody to negotiate it any more. This article deals with the layer above: what structure do those metrics actually hang in? Five systems are candidates. They are not equivalent, and above all they are not freely interchangeable.

A goal system and an operating rhythm are two different things

Before the five candidates come to the table, a distinction whose absence sinks most rollouts. There are two questions, and they are almost always thrown into one pot:

The goal system answers: what is being steered? Which goals exist, how they relate, which metrics each one hangs on, who owns it. That is a question of structure.

The operating rhythm answers: when are decisions made? Which question belongs in the weekly cycle, which in the month, which in the quarter. Who attends, on which state of the numbers, and what the meeting produces. That is a question of process.

A goal system without an operating rhythm is a document — nobody notices when a gap opens up. An operating rhythm without a goal system is a standing meeting in which what matters gets renegotiated every week. Both occur, and both feel like steering without being it.

This article deals exclusively with the first question. The rhythm gets its own part, because it decides at least as much about success as the choice of system does.

The five candidates

MBO — Management by Objectives

The ancestor, described by Peter Drucker in 1954 in "The Practice of Management". The idea: manager and employee agree on goals instead of assigning tasks. Performance is measured by degree of attainment, usually over a financial year and often tied to compensation.

In e-commerce you rarely meet MBO under that name, but constantly in substance: annual goals per department, assessed at year end, with a bonus attached. The strength is clear accountability. The weakness is the coupling to compensation — as soon as a goal determines someone's pay, the negotiation is no longer about the right goal but about an attainable one. And the annual horizon fits badly with a channel in which the competitive environment, platform rules and demand shift on a quarterly cycle.

Balanced Scorecard — four perspectives and a chain

Introduced in 1992 by Robert Kaplan and David Norton in Harvard Business Review, as an answer to reporting that was purely financial (Harvard Business Review). The core idea: financial metrics are lagging. They say what happened, not what will happen. So three further perspectives are added — customer, internal processes, learning and growth — and a cause-and-effect chain is stretched between them.

For e-commerce this is more relevant than its corporate reputation suggests. Translated, the chain reads roughly: product data quality improves filterability, better filters lower the abandonment rate in the listing, that lifts the conversion rate, that lifts contribution margin. Every one of those steps is measurable. Which is exactly why it also becomes visible when a step is merely asserted.

The weakness: the complete scorecard is too heavy for a shop with 25 people. Four perspectives with four to five metrics each is twenty metrics that have to be maintained. In practice the usable part is not the form but the principle — separate leading from lagging indicators and make the chain between them explicit.

OKR — focus for a bounded period

Born at Intel, spread through Google, popularized by John Doerr. An objective is qualitative and directional, a key result is a number with a baseline, a target and a deadline. What Matters puts it this way: key results are "specific, time-bound, and aggressive yet realistic" and above all "measurable and verifiable" — you either meet them or you don't, with no gray area (What Matters).

The strength of OKR is focus and communication. Three objectives per quarter force a choice, and because they are public, every team knows what the others are working on. That is precisely the point at which, according to HBR, execution fails in two-thirds to three-quarters of large organizations — not on the strategy, but on coordination across unit boundaries (Harvard Business Review).

The weakness: OKR is not a measurement system. It assumes the numbers behind the key results exist and update themselves. Introduce OKR without having defined the metrics and you get a quarterly ritual in which someone eventually estimates percentages. And the quarterly cycle does not fit every business — an assortment with two hard seasonal peaks does not slice neatly into four equal parts.

KPI tree — decomposing the goal

Not a management system in the narrow sense but a calculation structure, often called a driver tree. The target metric sits at the root, below it the factors it is composed of, and below those the drivers a team can actually move.

For e-commerce this is the most natural form, because the target quantity can be decomposed arithmetically: contribution margin from orders, basket value, margin and return rate; orders from sessions and conversion rate; sessions from channels. This decomposition is not a metaphor but an equation — you can check the arithmetic.

The strength is the low barrier to entry: the tree needs no ritual, no cascading and no quarterly planning. It needs only defined metrics. The weakness is that it says nothing about prioritization and nothing about accountability. A tree shows which driver moves the goal most — it does not say whether that driver is also the cheapest one, and it does not answer who decides.

Hoshin Kanri — alignment across levels

From Japanese lean management, often called policy deployment. The Lean Enterprise Institute describes it as "a strategic framework for building sustained high performance and producing results through structured plan-do-check-act (PDCA) thinking" that aligns functions and activities "vertically and horizontally — from the CEO to the front line and across departments" with strategic objectives (Lean Enterprise Institute).

Its characteristic element is the reciprocal alignment between levels: goals are not passed down but negotiated until the level that has to deliver also considers the target level achievable. That is conceptually strong and in e-commerce almost always oversized. Hoshin Kanri earns its keep in organizations with several hierarchy levels and long value streams. A twelve-person shop team does not need multi-stage alignment mechanics, it needs one shared document.

The comparison at a glance

Which of these systems can be selected in nuonic Lens today is listed further down in a table of its own.

The column that decides most in practice is data requirements. All five systems assume that the numbers they invoke exist, are bindingly defined, and update without manual work. Where that is not the case, the choice of system is irrelevant: each of them then degenerates into a document that gets maintained twice and forgotten afterwards.

Which system fits which shop

The decision hangs on three variables, and none of them is a preference.

Your data. Are the most important metrics defined and automatically available? If not, the answer is always the KPI tree — not because it is the best system, but because it is the only one that also starts with three metrics and immediately shows which number is missing. Everything else comes later.

Organization size. Below ten people in e-commerce nobody needs a goal system with cascading — a KPI tree with named owners and a monthly meeting is enough, and anything beyond that costs more time than it returns in clarity. Between ten and fifty the real need appears, because several teams work on the same target quantity without noticing: this is where OKR plays to its strength, laid on top of an existing KPI tree. Above fifty the Balanced Scorecard's cause-and-effect chain becomes worth it, because the distance between a measure and its effect on the financial numbers grows too large to hold in your head.

Decision tempo. How fast does a change of direction have to take hold? A D2C shop with a performance marketing share decides on budget weekly and on assortment monthly — annual goals alone are worthless there. A B2B merchant with framework agreements, tenders and budget cycles on the customer side has genuine annual rhythms, and a quarterly cycle cuts its processes apart artificially.

In practice this nearly always produces the same order, regardless of shop size: the tree first, then the focus, then the chain. The KPI tree clarifies what the goal is composed of. OKR sets which branch gets moved this quarter. The Balanced Scorecard's perspectives make sure the leading indicators do not get lost along the way. Start in the reverse order and you build rituals before you have numbers.

Where F.O.C.U.S. sits in this landscape

A question that reliably comes up at this point: is F.O.C.U.S. then the sixth system? No — and the distinction matters enough to make it explicit.

The five systems above each answer one question within ongoing operations: how do I decompose the goal, what do I focus on this quarter, which chain connects a leading indicator to a financial figure. Our F.O.C.U.S. framework answers a different question — namely when in the course of a project each of those questions is even due:

• Facts supplies the baseline. A goal system set up before the first measurement sets its targets by guessing.
• Objectives is the phase in which the goal system, the KPI definitions and the planned trajectory are created — everything this article and the previous one describe sits here.
• Constraints clarifies the uncomfortable variant: a goal the data cannot support is not a goal but a limitation that belongs on the table.
• Execution is the set of measures with a hypothesis, a measurement window and an owner.
• Scaling is the operating rhythm as a permanent state — the part that decides whether the structure still holds a year later.

From that follows the sequence that saves the most argument in projects: objectives do not come first, they come after facts. Set the goals first and measure afterwards, and you have to correct the goals after the first measurement — losing exactly the commitment you introduced a goal system for.

F.O.C.U.S. therefore replaces neither OKR nor the Balanced Scorecard. It is the bracket in which they get their place. How the five systems and the five phases interlock in detail is a topic of its own, and gets the closing article of this block.

What all five systems presuppose

Whatever the choice, there are three preconditions. If one is missing, every one of the five systems fails in the same way.

Defined metrics. Every number a goal invokes needs a formula, a source system, a time reference, an exclusion rule and a stability rule. That is the subject of the previous article and cannot be retrofitted: a key result without a KPI definition is a statement of intent, and a branch in the KPI tree without a definition is an assertion about an arithmetic relationship.

A planned trajectory, not just a target. "€120,000 contribution margin by year end" is not a steerable goal, it is a final state. It becomes steerable through the expected path to get there, because only comparing actuals against the planned trajectory makes a gap visible while it can still be closed. Without one, you notice the deviation in December.

Named owners. One person per goal and per metric, not a team. They decide in case of doubt how something is interpreted and whether a change to the goal is justified. "The team owns the goal" means in practice that nobody owns it.

The most common mistake: two systems in parallel, neither binding

The most expensive mistake is not the wrong choice. It is the choice that was never made.

The pattern is always the same. There are annual goals from the management plan, because the bank and the shareholders want to see them. There has been OKR for two years, because the e-commerce team introduced it. And there is a dashboard with forty tiles that at some point started being called "the KPI tree". Three structures that aggregate the same metrics differently, and none that anyone invokes in case of doubt.

The consequence is not chaos — there is too much documentation for that. The consequence is arbitrariness: where three legitimate structures exist, the one that fits the desired outcome wins every meeting. That is exactly what the HBR research on strategy execution identifies as the core problem — not missing plans, but missing commitment across units.

The repair is uncomfortable and quick: one structure is marked as binding, the others are declared views on top of it or abolished. The annual goal stays in the tree as a target value, it does not become a parallel system. The OKRs hang off branches of the tree, not beside it. The dashboard shows what is in the tree, and nothing more.

Two further patterns are worth mentioning, because both look like progress. The first is the system as a project: the rollout gets a project plan, a workshop and a template — and ends with the rollout instead of with the first review. The second is switching systems in answer to a data problem: OKR isn't working, so let's try the scorecard. When the numbers are missing, changing the system only changes the form in which they are missing.

Why we're building nuonic Lens for this

The system question has an uncomfortable side effect: in practice it is not decided once but re-decided every couple of years. A change in management, a new head of e-commerce, a consultancy with a house method — and the structure gets rebuilt. What gets lost in that rebuild is not the form. What gets lost are the metric definitions, the goal history and the reasoning for why a target was set the way it was. We have accompanied this rebuild several times in projects and seen the same thing every time: the numbers do not survive a change of system, because they hung inside the system instead of underneath it.

That is why nuonic Lens is built so that the model determines only the arrangement — not the data. What gets stored is the guiding statement, the horizon and the review rhythm, and underneath them the goals with owner and budget, the metrics attached to each goal with a baseline and a target value, and the measures with an expected and a measured effect. There is one goals table, not four. Which slot a goal occupies is what the model says; what gets stored stays the same. Switching models rearranges the goals and throws nothing away.

Which systems Lens covers today

Four models can be selected in nuonic Lens: F.O.C.U.S., OKR, Balanced Scorecard and a free structure. KPI tree, Hoshin Kanri and MBO cannot.

The honest gap is the KPI tree — of all things the system this article recommends to small teams as the entry point. A baseline and a target value per metric are there; decomposing a target quantity into its drivers is not. That is the next step, and not coincidentally the most demanding one: a tree is only worth as much as the arithmetic relationships it asserts.

Even so, the benefit of where it stands today is exactly the one that matters for the system question: the decision becomes reversible. Start with F.O.C.U.S. and switch to OKR a year later because the team has grown, and you keep the guiding statement, the goal history, the metrics and the measures — the arrangement changes, not the data. That takes away what makes the system question so expensive today: its finality.

Lens is not another dashboard and not a replacement for an ERP or analytics. It reads from the sources that are connected anyway and holds the structure together — the business decisions about which goal applies and what gets prioritized stay with the company.

nuonic Lens is still in development — for the time being there is no public sign-up and no pricing. If you want to follow the series or talk about it early, just get in touch.

The next step

Three checks you can run in an hour:

1. Ask three people from different areas which goal system applies at your company. If you get three different answers, you do not have the wrong system — you have none.
2. Take your most important goal and check whether it has a planned trajectory. A target value at a deadline and nothing else means the deviation surfaces on the deadline.
3. Check whether every initiative currently running maps to a goal. What cannot be mapped is either indispensable operations — or there is a goal that officially does not exist.

The next article goes deep on the system most often introduced and most often misunderstood in e-commerce: OKR. Objective and key result, the difference between a key result and a measure, committed versus aspirational — and the abort criteria that tell you OKR is too much overhead for your shop.

If you would rather not build the goal structure alone: that is exactly what we do in consulting, and in growth we run it as a cycle with before-and-after measurement. How we connect the phases is described in the F.O.C.U.S. framework. Get in touch — a conversation with the people who also build it.

Sources and further reading

• Harvard Business Review: The Balanced Scorecard — Measures that Drive Performance
• Harvard Business Review: Why Strategy Execution Unravels — and What to Do About It
• What Matters: What is an OKR? Definition and Examples
• Lean Enterprise Institute: Hoshin Kanri — Resource Guide

Keep reading

• KPI definitions in e-commerce: metrics nobody negotiates any more
• Measurable strategy in e-commerce: why goals without numbers are not goals
• F.O.C.U.S. — the methodology behind our projects
• Consulting: decisions on a data basis
• Growth: scaling is a system