contents
You signed up for a SaaS tool last week. You don’t remember which one. There was a welcome modal, then a question about your role, then a question about your team size, then a four-step “let’s customize your workspace” carousel, then a tooltip explaining the sidebar, then a sample project pre-loaded with fake data, then a banner asking if you wanted to invite teammates. You closed the tab somewhere around step five. You meant to come back at some point, but of course you didn’t.
The team that built that flow spent two months on it. Every step was someone’s idea, defended in a meeting, refined in design review, even A/B-tested. They’re proud of it. It’s the reason their activation rate is 11%.
“Onboarding” is one of those words that lost its meaning by becoming too standard. Founders use it to mean the multi-step flow between signup and the product. But the flow is what they built when they confused onboarding with education or personalization. The actual onboarding (the thing the user is doing), is forming an opinion about whether the product is worth coming back to. That happens whether you ship a wizard or not, and the wizard doesn’t always help.
There’s a way to frame this: Onboarding is an editorial discipline. The job is to cut things until what’s left is the smallest experience the user can have and still feel something. Most founders, including myself, treat it as a building discipline instead, a place to add features, options, explanations, education. Often, we end up reducing activation when the goal was the opposite.
The only known exceptions are consumer behavior-change subscription products like Noom or Calm or Duolingo. For everything else (e.g. tool-shaped products, B2B SaaS, dev tools, productivity apps, and most consumer apps), the user is signing up for something they want to use, and the rule holds.
The instinct is wrong on purpose
The reason founders overbuild onboarding is that the people building the product are, by definition, the people who already understand it. When you understand a product, every feature looks like an asset. You added it for a reason, so surfacing it during onboarding feels like generosity. “Look at all the things you can do here. Welcome.”
This happens to every product team eventually. Improvements are always seen as additions, not subtractions. And additions to onboarding flows almost always cost more than they earn back. This is because the user doesn’t see assets. They see a tax. Every screen between signup and the first useful action is a place they can quit. We’ve noticed this in our own product more than once: the team’s instinct is to build a “good first experience,” and every time we ship that good first experience the activation rate either stays the same or drops. Our instincts keep pulling us in the same direction.
The fix is to intentionally and painfully cut down to a narrower experience. Sam Altman’s startup playbook makes the point bluntly: simplicity beats feature-richness at early stage, and friction kills growth more than missing features do. Most founders flip the priority and lose months of compounding to it.
What “editing” looks like in practice
The clearest tell that a team is doing it wrong is the configuration step. Some configuration is genuinely required: connecting a calendar, picking a primary email, or naming a workspace. Most of it isn’t. Most of what teams put in front of new users is configuration that could be deferred until after the user has done something useful, and is sitting in the onboarding flow because it felt thoroughly considered to put it there.
Configuration during onboarding is a tax on the roughly nine users who will never come back, paid in exchange for slightly less friction for the one user who actually uses it. The tradeoff math stays bad even when the configuration is genuinely valuable. Please defer it.
The harder edit is the educational one. Founders confuse onboarding with education. Education is what you do after the user is hooked. Onboarding is what you do to hook them, and it should be ruthless about cutting things that aren’t part of the hook. The tooltip explaining how filters work belongs after the user has typed something into the app, the product tour belongs after the user has saved their first thing, and the “learn more about our integrations” panel doesn’t belong in onboarding at all.
This is one of those lessons we all need to re-learn multiple times. For every screen, tooltip, or extra option: if I remove this, does the user still get to a moment where the product does something for them? If yes, remove it. The screens you keep are the ones where removal breaks a path.
Why this generalizes beyond developer tools
Back in 2011, Stripe’s pitch was that you could accept payments with 7-9 lines of code. Nine lines. At a time when every competitor was selling a multi-step integration that took a week. The “Collison Installation,” where Patrick and John flew to early customers to install Stripe on their laptops, has become famous in YC circles.
Linear loads your default workspace in under a minute. No 10-step wizard, no customization carousel, no quiz about your team’s working style. You’re inside the app, and the next thing you do is type.
Notion’s signup hands you a blank page after three simple questions. Templates exist but you don’t have to use them. The default state is clean, and the first thing the product asks you to do is anything you want.
The pattern is easy to spot, but it’s a lot harder to act on, because every instinct is pulling you the other way.
A reasonable objection is that Stripe is a developer tool and developers are unusually tolerant of bare-bones experiences. The nine-lines pitch works for them, but it wouldn’t work for a typical SaaS buyer who expects a polished welcome flow. But Notion isn’t a developer tool. Linear has plenty of non-developer users on the design and PM side. The pattern crosses categories because the underlying mechanism is about attention. New users have roughly sixty seconds of patience before they form a judgment about whether your product is worth coming back to, and that’s mostly based on whether they got to a useful moment. The welcome flow’s polish has minimal impact.
The second reasonable objection is that a too-simple onboarding will generate customer support load. In practice, support load comes from confused expectations. A clear, narrow onboarding produces a clear, narrow expectation: “I signed up and I’m in the product.” A multi-step wizard produces a much fuzzier one: “I signed up and I’m being prepared for something.” When the product doesn’t match the wizard’s implied scope, that ironically increases support requests.
There’s also the consumer-app exception. Long onboarding quizzes really do increase activation and retention for some apps in that space. The clearest case is Lose It!‘s own PM saying publicly that they just kept extending onboarding and trial starts kept going up, and that they don’t particularly care what the answers are. Perceived personalization works even when the personalization isn’t real, and a meaningful slice of the consumer subscription economy is built on this.
The carveout is narrower than it sounds. It applies to behavior-change products sold on a subscription funnel, where the user arrives with a specific outcome in mind and the personalized program is the product. Health and fitness, meditation, language learning, astrology, focus-and-study apps. The quiz works because of a stack of four things: the calibration is the actual value, each question is a micro-commitment that lifts completion, the time invested produces sunk-cost attachment before the paywall, and a long quiz reads as authority. Remove any of those four and the funnel weakens. Run the same playbook on Linear and you get a worse outcome.
The B2B side is the opposite direction without exception. Top-decile PLG products hit time-to-value in 5-15 minutes, and trials taking longer than seven days see up to 40% fewer conversions. The long onboarding stories in enterprise (Salesforce, Toast, Veeva) are sales-assisted human implementations of integrations that genuinely have to happen for the product to work.
So the rule survives. If you’re building Noom, ignore the rest of this post. If you’re building anything else, editing discipline is crucial.
How to tell if you’re overbuilding it
Some questions, mostly stolen from conversations with founder friends who’ve gone through this:
- What’s the median time from signup to a moment the user would describe as useful? If it’s longer than a minute, the fix is almost certainly cutting things rather than building new ones.
- How many of your onboarding steps are configuration the user could do later? Count them. It’s probably more than half.
- If you cut the entire welcome tour, what breaks? If the answer is “nothing breaks; some users might be slightly confused for five seconds,” you should try surfacing it later.
- Are you confusing onboarding with education? Education materials are good. They belong somewhere else.
- Which steps in your flow were added because a single user complained about not having them?
This audit is uncomfortable because the steps you’d cut are usually the ones the team is proudest of. The carefully designed personalization quiz and the configuration screen with the sensible defaults, not to mention the tasteful product tour. They look like craftsmanship. But they’re sitting between your user and their first productive moment.
The onboarding flows that win their categories tend to look slightly embarrassing to the teams that built them. There aren’t enough screens to point at when someone asks what the design team has been working on. Even the features that you could have sworn were previously A/B-tested might get cut, the activation rate goes up, and nobody is quite sure how to explain it.
The hard part is what you do on Monday, when the team you’ve worked with for three years pulls up the activation dashboard, looks at the flow they built together, and starts naming the screens they might have to cut. A good onboarding is a hallway, and you walk through it without noticing. A bad onboarding is a hotel lobby with someone in a vest insisting you sign the guest book before they’ll let you upstairs.