A north star measures value delivered

A north star metric is the one number that best captures the value customers get from your product. Amplitude's North Star framework, written up by John Cutler and colleagues, pairs it with three to five input metrics that the team can move directly. The idea is old and simple: if customers get more of the value, the business results follow, and the team has one shared answer to "are we winning?".

A good north star passes six tests:

• It counts value received, not activity you caused. "Orders delivered on time" counts groceries in a kitchen. "App opens" counts taps.
• It moves before revenue. Revenue and profit are results. They arrive late and have many causes, so they make poor steering numbers (the output, outcome and impact split from pm-11).
• The team can influence it through inputs it controls.
• Anyone can say it in one sentence, from a store manager to the managing director.
• It fits the strategy. Someone reading it should be able to guess what the company is betting on.
• It is hard to game on its own, and where it can be gamed, a guardrail sits next to it.

The opposite is a vanity metric. Mangrove has about 2 million registered customers. That number only ever goes up, even in a week when half of them had a bad experience and stopped ordering. Downloads, page views and total sign-ups behave the same way. They feel good and decide nothing.

Amplitude describes three "games" a product can be playing, and the game tells you what kind of north star to look for. In the attention game (streaming, social media) value is time well spent. In the transaction game (grocery delivery, ride-hailing, wallets) value is a completed exchange. In the productivity game (work tools, internal apps) value is work done faster and more accurately.

Mangrove's customer app plays the transaction game, and its promise is groceries in 30 minutes. A plain count of orders would miss half the promise, so the north star is weekly on-time orders: orders delivered within 30 minutes of checkout, counted per week. Weekly fits a grocery habit. Daily numbers jump with rain and payday, and monthly numbers arrive too slowly to steer by.

From one number to a tree

A north star on its own tells a team whether it is winning, but not what to do on Monday. A metric tree breaks it into the parts that produce it, until each leaf is something one team can move with its own work. Build it in four moves:

1. Write the north star as a formula. Weekly on-time orders = active customers × orders per active customer × on-time rate.
2. Split each part. Parts that multiply are rates and averages. Parts that add are segments that don't overlap: active customers = new customers + returning customers.
3. Add the drivers. Some inputs aren't arithmetic parts but causes. The on-time rate is driven by how fast a store picks the order, how fast a rider is assigned, and how long the ride takes.
4. Stop at a team. A leaf is finished when one team owns it, can move it within weeks, and has a data source for it.

Then put this week's numbers on every box and check they multiply back to the top. At Mangrove: 62,500 new customers plus 187,500 returning (75% of last week's 250,000) gives 250,000 active customers. They place 1.70 orders each, and 91% arrive within 30 minutes. 250,000 × 1.70 × 0.91 = 386,750 on-time orders a week. If your numbers don't multiply back, a definition is wrong somewhere, and you have found it before anyone argued about it.

Notice the difference between the two kinds of link. Arithmetic links are certain: if orders per customer rises 1%, the north star rises 1%. Causal links are beliefs that need evidence. "Better stock accuracy means fewer cut items, which means customers order more often" is a good bet, but it is a hypothesis until data supports it. Draw the two differently, so nobody mistakes a guess for a law.

The drivers of the on-time rate also show why averages mislead. A typical "Now" order spends about 9 minutes being picked and packed, 4 waiting for a rider and 13 on the road: 26 minutes, comfortably inside 30. The late orders are the ones where two stages run slow at once. So the drivers are written as shares of orders inside a time limit ("picked within 10 minutes"), which track the slow tail, instead of average minutes, which hide it. Percentiles and tails are explained in Measuring speed and reliability.

Input metrics a team can move

An input metric earns its place in the tree when it is:

• Controllable: the team's own work moves it. Store operations can change pick paths; it can't change the weather.
• Fast: it moves within days or weeks, so the team sees whether its work is landing.
• Predictive: when it moves, the north star moves too. Check this in past data, and later with a test (Experiments).
• Owned: one team reports it every week.

