Onboard by hand until it stops teaching you

Teams often automate onboarding before they know what it should do. They build tours, tooltips, checklists, and email sequences to explain a product they haven’t yet watched anyone learn.

I’d rather do it by hand first. Talk to each new customer, set them up together, watch them use the product, and follow up a few days later. It’s slow, and it’s still the fastest way I know to learn what a product is missing.

I did most of my onboarding work at American Express and at the startup before it. At Drafter, I still onboard new customers and run demo calls.

What you learn in the room

A dashboard tells you where people drop off. Sitting with them tells you why. You see the step where they hesitate, even though they finish it. You hear the words they use for things, which are rarely the words on your buttons. You learn what they came to do, which isn’t always what the flow was built around.

Then you act on it while it’s fresh. If something breaks, fix it. If something’s unclear, rewrite it. If the value isn’t obvious, rethink the feature.

When software does the work, you’re also setting trust

When a product does part of someone’s work, onboarding has a second job. It sets how much people trust the product.

On a call, you can see an engineer check every dimension on a drawing, or check none of them. Both are problems. The first saves them no time, and the second will eventually cost them a part. A tooltip can’t see either one. A person can say, “This is usually right. Look closely here.” I wrote more about this in Show people what to check.

When to stop

Doing it by hand shouldn’t last forever. It’s time to automate when the calls stop surprising you, when you can predict each question before it’s asked, and when the same fix works for everyone.

At that point, what you’ve been saying on every call becomes the onboarding you build into the product. Keep a few calls on the calendar anyway. The product will change, and so will the people using it.