How to work toward your first 100 users

Define who counts as a user

Choose one event that shows someone reached the product’s core task. For a recipe app, that might be saving a recipe and creating a shopping list from it. For an approval tool, it could be sending a review link and receiving a decision. Keep registrations in the report, but do not silently count every address as an active user.

Record the definition, the time window and how you will recognize the event. Exclude your own testing accounts. If the product requires two people to complete the workflow, track both roles so an incomplete invitation does not look like a completed task. Your first useful deliverable is this definition, not a growth chart.

Find a group with the same immediate problem

Make a short list of places where people already ask about the task. Read enough of the discussion to understand the constraints: solo use or team use, phone or desktop, occasional or daily. A forum full of broad startup announcements may give you less relevant feedback than a small conversation about the exact problem.

Approach people through appropriate, permitted channels. Answer a question fully before mentioning your product when it is relevant. For existing contacts, explain why you thought of them and give them room to decline. Do not scrape a list and mistake mass messages for a community strategy.

Use an invitation someone can evaluate

A useful invitation says who the tool is for, what task it handles and what you want the person to try. Example: “I’m building a way for freelance designers to collect a decision on one draft. Would you try sending one review link and tell me where it gets confusing?” This is a sample invitation, not a message sent to anyone.

Avoid a general request to “check out my startup”. It makes the recipient decide what to inspect and how to help. If there is an access condition, limitation or setup step, explain it before asking for their time. Keep the feedback request smaller than a complete product review.

Run a batch, then repair one problem

Invite a manageable group, observe the task and note the first point where each person hesitates. Small batches make it possible to distinguish a confusing label from a product that does not solve the problem. Do not change the page, onboarding and feature simultaneously if you want to know which correction helped.

Turn repeated questions into a shareable demo

If several people ask how a feature works, record that feature once. For the recipe example, show one saved recipe becoming a grocery list. Use a realistic demo account and let the resulting list remain on screen long enough to read. A demonstration can travel further than another paragraph describing the feature.

A short ugcpeople reaction can be one opening to test, followed by your own recording. Keep a screen-first version too. The purpose is to make the explanation easy to follow, not to imply that the person in the clip is a customer. Link to the relevant feature or onboarding path rather than sending every viewer to an unrelated homepage.

Read a small batch without turning it into a forecast

Illustrative example: you invite 20 relevant people, eight visit, four register and two complete the chosen task. Those are invented worksheet values, not ugcpeople results. They show why “we got four users” can hide the real question: what happened between registration and useful action?

Do not multiply that batch into a prediction for a larger audience. Record the circumstances and speak to people who stopped. Increase distribution after the experience is understandable enough to repeat. The number 100 is a planning milestone; there is no universal timetable for reaching it.

Questions & answers