Skip to content

Leading Signal Tracking

Adoption, completion, error encounter rate. The signals that arrive in days, not weeks. What the team watches in the first 48 hours and the first three weeks after release — before the prediction can be honestly checked.

Owners: PO, Data, Tech Lead Phase it lives in: How We Build → After We Build The corpus principle this enacts: The check is observation, not a report.

Where it lives in the chain

The leading signals

  • Adoption rate — what fraction of the target audience has touched the feature? Slow adoption is itself a signal — the feature may be invisible, confusing, or unnecessary.
  • Completion rate — of users who started the flow, what fraction finished? Drops at specific states reveal flow gaps.
  • Error encounter rate — per user, per session, per state. A specific error spiking is a leading indicator of a bug not yet filed.
  • Time-on-state — for slow states (grading, reconciling), the time spent. A spike means the operation is slower in production than staging.
  • Recovery rate — for error states, what fraction self-recovers vs abandons vs escalates to support?

What good practice looks like

The signals are wired before the flag is enabled — that was a release-gate condition. The dashboards are named, owned, and rehearsed. The PO knows which signal answers which brief question:

  • "Do graders adopt the new shortcut?" → adoption rate of the shortcut event.
  • "Does it actually save time?" → time-on-state for the grading state.
  • "Does it confuse anyone?" → recovery rate from error states + helpdesk volume.

Leading signals don't replace the prediction check. They tell the team whether the prediction is on track before the check date arrives. A leading signal pointing wrong is permission to investigate now — not to declare the prediction wrong. The signal reading still lives next to the brief; leading signals feed it.

200apps · How We Work · NWIRE