100 Users ≠ 100 Customers. They're Your Product Team.

They're going to tell you what's broken.

What's confusing.

What's missing.

And sometimes, what's completely unnecessary.

Your first 100 users aren't there to make your dashboard look impressive.

They're there to help you build something people actually want.

I used to think users were the goal

This is how I thought about building products:

Build → launch → get users → get more users → celebrate.

Simple.

So when someone signed up for one of my products, I was excited.

One user.

Then five.

Then ten.

And immediately, my brain went:

"How do I get to 1,000?"

Classic maker behavior.

Instead of talking to the five people who had already trusted me enough to try the product, I started thinking about traffic.

SEO.

Social media.

Launches.

Content.

More eyeballs.

More users.

But there was a tiny problem.

I didn't really understand the users I already had.

Then someone broke my illusion

A user told me they couldn't figure out what to do after signing up.

I opened the product.

Looked at the screen.

And thought:

"How?"

The button was right there.

The copy was right there.

The whole flow seemed obvious.

To me.

Then it hit me.

Of course it was obvious to me. I built it.

I knew where everything was.

I knew what every button did.

I knew why the product existed.

The user knew none of that.

They just landed on a website and thought:

"Okay… what now?"

That was uncomfortable.

But useful.

Because the product in my head and the product in their hands were two different things.

Your users don't see your intentions

They see your product.

You might have spent three days designing the perfect onboarding flow.

They don't care.

They either understand it or they don't.

You might have written a beautiful explanation of your feature.

They either get it or they don't.

You might think your pricing is obvious.

They either buy or they don't.

That's the brutal beauty of having real users.

They remove the story you're telling yourself.

They show you what actually happened.

And that's exactly what you need in the beginning.

Your first 10 users are different

Your first 10 users aren't really customers yet.

They're closer to design partners.

They're helping you discover what the product should be.

So talk to them.

Not with a giant survey.

Not with 25 questions.

Just send a message.

Something like:

"Hey, thanks for trying this. What was the most confusing part?"

Then wait.

And listen.

Don't immediately explain.

Don't say:

"Actually, that button is supposed to…"

Don't defend the product.

That's a trap.

You aren't trying to win an argument.

You're trying to find the gap between what you built and what they experienced.

That gap is where your best product ideas live.

Your next 40 users are about patterns

One person asks for a feature.

Cool.

Write it down.

Don't build it yet.

Then another person asks for the same thing.

Interesting.

Then another.

Now we're paying attention.

This is where you stop asking:

"What does this user want?"

And start asking:

"What problem keeps showing up?"

That's a much better question.

Because users are usually good at describing their pain.

They're not always good at designing your solution.

A user might say:

"Add Slack integration."

But what they really mean might be:

"I need to know when something important happens without opening your app."

Those are very different problems.

Maybe Slack is the answer.

Maybe email is.

Maybe a push notification is.

Maybe your product needs a completely different workflow.

Don't blindly build the request.

Understand the reason behind it.

This is where makers get themselves into trouble

You know the pattern.

User:

"Can you add dark mode?"

You:

"Absolutely."

Two days later…

Dark mode shipped.

Next user:

"Can you add an AI assistant?"

You:

"Absolutely."

Next user:

"Can you add calendar integration?"

"Absolutely."

Next user:

"Can you add a mobile app?"

You:

"…absolutely."

Six months later, you have 47 features.

And somehow the product is harder to use than when you started.

I've been guilty of this.

It's easy to confuse shipping with progress.

Adding things feels productive.

Deleting things feels scary.

But sometimes the best product decision is removing something nobody needs.

Your users should help you make those decisions.

Not dictate them.

Your first 100 users are also telling you who your product is for

This one is easy to miss.

You might launch thinking:

"This is for everyone who wants to be more productive."

Sounds good.

Also means almost nothing.

Then 20 users sign up.

You notice something.

Most of them are developers.

They all use the product in a similar way.

They have the same problem.

They use the same feature.

They even describe the product using similar words.

That's not random.

That's a signal.

Maybe your product isn't for "everyone."

Maybe it's for developers with this specific problem.

That's useful.

Because once you know who cares, finding more people becomes much easier.

You stop shouting at everyone.

You start talking to someone specific.

Don't chase 10,000 visitors yet

This is probably unpopular.

But if you're early, I'd rather have 50 people who really care than 10,000 people who don't.

Because 50 engaged users can teach you something.

They can tell you:

Why they signed up.

What they expected.

What confused them.

What they love.

What they hate.

Why they came back.

Why they almost left.

That's gold.

10,000 random visitors mostly give you a nice graph.

And graphs are fun.

Until you realize you don't know what to do next.

Watch what people do

This is another big one.

People are sometimes terrible at predicting their own behavior.

They'll tell you:

"I love this feature."

Then never use it.

Someone else might say:

"I don't really care about this."

Then use it every single day.

