Onboarding is the one flow every single user goes through, and it is often the flow with the least clear owner on a project. Everyone assumes it belongs to whoever built the feature it leads into.
Why it falls through
A feature team owns the feature. A design team owns the visual pass. Nobody is specifically accountable for the sequence of screens between "sign up" and "first meaningful action", because it touches every feature a little and none of them fully. It gets built once, early, under the least scrutiny of any part of the product, and then rarely revisited as the product around it changes.
What we started doing
Every project now names one person responsible for onboarding specifically, distinct from whoever owns the individual features it introduces. Their job is to watch it end to end, on a recurring basis, as the product changes underneath it — not to build every screen personally, but to notice when a new feature has quietly made the existing onboarding sequence wrong.
What tends to go stale first
- References to features that changed — an onboarding tooltip pointing at a button that has since moved.
- Assumed prior knowledge — a step that made sense when the product had one plan tier, confusing once there are three.
- Order — a step that used to be early and useful, now buried after five others added since, each individually reasonable, collectively exhausting.
Support tickets are the signal, if anyone is watching for it
We started tagging support tickets that occur within a user's first week separately from the general queue. When that tag clusters around a specific step, it is treated as an onboarding defect, not a training gap on the user's part — the assumption we used to make by default, and the wrong one more often than we'd like to admit.
A flow every user goes through exactly once is not less important than the features they use every day. It is more important, because it is the only chance the product gets to make its first impression, and there is no second attempt at it for that user.
The measurable change
On one project, reassigning explicit ownership of onboarding — with no new engineering, just a named owner reviewing it monthly against current support tickets — cut first-week support volume by a visible margin within two review cycles. Nothing about the underlying feature set changed. The sequence describing it did.