Metric

Companies used to describe their own state entirely in words. Response has been good lately. Churn feels like it's creeping up. The last campaign went well. Sentences like these cannot be argued with. Answering "response has not been good" only sets one impression against another, and the conclusion drifts toward whoever spoke loudest or ranks highest that day. A quarter later there is also no way to check whether the conclusion held, because checking requires a record of what was being looked at, and impressions leave no record.

Bringing numbers into the room solves about half of that. The other half appears right afterward, in the form of the same named number arriving at different meetings with different values. Pagedeck ran into it directly. Grace asked how many active users there were this month. Ravi said 120,000. Mia said 40,000. Both read their own screens correctly. Ravi was counting anyone who logged in at least once; Mia was counting anyone who created at least one document.

What happens next is fairly predictable. The subject of the meeting shifts from the business to the numbers. An hour goes into arguing which figure is right, everyone agrees to pull the data again next week, and next week the same two figures come back. Nothing was decided about how to count, so re-pulling produces the same disagreement. The worse outcome is what this does over time: once people accept that the number depends on who fetched it, a correctly calculated figure carries no weight either, and the room falls back to impressions and volume.

A metric is the concept that blocks both problems at once. Arguing for numbers is not the new part. The new part is the procedure of agreeing on the counting rule first and writing it down — what counts, what is excluded, which timestamp anchors it, which store the values come from. Once that exists, anyone can pull the figure and get the same answer, and the meeting can be about what to do rather than about which number is correct.

The terms under this heading fall into five groups: how a single number gets defined and linked to others (design), whether the number is one a team can move directly or one that arrives as a result (character), whether it is a division or a raw count (shape), what breaks when a number becomes a target (risk), and how the same number is kept from diverging across screens (operations).

Design covers pinning one number down and connecting several.

1. Metric definition — the written rule for what is counted and how. For active users that means recording whether a login alone counts, which action is required if not, whether the window is 30 days or a calendar month, and whether internal staff accounts are removed. Without this document, one metric name produces as many metrics as there are people pulling it.
2. Metric tree — a structure that breaks one large number into multiplied and added parts hanging beneath it. Monthly revenue becomes paying accounts × average spend per account, and paying accounts splits again into new plus retained plus returning. Drawn out this way, "let's grow revenue" turns into a statement about which branch to touch, and last month's wobble can be traced down the branches. Branches also divide ownership — marketing owns new accounts, customer success owns retention, product and pricing own spend per account — which makes goals easier to hand out.

Character sorts numbers by whether a team can move them directly. An input metric reflects the team's actions the same day: guides sent this week, help articles rewritten, average time to first reply. An output metric is what accumulates from those actions later, which is where revenue and retention sit. The practical value of the split shows up at goal-setting time. Set only outputs and a team starts the quarter without knowing what to do; nobody handed "raise retention five percent" has a screen to open on Monday morning. Set only inputs and it is possible to finish a very busy quarter with nothing improved. So teams read inputs weekly and outputs quarterly, and keep checking whether the link between the two actually holds.

Shape sorts numbers by what they look like. A ratio metric divides one value by another; an absolute metric reports the count or amount as it is. Watching only one of the two guarantees being misled. Conversion moving from 3 percent to 6 percent reads as excellent until you learn that visitors fell from 20,000 to 1,000, which means actual conversions dropped from 600 to 60. In the other direction, an absolute rise in signups hides the fact that ad spend doubled. Dashboards therefore tend to place the pair side by side, and when a ratio moves, the first question is whether the numerator or the denominator moved.

Risk covers the failure modes that come from handling numbers at all. Goodhart's law says that the moment a number becomes a target, it stops working as a measure of the state. Make support response time a team goal and response time will certainly fall. It may fall because problems get solved faster, or because someone sends an acknowledgment first and solves later. The metric improved and the customer's experience did not. There is no way to avoid this entirely; the usual handling is to hang a paired number next to it. Putting repeat-contact rate beside response time closes the route that consists of replying with nothing.

Operations keeps agreed metrics from drifting. Single source of truth (SSOT) is the principle of keeping exactly one authoritative store per value. If everyone computes revenue their own way, three revenue figures arrive at the meeting, so the formula lives in one place and every screen reads from it. The cost is that changing that one place requires telling people which screens are affected, because changing a definition changes history too. Dropping internal accounts from active users pushes last month's figure from 40,000 down to 38,000, and without an announcement somebody reports that growth stalled. So definition changes get logged with the date, the reason, and the before-and-after values in the same document.

The five groups interlock in order. No definition means no tree. Ignoring character and shape means setting the wrong goals. Ignoring risk means a well-built metric breaking within six months. No operations means the definition exists while each screen shows a different value. Building a new metric tends to follow that same order: write in one line what decision this number will drive, set the counting rule to fit that decision, attach a paired number the team can move directly, think through how a target on it could be gamed, and finally pin down where the value is read from. The metrics that skip the first line are the ones that come off the dashboard first. The order matters because each step constrains the next: a decision about pricing and a decision about onboarding need different counting rules even when both are called activation, and a rule that cannot be read out of any existing table is not a rule yet.

"Where is that number defined? It doesn't match what our dashboard shows."

The same metric name is being counted two different ways, so the reference document has to be settled first.

"That's an output, so the team can't move it directly enough to make it this quarter's goal."

It sits on the result side, which means setting it as a target doesn't tell anyone what to do tomorrow.

"Don't just send the rate. Send the denominator with it."

Somebody needs to check whether the percentage improved or the base simply shrank.

At Pagedeck the metrics get reworked in the week before quarterly goals are set. Mia opens last quarter's list and asks the same two questions of every line: what did we change after looking at this, and when this value moved last quarter, who decided what? Lines with no answer come off the dashboard. The first time the team did this, thirty-two lines became nine. Several of the twenty-three that came off had been going out in an automated weekly email, and in the three months after removal nobody went looking for them.

Grace and Mia then attach a definition document to each of the nine. Theo checks whether each definition can actually be computed from the data on hand, since a definition can read perfectly well and still require six months of records nobody kept. Skip that check and halfway through the quarter someone says the metric can't be pulled yet, leaving a goal standing empty. The replacement found in a hurry is usually whatever is easiest to query, which is rarely what the team cared about. The cheap fix is to run the check while the goal is still a draft, because adding a record now costs a day and adding six months of history costs six months.

The most common assumption is that numbers are objective, so adopting metrics ends the argument. Numbers feel like the opposite of a shouting match. But judgment already entered at the moment someone chose what to count. Whether active users are counted by login or by editing is not settled by the data; it is settled by the product. When that choice stays invisible in the meeting, the disagreement does not disappear — it hides. On the surface everyone is agreeing while looking at one dashboard, and underneath they are imagining different products and reading the same figure. Those teams collide again at the end of the quarter, starting from scratch. The way out is small and slightly tedious: when a definition is proposed, say out loud which product belief it encodes, and let people disagree with the belief rather than with the arithmetic.

Believing that more metrics mean a better grip on reality is the other frequent mistake. Thirty items on a screen feel complete, so nothing seems to be missing. In practice nobody reads thirty items weekly; three or four familiar ones get read and the rest become background. When the item that breaks is sitting in that background, two months can pass before anyone notices. More items also raise the odds that something is off somewhere every week, and a screen that is always partly red trains people to ignore red. The trimming rule is short: keep only the items for which you can state, in one line, what you would do differently if the value moved. Deleting the rest costs nothing. If one becomes necessary later it can be pulled again, and until that day it only takes up screen space and weekly attention.