Amazon calls these controllable input metrics, and Colin Bryar and Bill Carr's Working Backwards (2021) tells how its selection metric was refined. The first version counted new product detail pages, and teams added pages for products few people wanted. It became detail page views, so a page only counted if customers looked at it. Then the share of those views where the item was in stock. Finally, the share where it was in stock and ready for two-day shipping, which Amazon named Fast Track In Stock. Each change came when the old version stopped predicting sales. Expect to refine your inputs the same way.

If you are stuck for inputs, Amplitude suggests four prompts: breadth (how many customers or stores use it), depth (how much of the job they do in the product), frequency (how often) and efficiency (how fast or cheaply the job gets done).

Which input moves the north star most?

The arithmetic is short. In a product of factors, a 1% rise in any factor raises the result by 1%. In a sum, a 1% rise in one part raises the total by that part's share. New customers are 25% of active customers, so 1% more new customers adds only 0.25% to the north star.

North star now: 250,000 active x 1.70 orders x 91% on time = 386,750

+1% orders per customer (1.70 -> 1.717)       +1.00%  = about +3,868
+1% on-time rate (91% -> 91.9%)               +1.00%  = about +3,868
+1% returning rate (75% -> 75.75%)            +0.75%  = about +2,901
+1% new customers (62,500 -> 63,125)          +0.25%  = about   +967

Sensitivity is half the answer. The other half is what a 1% rise costs. Adding 625 new customers a week may be one campaign. Adding 0.9 points of on-time at 91% may need a new dispatch rule, and at 97% it may need many more riders. Put the sensitivity next to the effort, then decide.

Guardrails and counter-metrics

In pm-11 you added guardrails to OKRs. A metric tree needs them for the same reason: any input pushed hard enough can be hit in a way that hurts. Pair each input that can be gamed with a counter-metric, the number that gets worse when the input is hit the wrong way.

One more guardrail protects the measurement itself. Mangrove counts an order as delivered when the rider taps "delivered" in the Rider app. Put enough pressure on the on-time rate and some riders will tap it a street early. So the team also tracks the share of "delivered" taps made more than 100 metres from the address, and customer reports of orders not received. When a metric becomes a target, guard the way it is measured as well as what it measures.

Keep the list short: two to five guardrails for the whole tree, each with a limit written down before anyone pushes. In the cost example, Mangrove's riders can carry the load up to about 95% on time. Above that, every extra point needs more standby riders, and cost per order climbs faster and faster.

Metric trees for internal tools

The Store app sells nothing, so its tree plays the productivity game: value is work done faster and more accurately. Its north star could be supplier deliveries received right in the app per week: received by scanning at the dock, and never corrected later. Each store gets about 4 supplier deliveries a day, so 320 stores receive about 8,960 a week. If 60% are received in the app at the dock and 92% of those are right first time (today about 1 goods received note in 12 is corrected later), the north star is about 8,960 × 0.60 × 0.92 ≈ 4,950.

The inputs come from the four prompts. Breadth: stores where receiving in the app is switched on. Depth: the share of a store's deliveries received in the app. Efficiency: minutes per delivery, which also acts as a guardrail, because an app that slows receiving will be dropped for paper as soon as nobody is watching. Below the inputs sit the things that make or break them on a handheld: staff signed in at shift start, scanners charged, and offline receipts that sync without errors (Offline-first apps and data sync).

The link to the customer tree matters in two ways. It lets Imran explain the Store app's work in the terms the managing director already uses: better receiving should mean fewer cut items and more repeat orders. And it warns him not to steer by stock accuracy alone, because accuracy also depends on theft, damage, counts and DC deliveries, and it moves over months. The Store app team steers by its own north star and reports the downstream link once a quarter.

Internal tools add one trap that consumer apps rarely have: what counts as "a delivery" in the denominator. If stock transfers from the DC, which arrive with an electronic note and are always received in the app, are mixed with supplier deliveries, the adoption number looks better than the dock really is. You will take that number apart in Funnels, activation and adoption.