Success Metrics That Survive Review

Most success metrics in a PRD cannot fail. They are written so that almost any outcome can be read as having met them, which means the launch cannot be evaluated — only declared successful by whoever is most invested in it having been.

A metric that survives review is one where somebody could look at the result in six weeks and say no, that did not work. Three properties make that possible.

1 · Measurable

Not "could be measured in principle" — measurable with data you already collect, or will collect before launch.

The common failure is a metric that requires an event nobody emits yet. "Increase feature adoption" assumes something logs adoption. If instrumentation does not exist, it is a dependency with a lead time, and it belongs in the spec as one rather than being discovered the week you try to read the number.

The second failure is measuring a proxy and reporting it as the thing. Page views are not understanding. Session length is not value — it is equally consistent with someone being confused. If you must use a proxy, name it as one.

2 · Attributable

The hardest of the three and the most often skipped.

If the number moves, can you tell it was your change? A quarter contains a pricing test, a marketing push, a seasonal swing and four other releases. "Signups increased 12%" is not evidence about your feature unless something isolates it.

Three things make a metric attributable, in descending order of rigour: a controlled experiment, a cohort comparison (users who touched the feature versus those who did not, with the obvious selection caveat), or a metric so specific to the feature that nothing else plausibly moves it.

That third one is underrated and usually available. "Median time to publish a saved view" is hard to confound. "Weekly active users" is nearly impossible to attribute to any single release, which is why it appears in so many PRDs and settles so few arguments.

3 · Baselined

A target with no baseline is not a measure, it is a wish.

"Increase activation to 40%."

From what? If nobody knows today's number, 40% is unfalsifiable in both directions — you cannot tell afterwards whether it was a stretch or a rounding error, and neither can anyone reviewing the spec.

Two honest ways to handle a missing baseline:

• Establish it first. Make that the first task, and write the target once you have the number.
• Say it is unknown. "Baseline unknown; we will instrument and set a target after two weeks." This is a perfectly good line in a PRD and a far better one than a confident number resting on nothing.

What does not work is picking a plausible-sounding figure so the section is not empty. Reviewers who notice will discount everything else in the document by the same amount.

The guardrail

Success metrics tell you it worked. Guardrails tell you to stop. They are different questions and a spec with only the first has no brake.

Adoption can rise while latency degrades, support volume climbs, or conversion elsewhere quietly drops. Name one or two numbers that would make you pause a rollout, with thresholds — the same discipline the Launch Plan template applies to phases.

A launch that hit its target and broke something adjacent is not a success you found out about early. It is one you find out about in a quarterly review.

The counting rules nobody writes

This is where most metrics quietly become unfalsifiable, and it is almost always omitted:

Who is in the denominator? All users, active users, users who reached the feature, or users eligible for it? The same numerator gives wildly different percentages, and the choice usually gets made after the data arrives — by whoever is reporting it.

Over what window? Seven days, twenty-eight, since launch? Daily active rates and monthly ones tell different stories about the same product.

When does it count? Does a user who tried the feature once count as adopting it? Twice? Did they have to complete something?

Who is excluded? Internal accounts, trials, the enterprise pilot that behaves nothing like everyone else.

Four lines. Without them the metric is decided retroactively, which is the definition of a number that cannot fail.

Survives versus does not

Does not survive	Survives
Increase user engagement	Median saved-views per active workspace rises from 0.4 to 1.2 within 30 days of GA
Improve onboarding	Share of new workspaces completing a first critique within 7 days rises from 31% to 45%
Reduce support load	Tickets tagged invite-expired fall from ~20/month to under 5, measured over 60 days
Users find it faster	p95 time from list view to opened asset drops below 3s, from 7.4s today

The right column is not longer because it is more thorough. It is longer because it contains the decisions — denominator, window, baseline, threshold — that the left column leaves for later.

When you genuinely cannot measure

Some work is not measurable on a useful timescale. A migration, a refactor, a compliance obligation, a foundation for something three quarters out.

The honest move is to say so rather than to manufacture a metric. "This is not measurable in the usual sense; success is that the migration completes with no data loss and no customer-visible incident" is a legitimate success criterion. It is checkable, it can fail, and it does not pretend to a rigour the work does not have.

What corrodes trust is the invented proxy — attaching an engagement metric to a compliance project because the template had a field for it. Reviewers can tell, and the next real metric you write gets read with the same scepticism.

FAQ

What makes a good success metric? It can fail — measurable with data you have, attributable to your change, and baselined.

How many? One primary, one or two guardrails. Two primaries means you have not decided what success is.

What is a guardrail? The number that makes you stop, as distinct from the one that proves it worked.

What if we cannot measure it yet? Make establishing the baseline the first task. An honest "unknown" beats a confident number resting on nothing.