How to Get Your First 100 Users Before You Finish the Product

When I first started talking about Mangos, I described it as a way to save time by automating social media engagement.

I thought the automation was the value. Then people started telling me something more interesting. They wanted AI to help them, but they did not want it to take complete control. They wanted to see what it was doing. They wanted to review the work. They wanted to decide what should happen next.

That feedback changed how I positioned Mangos. Automation is still available, but the product is human in the loop first. The promise is not that Mangos will take your work away. The promise is that it will improve the way you do the work while keeping you in control.

I learned this before I had every part of the product figured out.

That is why I think the journey to your first 100 users starts before you finish building.

Decide what you mean by a user

Before trying to get your first 100 users, decide what you are counting.

A visitor is not a user. A person on a waitlist is not yet a user. Even a registration can be misleading if the person never reaches the main value of the product.

For an early product, I would count someone as a user when the right person completes the important workflow and has a reason to return. Your definition might be different, but it should describe meaningful use rather than a large number on a dashboard.

This matters because every step before that point is creating evidence. A community reply shows that the problem created a reaction. A waitlist registration shows interest. A prototype session shows willingness to spend time. Repeated use shows that the product may be becoming useful.

Do not treat all of those signals as if they mean the same thing.

Find potential users before you build the whole product

Many founders build in silence because they want the first version to look complete. I understand the instinct. It is more comfortable to show people something polished than to explain an idea that is still changing.

But silence has a cost. You can spend weeks building the wrong promise perfectly.

Before you build the full product, go to the places where people already discuss the problem. That might be a subreddit, a founder community, Indie Hackers, LinkedIn, X, a focused Discord group, or a conversation with people in your network. Do not begin by pretending you have all the answers. Explain what you are trying to solve and ask people how they handle it today.

The best channel is not necessarily the one with the largest audience. It is the place where your specific customer already describes the problem. If you are building for developers, that place will look different from the community for new parents or independent designers.

You are not trying to manufacture excitement. You are trying to learn how the market responds when you describe the problem in your own words.

What do people question? What makes them uncomfortable? Which part do they immediately understand? What do they keep asking for?

Those reactions are part of building the product.

Ask for feedback on a landing page or prototype

A broad question such as, “Would you use this?” will usually produce broad answers.

Give people something they can react to instead. It can be a landing page. It can be a simple prototype deployed on Vercel. It can be a screenshot of one workflow. It does not need to be a complete application.

The purpose is to make the promise visible.

If somebody reads the landing page and misunderstands the product, that is useful. If they understand it but do not care, that is also useful. If they ask when they can try it, you have learned something different.

Early feedback should not only create a list of features. It should change the way you explain the product.

That was the important part of the Mangos feedback for me. People did not simply ask for another setting. They showed me that control needed to be part of the main story.

Use your landing page to validate the message

A landing page is not a small website you create after the product is ready. At this stage, it is a test of your understanding.

Can you describe the problem in a sentence your customer recognizes? Can you explain the result without showing ten features? Does the page answer the concern you heard in the community?

Change the page as you learn.

If people worry that AI will post without their approval, explain the review process. If they care more about saving research time than generating content, lead with that. If your headline sounds impressive but nobody knows what it means, replace it with the words people actually use.

The goal is not to win an argument about your original idea. The goal is to make the idea clearer and more useful.

Build a waitlist, but treat it as a signal

Once the promise is clear enough, give people a way to register their interest.

This can be a simple waitlist. You do not need a complicated launch system. A landing page, a short explanation, and a registration form are enough to begin.

But a waitlist is not the same as 100 active users.

It is evidence that some people care enough to take a small next step. That is valuable, but it is only one signal. The stronger signal comes when those people answer your questions, try the prototype, return to the product, and eventually depend on it for something important.

I would rather have 20 people who explain their problem clearly and want to try the product than 1,000 email addresses from people who barely remember joining.

The number matters less than the strength of the interest behind it.

Turn the waitlist into your first real users

When the prototype is useful enough to test, do not send a link to the entire waitlist and disappear.

Invite a small group personally. Help them begin. Watch whether they reach the result you promised. Ask what they expected to happen, where they became confused, and what would give them a reason to return.

Then invite the next group with a better product and a clearer message.

This is how early interest becomes early usage. It is manual, but the first 100 users are supposed to teach you things that will eventually make growth less manual.

The path to 100 users is not one large launch. It is a series of small loops.

First, describe the problem in a community. Then listen to the response. Change the landing page. Invite interested people to a waitlist. Show them a prototype. Watch where they get value and where they hesitate. Then go back and improve the message and the product.

Each loop should make the next conversation better. You learn which people care most, which words earn their attention, and which part of the product creates a reason to return.

This is slower than posting a launch link everywhere on the same day. It is also more useful. You are not only collecting users. You are learning why they become users.

This is the same learning loop I described in why product readiness and go to market readiness are different.

Find users in communities without spamming

There is one important difference between creating noise and creating spam.

If you enter a community only to drop a link, people can feel it. The best conversations begin with respect for the people who are already there. Read how they discuss the problem. Answer questions when you can. Share what you are learning. Be honest that you are building something and that you want feedback.

You do not need to hide your product. You only need to make the conversation useful even for someone who never joins your waitlist.

That approach will not give you a hundred users overnight. It can give you something better: the first group of people who understand why you are building the product and are willing to help you make it better.

A simple plan for finding your first 100 users

If I reduced the process to one sequence, it would look like this:

1. Define the specific person and problem.
2. Find two communities where those people already discuss it.
3. Share the problem and ask for feedback on something concrete.
4. Rewrite the landing page using what you learn.
5. Invite interested people to a waitlist.
6. Bring small groups into the prototype personally.
7. Measure meaningful use, not only registrations.
8. Repeat the loop until the message and product consistently bring the right people back.

There is no promise that every waitlist registration will become a user. The purpose of the sequence is to learn at every step instead of betting everything on launch day.

Questions founders ask about their first users

Your first users begin with listening

When I changed the positioning of Mangos, I was not responding to a dashboard. I was responding to what people told me they wanted from AI.

They wanted help, but they also wanted control.

That lesson changed the website and the product story. It also reminded me that distribution is not work that begins after building. It is one of the ways you decide what to build.

So before you spend another month finishing the product, put the promise in front of people. Give them something concrete to react to. Listen carefully enough to change your mind. Then build the next version with them, not only for them. That is where the work of getting your first 100 users really begins.

What could you show a potential user this week, before the product feels finished?

Find the conversations that can shape your product

Mangos helps founders find and research people already discussing the problems they solve across X and Reddit, with every message kept under human review.

Try the live demo