Measure the few signals that would change what you do next

The Measure stage of my method says: instrument the few signals that would change what happens next. The emphasis is on few and on change.

Most products are over-measured and under-informed. They collect hundreds of events, build dashboards full of charts, and still cannot answer the question that matters this week.

The test for a metric

Before adding a metric, I ask one question: if this number came back very different from what I expect, what would I do differently?

If the honest answer is "nothing", the metric is decoration. It might be interesting. It will not change a decision. It will, however, take time to build, clutter the dashboard, and make the metrics that do matter harder to find.

If the answer is concrete — "we would stop building this", "we would change the onboarding", "we would raise the price" — then the metric is worth having, and you already know what threshold matters.

Signals worth having

The useful ones tend to be close to the product's core promise.

• Does the core action happen? Not visits or sign-ups, but the one thing the product exists for: a buyer finding and downloading an asset, a learner completing a meaningful exercise, an inspector closing a finding.
• Does it happen again? Retention on the core action says more than almost any other number.
• Where does it fail? The step where people abandon the flow tells you where to work next.
• What does it cost? For AI-heavy products especially, cost per core action is a first-class product metric, not a finance report.

Signals that mislead

• Vanity totals. All-time sign-ups only go up. They cannot tell you whether things are getting better.
• Averages that hide the distribution. A mean session time can look healthy while most users bounce and a few leave the tab open all day.
• Engagement without outcome. Time spent is not value delivered. Sometimes the best product is the one people finish with fastest.

Instrument deliberately

Decide what you want to know, then instrument exactly that, with names and properties chosen for the question. Events added "in case they're useful" are rarely consistent enough to be useful.

And measure the health of the system separately from the success of the product. Knowing that the site is up and the database reachable belongs in a health check that pages someone. It should not be mixed into the product dashboard, where a broken system can look like a quiet week.

The takeaway

A good measurement plan fits on a page. For each metric: what it is, why it matters, and what you would do if it moved. Anything that cannot fill in the third column can wait.