Product measurement exists to help teams make better product decisions.
That purpose is easy to agree with and surprisingly easy to lose. A metric can be carefully calculated, beautifully displayed, and regularly reported without changing anyone’s understanding or behaviour.
The test is not whether the number is technically valid. The test is whether the team knows what job the number is doing.
Give measurement a job
Teams often ask for measurement through the output they expect to receive:
- “Can we get a dashboard?”
- “Can we track conversion?”
- “Can we report engagement?”
- “Can we see the drop-off?”
- “Can we measure adoption?”
Those requests may be reasonable, but they are incomplete. Before naming the metric or choosing the chart, ask:
That question turns a reporting request into a measurement problem. It connects the evidence to a use.
Six common jobs of product measurement
Most product measurement supports one or more of six jobs.
| Job | What measurement helps the team do | Example question |
|---|---|---|
| Monitor | Keep watch over an important workflow, outcome, or risk | Are people still able to register and access the product? |
| Diagnose | Locate where a problem may be happening | At which point are applications most often delayed or abandoned? |
| Evaluate | Judge whether a change had the intended effect | Did the revised form reduce avoidable validation errors? |
| Compare | Understand differences between groups, contexts, or periods | Are mobile users struggling more than desktop users? |
| Prioritise | Decide which problem or opportunity deserves attention | Which workflow issue affects the most users or creates the greatest risk? |
| Maintain | Check whether the measurement itself remains trustworthy | Does this metric still represent the workflow we think it does? |
The distinction matters because different jobs require different evidence.
A monitoring metric needs stability and an expected range. A diagnostic view needs enough detail to locate the problem. An evaluation needs a credible comparison and clear limitations. A prioritisation metric needs context about scale, value, risk, and effort.
One number rarely performs all six jobs well.
Not everything needs equal measurement
A product contains more behaviour than a team can usefully instrument, analyse, and maintain. The aim is not to measure every interaction. It is to invest in evidence where better understanding could change something important.
A workflow is a strong candidate for measurement when one or more of these conditions is true:
- an important decision is blocked by uncertainty;
- user, service, or organisational value depends on the workflow;
- failure creates meaningful cost, harm, or operational risk;
- the product or workflow is about to change;
- teams disagree about what is happening;
- existing evidence is weak, incomplete, or no longer trusted.
This prioritisation should happen before instrumentation. Tracking a low-value workflow perfectly is still a poor use of time.
A useful test is:
What decision would become easier, safer, or more informed if we understood this workflow better?
If the team cannot answer, the measurement request may not be ready.
Questions connect evidence to decisions
A clear product question does not dictate one metric. It defines the problem the evidence needs to serve.
| Product question | Evidence that may help | Decision supported |
|---|---|---|
| Are people able to create an account and reach the product? | Registration starts, submissions, verification, first access, errors, and user feedback | Where should we improve or investigate the registration workflow? |
| Are mobile users struggling to complete checkout? | Workflow events by device, performance data, errors, and usability findings | Should mobile checkout fixes take priority? |
| Are organisations creating plans they can act on? | Plan progress, completion, revisions, exports, follow-up activity, and stakeholder research | Which part of planning needs more support or clearer evidence? |
| Are people returning after first use? | First-use cohorts, return behaviour, reminders, support contacts, and research | Is the problem onboarding, relevance, timing, or ongoing value? |
The evidence may include event data, research, support feedback, operational records, experiments, or technical logs. Product measurement is stronger when it uses the right combination rather than expecting one analytics metric to explain the whole experience.
Measurement improves confidence, not certainty
Good measurement does not remove uncertainty. It makes uncertainty easier to see, discuss, and act on responsibly.
A team may not know exactly why every person left a workflow. It can still identify where behaviour changed, which explanations are plausible, what evidence is missing, and what investigation should happen next.
That is enough to make many decisions better.
A useful measurement system does not promise a perfect answer to every question. It gives the team a clearer basis for choosing what to monitor, what to investigate, what to change, and what not to touch.
A metric without a question behind it and a possible use in front of it is not yet doing product work. It is a number waiting for a purpose.