Finding your first hundred users

When a product is new, a signup count leaves a lot unanswered. Who arrived because they needed it? Who was being supportive? Who opened it once and never found a reason to return?

That's why I care about conversations early on. With a small enough group, I can connect what someone says they need to what they actually do in the product.

A hundred users isn't a meaningful boundary on its own. A tool for a handful of specialist teams and a free consumer app will have very different evidence at that point.

Contact people with a reason to care

Direct outreach is useful when you can explain why you're contacting that particular person. A relevant complaint, an existing workflow, or a question they've asked gives you a starting point. A job title scraped from a directory usually doesn't.

The message can be short: mention the problem, explain what you're building, and ask whether they'd be willing to try it or talk about how they handle it today. Be clear about the ask. Don't dress a sales pitch up as neutral research.

Some people won't answer. That doesn't tell you much by itself. The message could be wrong, the timing could be bad, or the problem might not matter to them. I wouldn't treat silence as proof of either demand or its absence.

Search, communities, and an existing audience can also bring early users. Outreach is one way to learn quickly, not a required initiation for every founder.

Watch the first useful task

A signup is a convenient event to measure, but the useful event is specific to the product.

For a reporting tool, it might be producing a report someone can send to a colleague. For a scheduling tool, it might be completing a real booking. Decide what that event is before congratulating yourself on registrations.

If possible, watch someone reach it without coaching. Note where they pause, what they expect a control to do, and whether they recognize the result as useful. Explaining every step can hide the very problems you need to find.

I also want their description of the product. If it differs from mine, I need to understand why. Their wording can improve the site copy, provided it accurately describes what the product does. Quotes still need permission and attribution where appropriate.

Keep a small record of what you're learning

At this stage, a simple table is enough: how someone found the product, the job they wanted done, whether they completed it, and what happened next.

Look for patterns without pretending a small sample is conclusive. Several people hitting the same import error gives you a clear fix. Several people requesting different features may mean you're reaching different audiences.

When someone leaves, a brief, optional question is usually better than demanding a cancellation interview. Make it easy to cancel whether they answer or not.

Turn a promising source into a repeatable one

Once people are getting value, the next question is whether you can find more people with the same need.

Choose a channel based on how those customers look for help. Search makes sense when they already search for the problem. A partnership may fit a product bought through advisers. A niche community can help when participation is welcome and you have something useful to contribute.

Give the experiment a budget, a review date, and an outcome beyond traffic. Keep the definition small enough to evaluate: qualified conversations, completed first tasks, or customers who are still using the product later.

As numbers grow, automate the repetitive parts you understand. Keep a way to talk to customers directly. A tidy acquisition report can still conceal a product people aren't returning to.