Product
Onboarding is the product: designing first-run for B2B software
For most B2B tools, the first ten minutes decide the first year. Treat onboarding as a product surface, not a set of tooltips.
Jan 30, 2026 · 7 min read · By Maya Idris
Key takeaways
- Model the jobs, not the features.
- Design the empty, error and return states first.
- Instrument first-run like a product, not a funnel report.
Why tooltips fail
Tooltips describe features. New accounts are trying to finish a job – connect a source, invite a colleague, publish something. Guidance that does not map to a job gets skipped, then the account stalls.
Write the task model first
Nine interviews usually produce four jobs. Write them as verbs, order them by dependency, and put each one on one screen with one primary action.
“Model the jobs, not the features.”
The states are the design
Empty, loading, error and return states are where onboarding actually lives. Design them before the review and the build gets faster, not slower.
Measure the first run, honestly
Instrument job completion and step-level abandonment. Report them weekly with support tickets per step – the pairing keeps the story honest.
A practical checklist
- Interview nine new accounts before designing
- Write jobs as verbs, order by dependency
- One screen, one primary action per job
- Design empty/error/return states first
- Track abandonment per step, weekly
Maya Idris
About the author
Engineering lead
Sets the performance budget before design starts and keeps it in CI. Builds WordPress and product front ends with the same discipline: explicit states, tested routes, documented handovers.
Profile
Next step
Put this into practice
If a note maps to a problem you are facing, send it to us as a question.