When Did Onboarding Become the Product?

Cover Image for When Did Onboarding Become the Product?

Canva puts you in front of a blank canvas in under sixty seconds. Pick a format, choose a template, start designing. The product is the canvas. The onboarding is invisible because the canvas is the point, and they trust you to figure it out.

Other products take a different approach. Create your workspace. Name your workspace. Invite your team — or skip for now. Choose a template. Set up your first project. Watch the tutorial. No, really, watch the tutorial. Okay, you can skip the tutorial. Here's a tooltip about the sidebar. Here's a tooltip about the tooltip.

Both call this onboarding. Only one of them is treating you like someone who came to use their product.

What "Activation" Actually Measures

Product teams discovered that onboarding completion correlated with retention. Users who completed the setup flow stayed longer than users who didn't. The conclusion: improve onboarding, improve retention.

The problem is that correlation pointed in the wrong direction. Users who completed onboarding didn't stay because they completed onboarding — they stayed because they were motivated enough to push through it. You can have a terrible onboarding flow and still have high completion rates if your product is valuable enough that people are willing to tolerate the friction. The completion rate doesn't tell you whether the onboarding helped.

Activation metrics compounded this. "Activation" — the moment a user is considered truly "in" the product — got redefined as completing a checklist. Hit five milestones and you're activated. The milestones got added to the onboarding. The onboarding got longer. Activation rates went up. Retention didn't follow.

This is the same pattern that killed progressive disclosure: a design principle that served users got replaced by engagement metrics that served the product. The result looks like user-centered design and isn't.

Samuel Hulick documented this exhaustively at UserOnboard.com — a long-running project of UX teardowns that dissects how products guide new users. His consistent finding across hundreds of products: the most effective onboarding flows focus on one thing, deliver one moment of value, and get out of the way. The worst ones make the user do the product's setup work while calling it an experience.

The Jobs-to-be-Done Problem

Clayton Christensen's jobs-to-be-done framework is useful here. Users don't hire products — they hire products to do a job. Someone signs up for a project management tool because they have a specific project they want to manage. Someone signs up for a design tool because they want to make something.

The job was there before the product. The product is supposed to help them do it.

Every step of onboarding that delays the user's ability to do their job is a step the user is paying for with their patience. They're not there to configure a workspace. They're there to manage the project. Configuration is friction between them and the job, and friction compounds: each additional step is a new opportunity to decide this isn't worth it.

The users who drop out of long onboarding flows aren't the low-intent users. They're often the high-intent users who actually needed the tool urgently, couldn't figure it out in the first session, and went looking for something faster. You've selected for people with time and patience. That's a different user than the one you designed for.

Canva understood this intuitively. The job is "make something visual." The product is the canvas. Everything else — templates, export settings, collaboration features — comes after you've made something. They don't explain the product. They let you use it. Their growth to 100 million users wasn't just content marketing; it was a UX philosophy that treated the user's time as the cost of entry and tried to minimize it.

The Setup Tax

There's a category of onboarding that's become normalized which I'd call the setup tax: making users do configuration work that benefits the product's data model before they can access the actual functionality.

"What's your role?" — so they can segment you for marketing. "What's your team size?" — so they can slot you into a pricing tier. "What are you trying to accomplish?" — so they can personalize the experience (they won't). "Invite your colleagues" — so they can expand the account before you've decided if you like it.

This isn't user-centered design. It's company-centered design wearing UX clothing. The user isn't getting value from these steps. The product is. The user is paying a setup tax so that someone else's CRM gets richer data.

The tell is simple: if you removed this step, would the product work worse for the user? If not, the step isn't for the user.

Contrast this with Duolingo's early onboarding: pick a language, pick a goal (I'm traveling, I want to connect with family, I'm curious), start a lesson. Three steps. Two of them directly configure the experience the user asked for. One of them is the experience. The setup that happens — language model calibration, notification scheduling, streak initialization — is invisible.

The cognitive load this creates isn't neutral. Every step requires a decision. Every decision has a cost. Users arrive at your product with a finite amount of patience, and your onboarding is spending it.

The Empty State Opportunity

The most underused design surface in product development is the empty state — the first experience a user has with the actual product, before they've created any content.

Most teams treat empty states as placeholders. A gray illustration, some encouraging copy, a "Create your first X" button. The assumption is that the onboarding flow prepared the user for this moment. It didn't. The onboarding flow filled time. The empty state is where the product's actual usability is first tested.

The best empty states are mini-products. Figma's empty state shows you example files and a "New Design" button. The example files teach you what the product can do. The button gets you started. No instructions needed — the environment answers the implicit question "what am I supposed to do here?"

Airtable's empty state used to do the opposite: it dropped you into a blank grid with no context. Users familiar with spreadsheets understood it instantly. Everyone else bounced. Airtable eventually added suggested templates, which didn't solve the conceptual gap but at least gave users something to anchor to. The problem was upstream — the product required mental models that onboarding didn't build.

When onboarding fails, teams add more onboarding. When the product is unintuitive, teams add more explanation. This loop produces the six-screen tooltip tour, the mandatory video, the progress bar tracking your journey through a checklist that exists to make you feel accomplished before you've done anything.

The right intervention is usually in the product itself, not in the onboarding that precedes it.

The Constraint Worth Accepting

There's a design constraint that would make most products better and most product teams uncomfortable: what if onboarding was limited to sixty seconds?

Not as an aspiration — as a rule. You get sixty seconds of the user's time before they're in the product. You can spend it explaining one thing, doing one setup step, or delivering one moment of value. Pick.

The constraint forces a question most teams avoid: what is the one thing a user needs to understand to get value from this product on their first try? If the answer is "we need to explain several things," that's a product problem disguised as an onboarding problem.

The best onboarding is invisible because the product is clear enough to not need it. That standard is high. Most products don't reach it. But the solution isn't more onboarding — it's iterating on the product until the friction that prompted the onboarding disappears.

What would your product look like if onboarding wasn't allowed?


Photo by Davide Baraldi via Pexels.