So don't only collect opinions.

Watch behavior.

Ask:

Did they activate?

Did they reach the main value?

Did they come back?

Which feature did they actually use?

Where did they stop?

You don't need a giant analytics stack.

For an early product, a simple spreadsheet can be enough.

User.

What they tried.

Where they got stuck.

What they asked for.

Whether they came back.

That's already useful.

Here's a simple system I like

Create a document called:

User Problems.

Then make five columns.

Problem — What are people struggling with?

Frequency — How many people mentioned it?

Impact — How badly does it affect their experience?

Evidence — What did they actually say or do?

Decision — Build it, test it, investigate it, or ignore it.

Now you're not building based on whoever emailed you last.

You're building based on evidence.

That's a big difference.

And here's the best part

When you fix something, tell them.

Imagine a user tells you:

"I keep forgetting to come back to the app."

You build a reminder.

Then you message:

"Hey, you mentioned this last week. I added it."

That's powerful.

You just showed them that you listened.

Now they're not just another user.

They're part of the story.

And that's how early communities form.

Not through fancy community strategies.

Through small moments where someone realizes:

"The person building this actually cares."

Your first 100 users don't need a perfect product

They need to feel progress.

That's an important distinction.

If you're building a SaaS, don't wait until everything is polished.

Let people see the product evolve.

Fix the onboarding.

Improve the confusing button.

Remove the unnecessary feature.

Make the core workflow faster.

Then tell people what changed.

Your early users get a better product.

You get better feedback.

Everyone wins.

There is another reason this matters

Your first 100 users are giving you something more valuable than revenue.

They're giving you confidence based on reality.

Before launch, you're guessing.

You guess what people want.

You guess what they'll pay for.

You guess which features matter.

You guess who the customer is.

After launch, you get evidence.

Not perfect evidence.

But better evidence.

That's why shipping early matters.

You're not launching because the product is finished.

You're launching because you need to learn.

The mindset shift

Stop thinking:

"I need my first 100 users."

Start thinking:

"I need 100 opportunities to learn."

One user teaches you about onboarding.

Another teaches you about pricing.

Another teaches you about positioning.

Another teaches you about retention.

Another teaches you that the feature you spent two weeks building isn't actually important.

It hurts.

But it's useful pain.

And that's what makes the first 100 so valuable.

What I'd do with my first 100 users

If I were starting a new SaaS tomorrow, I'd keep it ridiculously simple.

With the first 10:

Talk to them personally.

Watch them use the product.

Fix obvious problems immediately.

With the next 40:

Look for repeated problems.

Look for repeated language.

Look for repeated use cases.

With the next 50:

Look at behavior.

Who comes back?

Who gets value?

Who pays?

Who recommends you?

Then ask:

"What do these people have in common?"

That answer might become your positioning.

It might become your landing page.

It might become your acquisition strategy.

It might even become your entire business.

Don't waste your unfair advantage

When you're small, you have something big companies don't.

You can talk to your users.

Personally.

You can reply to an email.

Jump on a call.

Fix something in the afternoon.

Ship it at night.

Then message the person who asked for it.

You can know your first users by name.

That's an unfair advantage.

Use it.

Don't rush to become a company that can't hear its customers.

Stay close while you can.

One thing I keep reminding myself

Your first users aren't there to prove that you're right.

They're there to show you where you're wrong.

That's the job.

So when someone complains, don't immediately think:

"They don't understand my product."

Think:

"What did I fail to make clear?"

When someone asks for a feature, don't think:

"I need to build this."

Think:

"What problem are they actually trying to solve?"

When someone leaves, don't think:

"They weren't my target customer anyway."

Think:

"What can this teach me?"

That's how you turn users into a product team.

The takeaway

Your first 100 users aren't a vanity metric.

They're 100 conversations.

100 experiments.

100 chances to find something you couldn't see from inside your own head.

You don't need them to tell you that your product is great.

You need them to make it better.

Because your first version probably won't be the version that wins.

That's okay.

It shouldn't be.

The goal isn't to be right on day one.

The goal is to get closer every week.

And your first 100 users can help you do exactly that.

Your first 100 users aren't your audience. They're your product team.

Treat them like it.

Talk to them.

Watch them.

Listen carefully.

Then go build.

Builders Challenge

Pick three people who have actually used your product.

Not newsletter subscribers.

Not random followers.

People who actually touched the product.

Send them one message:

"What almost made you stop using this?"

Then don't defend yourself.

Don't explain.

Don't pitch.

Listen.

Write down their answers.

Look for the pattern.

Then spend the next 24 hours fixing one problem that keeps appearing.

Not the coolest problem.

Not the easiest problem.

The one that matters.

Your next feature might already be sitting in someone's inbox.

You just haven't listened closely enough yet.

Build something people want.

Then listen to the people who use it.

Until the next build,

— Abhi

Mind of a Maker

Go build something worth talking about.