How to choose a North Star metric that changes what you do on Monday

By Meet Patel · 2026-10-03 · 6 min read

Amplitude's article on product North Star metrics lists a few example metrics, and two of them are worth reading slowly. For early Facebook, it gives the number of users adding seven friends in the first ten days. For a self-serve SaaS product, it gives the number of trial accounts with more than three active users in the first week. Each one is a count, a window of time and a threshold of customer behavior. Neither contains the word revenue.

That is the shape of a useful North Star metric: a measurement of the behavior that tells you a customer got value, small enough to read every week. The rest of this post sets out the criteria, a test I would apply before adopting any candidate, a worked example with invented numbers, and the mistakes that most often turn a North Star into a number nobody acts on.

What a North Star metric has to do

Amplitude's article says a strong North Star meets three requirements. It aligns to customer value, meaning it reflects an action inside the product where the customer realizes the value. It represents product strategy, so a reader can infer from the metric where the company is heading. And it is a leading indicator, positioned as far upstream of revenue as it can be, because a leading indicator gives a signal before the financial result arrives. The same article warns that lagging indicators such as monthly revenue or average revenue per user give no early signal of product impact.

I would add a fourth requirement, because the first three can all be satisfied by a metric that sits on a dashboard and changes nothing: the metric has to change a decision in the weekly meeting. Otherwise the company has a measurement and no North Star.

The Monday test

Take the candidate metric and imagine it fell 10% last week. Write down, by name, what each person would do differently on Monday morning. Three outcomes are possible.

• Someone has a specific action. The onboarding owner checks the first-session flow, or the lifecycle owner changes a reminder. The metric has a diagnosis path, and you can build input metrics beneath it.
• The answer is “investigate”. This is a partial pass. The metric needs inputs that tell the investigator where to look, and until they exist it works as a smoke alarm only.
• The answer is “wait and see”. The metric is lagging or too coarse. Revenue and total registered users usually land here.

Then run three checks against the evidence you already have.

1. Customer language. Could a customer describe the measured action as the reason they use the product? “Sent an invoice that got paid” passes. “Logged in” does not.
2. Reach. Can a team ship a change this quarter and see the metric respond? If movement depends on a macro cycle or on a sales team's pipeline, the product team cannot steer by it.
3. Lead. Take the last twelve months, line up the candidate against revenue three months later, and look for cohorts where the candidate moved first. If you cannot find one, you are guessing that it leads.

The lead check deserves honesty about small data. With a few dozen accounts, a cohort comparison will be noisy, and the result is a hypothesis to test over the next two quarters, which is a weaker thing than proof.

Why revenue fails the test

Take a hypothetical 15-person invoicing software company with 500 paying accounts at $50 a month, which is $25,000 in monthly recurring revenue. In one month it raises the price to $55. Monthly recurring revenue rises 10%, to $27,500, while 25 accounts (5%) quietly stop sending invoices.

Revenue reports a good month. The 25 inactive accounts still pay, because many are on annual plans, so their departure will appear in the revenue line months from now, after the cause is old. A team steering by revenue sees green throughout the period when the useful signal was red. The numbers are invented, but the mechanism is general: revenue records decisions customers made one to twelve months ago, and a leading metric records what they are doing now.

A worked example, from candidate to North Star with inputs

For the same hypothetical company, candidates might be registered accounts, monthly recurring revenue, invoices sent per week, and accounts with at least three invoices paid through the product in the week. Run them through the test.

• Registered accounts counts curious people and almost never falls, so a 10% drop in a week is close to impossible. It fails the Monday test.
• Monthly recurring revenue fails as shown above.
• Invoices sent per week responds to product changes, but a handful of large accounts can dominate it, and sending an invoice does not mean the customer got paid.
• Accounts with three or more invoices paid through the product in the week reflects customer value (getting paid), shows both breadth and depth, and responds to shipped changes.

The last one becomes the North Star. Write the definition so that a new analyst could compute it without asking anyone: an account counts in a week if at least three invoices it sent were marked paid through the product between Monday 00:00 and Sunday 23:59 UTC. Every term has an edge (which time zone, which events count as paid, whether test accounts are excluded), and each edge is a place where two teams can silently disagree.

Now give the metric four input metrics, each owned by a single person:

1. New accounts reaching a first paid invoice within 14 days (owner: onboarding).
2. The share of active accounts sending three or more invoices a week (owner: core product).
3. Lapsed accounts that come back and pay an invoice in a given week (owner: lifecycle messaging).
4. Median time from signup to first paid invoice (owner: payments).

On Monday the metric shows a 10% drop, the second input is down and the others are flat. The core product owner has a place to start, which is the invoice creation flow. That is the Monday test passing: the metric produced a named action for a named person. Amplitude's framework likewise pairs the metric with a small set of inputs that teams can influence through daily work, so different teams move different inputs while reading the same North Star.

Mistakes that turn a North Star into decoration

• Choosing revenue. It matters, and it belongs in the board pack. It sits too far downstream to steer weekly product choices.
• Choosing a count of everything. Registered users, page views and downloads rise with marketing spend and say little about value received.
• Hiding a definition change. If “active” means something different in Q3 than in Q2, the trend line carries a break nobody can see. I have written about how three systems can each give a different answer to one metric, and the fix is a written definition with one owner.
• Naming two North Stars. The second one is an input, or the company has not decided what it is optimizing for.
• Never auditing drift. A metric that was sound at launch can drift as the product changes, a pattern covered in why KPIs drift before anyone notices. Put a review date on the definition.
• Ignoring activation quality. If the North Star counts a first action that customers take and then abandon, it overstates value. The argument in your activation metric is a lie applies here directly.

A checklist to adopt or reject a candidate

1. It counts a customer action that signals realized value.
2. A reader can infer product strategy from it.
3. It moved before revenue in at least one historical cohort.
4. A shipped change can move it within a quarter.
5. It has between three and five inputs, each with one owner.
6. Its definition is written down, with an owner and a review date.
7. If it fell 10% this week, someone can say what they would do on Monday.

A North Star metric earns its name by the Mondays it changes. Choose the measurement whose movement someone can already name an action for, and put the revenue figure where it belongs, in the report that confirms the result.

Written by Meet Patel — startup operator and growth strategist in Dubai.

Read on themeetpatel.com