The First Five Minutes: Onboarding When You Have No Onboarding Team
Most onboarding advice assumes a product team and a tooling budget. At ten users the fix is not a guided tour, it is the empty state, one obvious first action, and doing it by hand while you still can.
Posted by
RouzbehRelated reading
Using Directories for SEO: Getting Listed, and Building Your Own
Two different tactics get called the same thing. Submitting to directories is a small one-off. Running one is a content asset that compounds, and it only works if the pages say something nobody else has.
MCP or RAG: Which One Does Your AI Feature Actually Need?
MCP connects a model to live data. RAG compresses a corpus that will not fit in a prompt. They solve different problems, and picking the wrong one produces confident wrong answers.
Fundraising After Launch: What Changes Once You Have Real Numbers
Launching turns a pitch from a story into evidence, and that changes who will talk to you and what they ask. Whether to raise at all, the numbers investors look at first, and where to find the right ones.
You spent months getting people to sign up, and then most of them open the product once and never return. That is not a marketing failure and it is rarely a feature gap. It is the first five minutes, where somebody arrives with a vague hope and meets a blank screen with no obvious next move. Almost all onboarding advice is written for companies with a product team and a tooling budget. This is the version for a product with eleven users and one person building it.
Table of contents
Define activation before you fix anything
Activation is the moment a new user has done the thing your product exists to do, once. Not signed up, not looked around. Done it. Everybody's definition is different and yours has to be specific enough that you could write the database query.
Some examples of the shape: sent the first campaign, published the first page, connected the first repository, invited the first colleague. Notice these are all things that produce a result the user can see, which is the test. "Completed profile" is not activation, because nothing happened for them.
Write your sentence down before you touch the interface. Without it you will end up improving whichever screen you happen to dislike most, which is not the same as improving the number.
Do it by hand while you still can
Below roughly fifty users, the correct onboarding flow is you. Email every single person who signs up, personally, and offer to set the thing up with them or for them. Most will decline. The ones who accept will teach you more in twenty minutes than a month of session recordings.
This feels like cheating and it is not, for the same reason doing the manual version of a feature is not cheating when you are scoping the first version. You are buying information at the only price you can afford, which is your own time, at the only moment it is cheap, which is while the numbers are small.
What you are listening for is the exact sentence where they hesitate. Not "the UI could be cleaner" but "wait, is this the thing I paste my key into?" Those hesitations are the onboarding backlog, in priority order, written by the only people qualified to write it.
Then automate the parts you found yourself repeating. That is a very different list from the one you would have guessed.
The empty state is the onboarding
The single highest-return screen in a young product is the one a user sees before they have created anything, and it is usually the most neglected, because the person who built it has never once seen it with fresh eyes.
A bad empty state is an empty table with the word "No items" in grey. A good one does three things:
- Says what this screen is for, in the user's words rather than your feature name.
- Shows what it looks like full, with a realistic example rather than a stock illustration. Half the confusion in a new product is not knowing what the finished state is supposed to be.
- Offers exactly one button, doing the most common thing.
An honest test: open your product in a private window, sign up as a stranger, and stop. Do not click anything for ten seconds. If you cannot tell what you are supposed to do next, neither can they, and they have less motivation than you do.
Sample data is the underrated version of this. Letting someone see a populated, working example before they have made anything removes the blank-page problem entirely, and it is usually a day of work.
One first action, not a checklist
Setup checklists are popular because they are easy to build and they look like progress. They also spread attention across five tasks when your entire goal is to get one of them done.
Pick the single action that leads to your activation sentence and make everything else secondary or invisible. Every additional decision on that path costs you people, and at your volume you cannot afford to lose them to a settings screen they did not need yet.
Practical ways to shorten the path:
- Default everything you can default. A choice you make for them is faster than a choice they have to understand.
- Move anything not needed for the first result out of the way. Team settings, billing details, integrations, profile photos: none of these produce value on day one.
- Let them see a result before asking for anything expensive. Email verification in the middle of the first action is the classic place people fall out.
What to cut
The things founders build first and should usually build last:
| Tempting | Why it does not work yet |
|---|---|
| A guided tour with tooltips | Usually compensation for a confusing first screen. Fix the screen and the tour becomes unnecessary. |
| A welcome video | Almost nobody watches it, and it goes stale the first time you change the interface. |
| A multi-step setup wizard | Front-loads work before any value is delivered. People abandon halfway and never see the point of the product. |
| A knowledge base | Ten users can email you. Write the article after the third person asks the same question. |
None of these are wrong forever. They are all things that make sense when you have enough users that answering individually stops scaling, and that is a good problem you do not have yet.
The questions worth asking on the way in
Every question in a signup flow costs you some completion, so the bar is that the answer has to change something. Two usually clear it.
What are you hoping to do with this? Free text, one line, skippable. It tells you which of your use cases people actually arrive with, which is frequently not the one your homepage leads with. It is also the fastest way to spot a segment you did not know you had.
What are you using today? The same question that does the work in user interviews, and it works here too. It tells you who you are really competing with and separates people with the problem from people browsing.
The reason to collect these at signup rather than in a survey later is that this is the one moment you have their attention guaranteed. Store the answers next to the account so they are still there in three months when you are deciding what to build, and so you can email a segment rather than the whole list. That is the same mechanic as segmenting a waitlist by survey answers, moved one stage later in the funnel.
Measuring it without a data team
You do not need funnel software. You need one number, checked weekly: of the people who signed up this week, how many reached your activation sentence?
At small volumes a database query beats a dashboard, and the honest version of the analysis is looking at the individual rows. Ten people who signed up and did nothing is not a statistic, it is ten email addresses. Write to them and ask what stopped them. The reply rate is low and the replies are worth more than any chart.
Two traps at this size. Do not average across weeks that had different traffic sources, since a launch spike and a search visitor behave nothing alike, which is the point of knowing which channel brought your signups. And do not chase a percentage while the absolute number is tiny. Going from two to four out of ten is not a fifty percent improvement, it is two more people.
Frequently asked questions
What is a good activation rate?
Any number you read is from a different product with different traffic and a different definition, so it tells you nothing. Measure your own, change one thing, and see whether it moves. Your last month is the only benchmark that controls for everything that matters.
Should I force people through setup before they see the product?
Generally no. Every step before the first result is a place to lose somebody who has not yet been given a reason to persist. Let them see something working, then ask.
Do onboarding emails help?
Yes, and fewer than you think. One email that arrives when somebody has signed up and not done the main action, asking plainly whether they got stuck, outperforms a five-part sequence. It reads as a person rather than a funnel, and at this size it is a person.
My users activate but do not come back. Same problem?
No, and it is worth separating them. If they never activate, the first five minutes are broken. If they activate and vanish, the product worked and was not worth returning to, which is a harder and more important finding. Do not fix onboarding when the real answer is that the value did not repeat.
When should I build real onboarding tooling?
When you can no longer personally email everyone who signs up in a week. That threshold is a genuinely good milestone, and until you hit it, the manual version is both cheaper and more informative.
The uncomfortable part of onboarding at this stage is that the work is unglamorous: write the empty state properly, remove three decisions from the first screen, and email eleven people to ask what confused them. None of it looks like building a product. It is reliably the difference between the signups you worked for turning into users and quietly evaporating.
Lighthouse collects onboarding answers through its API and keeps them next to the account, so the reason somebody signed up is still there months later and you can email one segment instead of everybody. From an indie dev, for indie devs and makers.