How to get your first users after a launch

Before you contact anyone, sort the people you got into three groups:

• Signed up and never did the main thing. They were curious. Some will come back if you help them.
• Did the main thing once. They saw the result. Find out why they didn't return.
• Came back on their own. These are your first users, even if there are only three.

Decide what "did the main thing" means for your product: sent the first invoice, ran the first check, published the first page. Account creation doesn't count.

The people who commented during launch week told you what they think in public. They are the easiest people to contact.

• Reply again to every comment, especially critical ones, and say what you changed because of it.
• On Nukkadly, comments are tagged useful, confusing, pricing or missing, and visitors can mark a product as fitting their use case, something they'd try or something they'd pay for. Go back through the confusing and missing comments first. Each one is a reason somebody didn't become a user.
• Contact anyone who signed up through your own product, using the email they gave you. Keep it short and personal.

A message that works is specific and easy to answer:

Hi Priya, you signed up for Inboxed last week after the launch. I'm the maker. Did you get as far as connecting an inbox? If something got in the way, I'd like to fix it. A one-line reply is plenty.

Ask one question. Don't attach a survey, and don't ask for a review or a vote.

Graham's essay describes the Collison brothers at Stripe: when someone agreed to try the product, they asked for the person's laptop and set them up on the spot. You can do a remote version of this.

• Offer a 15-minute call to set up the first project together.
• Import a small sample of the user's data for them.
• Record a two-minute walkthrough that uses their use case, not a generic demo.
• Reply to questions within hours, not days.

None of this scales, and it isn't meant to. You'll learn more about your onboarding from watching three people use it than from any dashboard.

Look at the users who came back. What do they have in common: a job title, a tool they already use, a size of team, a problem they described in the same words?

Graham gives the example of Ben Silbermann noticing that many early Pinterest users were into design, then recruiting at a conference of design bloggers. The small-SaaS version is to go where that specific group already talks:

• The forums, Slack and Discord groups, subreddits or mailing lists for that role or tool.
• Public posts where people describe the exact problem you solve.
• People who use a tool next to yours, such as the integration your best users connected first.

Answer questions properly before you mention your product. When you do mention it, say it's yours. Most communities remove drive-by links, and Hacker News states plainly that asking friends to upvote or comment is not OK.

Cold messages work when they are about the reader, not about you. Find someone who described the problem in public, then write:

Hi Sam, I saw your post about answering the same support question every day. I built a small tool that groups repeat questions from a shared inbox and drafts answers for you to approve. It's early and free during the beta. Want a link?

Mention what they wrote, describe the product in one line and ask a yes-or-no question. If they say no or don't reply, leave it there.

A launch site doesn't have to be a one-time visit.

• On Nukkadly a product stays in Browse after its week, ranked by votes, feedback and use signals. When you ship a major feature, post it as an update from your product's edit page. It goes on the changelog and can return the product to the current week's board without a duplicate listing.
• Show HN treats small version bumps as not substantive enough to post, but says a major overhaul is probably fine.
• Add a short changelog to your own site, and tell the people who gave feedback when you ship what they asked for.

If the first launch was quiet, start with what to do after a quiet launch.

Keep one note per week with three lines: how many people came back on their own, the most common reason someone stopped, and what you changed. After a month you'll see whether the product is getting easier to adopt.

If the same confusion keeps coming up, the problem may sit before signup, in how you describe the product. The guide to writing a launch tagline and description helps with that, and the questions in SaaS beta testing feedback questions work just as well after launch.

• Launching on yet another site to fix low usage. More visitors won't help if the first visitors didn't stay. Fix the drop-off first, then use our list of product launch websites for the next round.
• Paying for votes, upvote groups or fake reviews. Most boards ban it, and it tells you nothing about demand. Nukkadly's guidelines ban vote buying and coordinated fake accounts, and new accounts vote at a quarter of the normal weight for their first 7 days.
• Posting the same link in every community. People notice, and moderators remember.
• Waiting for word of mouth before you have ten happy users. People who use a product every week tell others about it. People who signed up once don't.

Once a handful of people use the product every week without you prompting them, start testing one channel that can grow: search content about the problem you solve, an integration listing, or a referral prompt for existing users. Pick one, give it a few weeks, and check whether the people it brings behave like your first users.

If you haven't put the product in front of a launch audience yet, submit it to Nukkadly. Review is free, the launch runs a full Monday to Sunday UTC week, and the listing stays in Browse afterwards.