Your startup waitlist is not traction. Convert it in cohorts

A waitlist is a list of people who once traded an email address for a future possibility. It is not a list of users.

The distinction appears on launch day. The founder emails 2,000 people. Forty open the product. Eight begin. Two finish the important job. Nobody returns next week.

The tempting conclusion is that the launch failed. The useful conclusion is that four different conversions were hidden inside one large number.

A waitlist measures permission to ask again. Traction begins when people do the work.

Do not burn the whole list to discover that your onboarding is unclear. Convert it in small cohorts, watch what happens, and earn the right to invite the next group.

First, learn what the list contains

Waitlists mix intentions that should not be treated alike.

One person has the problem today. Another liked the idea six months ago. A third wanted to see the launch. A fourth joined for a referral reward. A fifth is a competitor. A sixth no longer remembers your name.

Record what you know about each signup:

• the date and source;
• the page and promise they saw;
• their stated role or use case;
• the problem or urgency they described;
• whether they replied, referred someone, or took another action;
• whether you have permission to send the message you intend to send.

Do not invent a lead score with twenty weak inputs. Begin with three groups:

1. Now: a specific person with the problem, authority, and a live use case.
2. Later: a plausible user without a current task or timing signal.
3. Unknown: an address with little evidence behind it.

Invite the “Now” group first. The purpose is not to reward queue position. It is to learn from the people most able to test the product's promise.

Reconfirm the problem before announcing the product

The waitlist may have formed around an older promise. Your product may have narrowed, changed audience, or solved a different part of the job.

Send a short plain-text message to a small set of likely users. Remind them what they joined for. State what exists now. Ask whether they still face the problem and have a real case they could try.

For example:

You joined because checking a site before launch took too much manual work. We now have a version that reviews a public URL and returns a private report. Are you launching anything in the next two weeks? If so, reply with the date and I will help you run the first check.

This asks for evidence, not applause. A reply with a date and project is stronger than an open. A booked session is stronger than a reply. A completed job is stronger than a booking.

Do not lead with “We are thrilled to announce.” The recipient needs to recognize the old problem, the current product, and the next useful action before they need to share your excitement.

Invite a cohort small enough to observe

Choose the first cohort from your support capacity.

If you can watch and help five users this week, invite five to ten strong candidates, not five hundred. If the product handles sensitive data, money, publication, or irreversible actions, begin smaller.

A practical sequence is:

• Cohort one: people you can contact directly and observe live.
• Cohort two: similar users who can complete the job with light help.
• Cohort three: qualified users who receive ordinary onboarding.
• Broader release: the next segment, only after the main path holds.

The number is not sacred. The constraint is attention. You should be able to read every reply, inspect every failed run, and contact anyone who gets stuck.

Paul Graham's Do Things That Don't Scale argues that a launch only needs to produce an initial core of users, and that later progress depends more on how happy those users are than on launch-day volume. A waitlist is useful when it helps you find that core. It becomes harmful when its size excuses you from knowing them.

Define activation before sending an invite

“Signed up” is rarely the result the customer came for.

Write one sentence describing the earliest completed job that demonstrates value. It should be observable in the product or confirmed by the user.

Examples:

• A founder scans a real public site and reads the evidence behind one launch issue.
• A recruiter imports a live role and sends one approved candidate brief.
• A finance lead connects an account and reconciles one real transaction.
• A team creates a shared project and a second member completes an assigned action.

Avoid activation definitions such as “visited dashboard,” “created account,” or “used three features.” Those are movements. They may be necessary, but they do not prove the job was done.

Then define the next behavior that would show continued value. For a launch tool, that might be returning after fixes to run another check. For a monthly workflow, it may be completing the next cycle. Match the interval to the real job instead of forcing every product into daily activity.

The traction guide separates attention, activation, retention, payment, and referral. Use that sequence here. A large waitlist can create attention. It cannot skip the rest.

Make the invitation complete

The invite should answer five questions:

1. Why am I receiving this?
2. What can I do now?
3. Why might it matter to me?
4. What must I prepare or connect?
5. How do I get help or decline?

Use one primary action. Deep-link to the first useful step when it is safe. If access is limited, say how long the invitation remains valid and what happens afterward. Do not create false urgency or pretend that a capacity limit exists when it does not.

Send the message from an identity the recipient can recognize and reply to. Test authentication, delivery, links, redirects, mobile rendering, unsubscribe behavior, and expired invitations before using the list. The transactional email launch guide covers the delivery and recovery path in detail.

Do not attach an image of the product where a sentence will do. The invitation is not a launch poster. It is the start of a task.

Meet the first users inside the work

Offer a short setup session. Import their first data. Configure the first project. Run the workflow beside them. Ask them to share their screen while you remain quiet.

This is not a permanent service promise. It is the cheapest way to learn where the product asks for knowledge it has not earned.

Record:

