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