Writing success metrics into a PRD

The success-metrics section is where a lot of PRDs quietly fail. "Improve engagement," "make onboarding better," "increase satisfaction" — these aren't metrics, they're hopes wearing a metric's clothing. A real success metric tells you, after launch, whether the thing worked.

Specific and measurable

Compare "improve onboarding" with "reduce average onboarding time from 5 minutes to 3 minutes by the end of Q2." The second names the measure, the current value, the target, and the deadline. It aligns the team (everyone knows what winning looks like) and makes the feature testable (you'll know if you got there). If you can't state the current baseline, that's a sign you don't yet understand the problem well enough to build for it.

Tie the metric to the problem

The metric has to measure the actual problem, not a convenient proxy. If the problem is "password resets overwhelm support," the metric is "password-related tickets," not "reset-page views" — you could triple page views and make support's life worse. The right question is: if this number moves, did we actually solve the problem? If not, it's the wrong metric.

Add a counter-metric

Single metrics get gamed, sometimes by accident. Pair your primary metric with a guardrail that would catch unintended harm. Optimizing "time-on-page" can mean a confusing UI that traps people; pair it with task-completion or satisfaction so you'd notice. Optimizing "signups" can mean low-quality signups; pair it with activation. The counter-metric is cheap insurance against shipping a number that goes up while the product gets worse.

Decide measurement up front

Write down how and when you'll measure before you build. Which event, which dashboard, what window after launch, who looks. Metrics defined after the fact tend to drift toward whatever number happened to move — define them while you can still be honest, and you'll get a real read instead of a post-hoc story.