• the first moment of hesitation;
• the first question;
• anything you had to explain outside the interface;
• any data or permission the user would not provide;
• where they expected a different result;
• whether the result changed a real decision;
• what they did after the session without being asked.

YC's growth discussion with Gustaf Alströmer makes the early-stage point directly: growth requires intentional work, founders should do it themselves, and direct user channels can be more useful than press. The waitlist gives you a direct channel. Use it for learning, not broadcast alone.

Measure the whole conversion chain

Do not report “waitlist conversion” as one percentage. Measure the stages separately:

| Stage | Question | | --- | --- | | Delivered | Did the invitation reach a working address? | | Opened or visited | Did the person notice and recognize it? | | Started | Did they begin the intended job? | | Activated | Did they complete the first useful result? | | Returned | Did they come back at the job's natural interval? | | Committed | Did they pay, invite a colleague, bring real data, or schedule the next use? |

Use counts as well as percentages. “Two of eight activated” is easier to reason about than “25% activation” when the cohort is small.

Segment by signup source, promise, age, role, and use case. A recent list from direct customer conversations should not be averaged with an old giveaway campaign. The blend conceals the answer.

Do not compare cohorts until the definition and journey are stable enough to make the comparison fair. If cohort one received founder setup and cohort three did not, the difference is part of the experiment.

Diagnose the first serious break

Each pattern points to a different problem.

Few invitations are delivered

The list may be old, mistyped, or poorly collected. Stop sending broadly. Protect sender reputation, remove invalid addresses, and confirm that recipients asked for this kind of contact.

Messages arrive but few people visit

The sender or subject may be unfamiliar. The old promise may no longer matter. The audience may have joined for curiosity rather than need. Ask a few non-clickers why before rewriting ten subject lines.

People visit but do not start

Check whether the page repeats the promise, shows the product is available, and gives one obvious action. Test invite expiry, login, mobile layout, pricing surprises, and trust signals. The no-signups diagnosis helps isolate audience, clarity, trust, and form problems.

People start but do not activate

Watch the workflow. The setup may demand too much, the blank state may be empty, or the result may take too long. Fix the earliest consequential obstruction using the first-minute onboarding guide.

People activate but do not return

Ask whether the job repeats and whether the result was strong enough to change behavior. Do not add reminder email to a product that delivered no reason to return. Diagnose the value and return loop first.

Use replies to change the next cohort

After each group, write a one-page decision note:

• Who was invited, and why?
• Which promise did they receive?
• How many reached each stage?
• Where did the first serious break occur?
• What did users do or refuse to do?
• What will change before the next cohort?
• What must stay unchanged so the comparison remains useful?
• What evidence would justify a wider release?

Choose one material change. If you alter the audience, invitation, pricing, onboarding, and product together, a better result teaches little.

Widen when the core path works often enough that another cohort will test a new question rather than repeat a known failure. Pause when you cannot support current users, a consequential path is unsafe, or the product does not deliver the promised result.

Do not confuse list maintenance with customer work

Referral points, queue positions, progress updates, and launch teasers can keep people interested. They can also create a small entertainment product around a product nobody has used.

A skeptical reply in a Hacker News discussion about waitlists described them as a sign that a maker may care more about hype than the product. One comment is not market research, but the suspicion is worth understanding. Every additional waitlist mechanic should answer a customer question or help a qualified user reach the product. If it merely increases the displayed count, leave it out.

Do not hide indefinitely behind invite-only status. A closed launch is valuable when exposure is limited by risk, support, supply, or a specific learning goal. It is not valuable as permanent theatre. The closed beta guide helps set an explicit reason and exit condition.

A seven-day waitlist conversion plan

Day one: clean the promise

Write the current user, problem, first result, and activation event. Compare them with the page people originally joined.

Day two: choose ten people

Select users with a live problem and recognizable source. Write down why each belongs.

Day three: test the path

Use a fresh address and device. Test delivery, invite acceptance, login, setup, the core job, failure, help, and return.

Day four: send and reply

Send a plain invitation from a real person. Read every response. Book setup sessions while intent is current.

Day five: observe

Watch users attempt real work. Fix only blockers that prevent the promised result or cause unacceptable risk.

Day six: follow up on the result

Ask whether the user completed the job, what changed, and what they will do next. Do not ask for generic feedback.

Day seven: decide

Review the funnel by count. Invite the next similar cohort, change one part of the system, narrow the audience, or stop and repair the product.

The list has done its job when you no longer admire it

A waitlist is temporary infrastructure. Its purpose is to connect a known person with a product that can now help them.

The useful questions are not “How many people joined?” or “How large should the launch be?” Ask:

• Which people still have the problem?
• Which of them completed the job?
• Who returned without pressure?
• What broke before value?
• What did we learn that changes the next release?

Invite ten. Help them. Count the result. Then earn the next ten.