Product success metrics: the numbers that actually drive decisions

Ask a team that has built a product, "how do you know it worked?" If the answer is "users like it" or "traffic is good", that product has no metric.

Without one, every discussion about priorities comes down to taste, and the loudest voice wins.

Vanity metrics and actionable metrics

A vanity metric is a number that usually goes up, feels good and changes no decision: total sign-ups, page views, downloads.

An actionable metric is a number that tells you what to do when it changes.

A simple test: "If this number halved tomorrow, what would we do differently?" If you have no answer, the metric is decoration.

Start from value, not from data

A common mistake is to see what can be counted and make that the metric. The right order is the reverse:

1. What value does the product create for the user?
2. At what moment does the user receive that value?
3. What behaviour shows that moment happened?
4. Count that behaviour.

For a sales assistant the value is "the customer got an answer and the purchase was completed". So the metric isn't the number of messages. It is the share of conversations that reached an outcome.

One primary metric

A team tracking ten metrics is tracking none. It is better to have one primary metric that sums up the product's value — what people call the north star.

A good primary metric:

• Is tied to user value, not only to your revenue.
• Can be measured, regularly.
• Can be influenced by the team.
• Is understood by everyone.

Beside it sit a few supporting metrics that explain why the primary one rose or fell.

Guardrail metrics

Optimising one number can break another. Push only on "sign-up rate" and you may bring in users who leave tomorrow.

For each primary metric, define a guardrail that must not get worse:

• Response speed goes up, but answer accuracy doesn't go down.
• Sales go up, but the return rate doesn't.
• Cost goes down, but satisfaction doesn't.

Decide the metric before building

The success metric has to be set before the build, not after. Set afterwards, there will always be some number that looks good.

That is why, in my process, the success metric is part of the output of the Define stage and is recorded in the product requirements document. The gate for that stage says the same: scope and success criteria are locked.

A clear metric also makes scoping version one easier: a feature that doesn't serve the metric has no place in v1.

Beware the number without a source

A standing principle in my work: no claim without evidence, no number without a source.

A number whose origin you don't know is more dangerous than no number, because it drives decisions with false confidence. For every metric it should be clear:

• Exactly what is being counted?
• Over what period?
• From which data source?
• What has been excluded?

Two people who define "active user" differently will never agree.

Measurement and privacy

You don't need to know everything about a user to measure. Most useful metrics come from simple, anonymous events: "form submitted", "step two completed". Collecting less is both safer and more respectful.

Common mistakes

• Too many metrics. A dashboard with thirty charts nobody looks at.
• A misleading average. An average can hide two completely different groups.
• Targeting the metric. Once a number becomes a target, people find a way to raise it even if the product doesn't improve.
• Short-term view. A metric that looks good for a week can be a disaster over a month.
• Forgetting qualitative feedback. The number tells you what happened; talking to users tells you why.

The takeaway

A good metric is simple: tied to real user value, set before the build, precisely defined with a known source, and clear about what to do when it moves. One primary metric, a few supporting ones and a guardrail are enough for most products.

Related: seven questions before the first line of code.