I think a lot of onboarding problems start earlier than teams want to admit.
Not in the signup form.
Not in the checklist.
Not in the empty state.
Earlier.
They start in the promise.
By promise, I mean the idea a user bought into before they ever touched the product:
- the ad they clicked
- the SEO page they landed on
- the use case the homepage emphasized
- the colleague recommendation they heard
- the lifecycle email that pulled them back in
That promise creates a mental contract.
The user shows up expecting progress on a particular job. Then a lot of products greet them with a generic onboarding flow that seems designed for a completely different person.
That is usually where the drift begins.
The team thinks it has an onboarding problem.
Often it has a continuity problem.
Growth work gets cleaner when you follow the user’s narrative
One reason I still come back to Clayton Christensen’s Jobs to Be Done framing in Harvard Business Review is that it forces a more useful question than “how do we get more users through setup?”
It asks what job the user is actually trying to make progress on.
That matters because users do not arrive as blank slates. They arrive with context.
If someone clicked because the page promised:
- faster reporting
- easier team coordination
- help getting started with studying
- less manual follow-up
then the first-run experience has to honor that expectation quickly.
If it does not, the user starts doing translation work:
- “Is this actually for my use case?”
- “Did I click the wrong thing?”
- “Why am I being asked to do this before I’ve seen the benefit?”
That translation tax is easy to miss because it rarely appears as a dramatic bug. It just shows up as weaker conversion, softer activation, lower return rates, and vague feedback about the product feeling confusing.
A lot of onboarding is too generic for the promise that created the visit
I do not mean every user needs a fully bespoke experience.
I mean teams often flatten meaningful differences too early.
One acquisition path may bring in users with a very specific use case and high intent. Another may bring in curious, lower-intent traffic that still needs help understanding the category. A lifecycle email may re-engage someone who already knows the basics but needs a sharper reason to continue.
When all of those users hit the same first-run script, the product quietly asks them to ignore the story that got them there.
That is expensive.
I think NN/g’s piece on progressive disclosure is helpful here, not because onboarding teams need another UX slogan, but because it reinforces something practical, which is that the right next step depends on what the user already knows and what they came to do.
If the product asks for too much too early, or asks for the wrong thing first, it is not only adding friction. It is breaking narrative continuity.
The artifact I like: a promise-to-product map
When a team is hand-waving about onboarding quality, I like forcing the conversation into a small artifact.
Nothing fancy. Just a one-pager.
Promise-to-product map
- Entry point:
- User intent or likely job:
- Promise made before signup or visit:
- First screen or first-run state they hit:
- First meaningful action we ask for:
- Earliest believable value moment:
- Biggest continuity gap:
- What we should delay until later:
- What we should personalize, sequence, or remove:
That artifact is useful because it pulls acquisition, lifecycle, product, and onboarding into the same frame.
Instead of debating whether the checklist should have four steps or five, you start asking:
- what expectation did this user arrive with?
- does the first-run flow help them make progress on that expectation?
- what are we asking them to do before value is visible?
- where are we forcing them into a generic path that made sense to us, not to them?
Those are much better questions.
The continuity gap usually hides in one of four places
When these flows feel off, I usually look for one of four mismatches.
The product opens with setup work instead of job progress
This is the classic one.
The landing page promised a fast path to a specific outcome. The product responds with profile fields, configuration chores, permission requests, and a tour of the interface.
Some of that may be necessary.
But if too much admin work appears before the user touches the core value, the product starts spending trust before it has earned it.
The message is specific, but the onboarding is generic
The acquisition surface may be tightly framed:
- create better study plans
- launch your first SEO page faster
- coordinate team work without spreadsheet chaos
Then the onboarding flow says some version of “welcome, let’s set up your account.”
Technically correct. Strategically weak.
The user had a reason for showing up. Generic onboarding often strips away that reason right when the product should be reinforcing it.
The first meaningful action does not match the user’s intent
This is where growth teams accidentally optimize the wrong step.
Maybe the first action is easy to measure. Maybe it helps internal systems. Maybe it makes the dashboard look organized.
But if it is not plausibly connected to the user’s expected job, it is just a neat internal milestone.
That is different from progress.
The product asks for commitment before it has earned conviction
Invite teammates.
Connect all your data.
Fill out every preference.
Upgrade your plan.
These asks can be reasonable eventually. They are often premature in the first few minutes.
The product is effectively saying, “Trust me now, understand me later.”
That sequence is backward more often than teams admit.
Why this matters for growth, not just UX
I think onboarding conversations get trapped when they are framed as a UX cleanup exercise instead of a growth system problem.
This is not just about making screens feel simpler.
It is about whether the story told in acquisition survives contact with the product.
That has consequences across the funnel:
- paid traffic underperforms because high-intent users do not find the promised path quickly enough
- SEO traffic bounces because the product experience does not match the use case the content page framed
- lifecycle reactivation weakens because returning users are dropped into the same generic flow as first-timers
- activation metrics blur because teams count setup completion instead of value-consistent behavior
I still think Andrew Chen’s “Retention is King” essay is a useful anchor here. Not because every onboarding issue is a retention issue, but because it reminds growth teams that early funnel wins become fragile when they are not connected to real long-term value.
Message mismatch is one of the ways that fragility enters the system.
What I would do with this in practice
If I were working this problem with a team, I would not start by redesigning the onboarding flow in the abstract.
I would start by mapping a few high-volume or high-intent entry paths:
- homepage or major use-case page
- one important acquisition channel
- one lifecycle re-entry path
- one high-value segment with a distinct job to be done
Then I would ask:
- what exact promise brought them here?
- what does the product ask them to do first?
- what would a more believable first value moment look like?
- which asks should move later?
- where could we tailor the first-run experience without overengineering the system?
Usually you do not need deep personalization to improve this.
Often the fix is more basic:
- change the order of steps
- rewrite the opening copy to reflect the user’s intent
- suppress low-value asks early
- route users into a more relevant starting state
- bring one use-case-specific example forward
That is not glamorous work.
It is extremely leverageable work.
A simple gut check
Take your top acquisition path and answer this honestly:
If a user clicked because of the promise we made there, would the first three minutes in product feel like a continuation of that story?
If the answer is no, I would resist polishing the onboarding checklist until that mismatch is clearer.
The team may still need better UX.
But the higher-order problem is usually that the product forgot what the user came for.
The point
Some onboarding problems are really onboarding problems.
Some are actually promise problems.
Or more precisely, promise-to-product continuity problems.
That is why I like mapping the story before optimizing the screen.
Growth work gets better when the product remembers the expectation that earned the click in the first place.
