How to Get Your First 10 Users Before You Build Anything

If you want your first users before your startup launches, the answer is not a marketing campaign. It’s a set of conversations that needs to happen before you build anything.

Most founders treat finding users as a post‑launch problem. You build the thing, you find the people, you iterate from there. The problem with that sequence is that by the time you’re looking for users, you’ve already made every decision they would have changed: the feature list, the pricing, the architecture, the onboarding flow, and the list goes on. All of it gets decided in a vacuum, then tested on strangers who didn’t ask for it.

There’s a different way.

It requires more patience and less comfort, but it produces something most launches don’t: a small group of people who were waiting for exactly what you built, because you built it around what they told you.

At Coura, we recommend a simple “signal‑before‑scope” approach, where you get real user signals before deciding what to scope, architect, or build. It’s the lens we encourage founders to use before any architecture work, scoping, or development spend. 

Here’s how we think about it.

Why Customer Discovery Has to Come Before Code

We often talk about how the most expensive mistakes in product development usually happen before the first line of code. In early‑stage work, founders who skip customer discovery tend to build features that technically work and commercially don’t. The kicker is they’re right about the problem, but they’re wrong about the solution.

Real users don’t behave like imagined users. 

They have workarounds you didn’t know about, preferences that contradict what they’d tell you in a survey, and constraints that make your most elegant feature irrelevant. You can discover all of this in a 30‑minute user interview, or you can discover it six months into a build when the cost of changing course is significant.

Your choice!

The conversation isn’t a nice‑to‑have. It’s the cheapest research you’ll ever do.

This is the core premise of a signal‑before‑scope approach: you need a signal before you scope. Not just a green light to build, a SIGNAL. The specific language, behaviors, and costs that tell you exactly whose problem you’re solving and what it would actually take to solve it.

How to Find First Users Before Launch

The best way to find your first users before launch is to identify people who currently have the problem (not people who might someday have it) and to have a structured conversation that surfaces real costs and consequences before you ask for anything.

This isn’t the same as running a survey or asking your network if they’d use your idea. Those approaches just measure interest. What you need is evidence of urgency: people who have the problem badly enough that they’ve already tried to solve it.

Four sources consistently produce high‑quality early adopters:

1. Your professional network

The colleagues, clients, and peers who work in the same space as your target user are already in your contact list. They understand the problem from the inside. Start there, and not with a pitch, but with a question about their experience.

2. Communities where the problem lives

Every significant problem has a community around it: a Slack group, a LinkedIn community, a subreddit, a Discord server. People in those spaces have already opted in to talking about the problem. Spend a week reading before you participate. Earn the right to ask.

3. People who’ve tried to solve it manually

They hired a consultant. They built a workaround in Excel. They have a whole process for managing the problem today. These are often your most motivated early adopters because they’ve already proven, sometimes with their own time and money, that the problem is worth solving.

4. Former colleagues in the role

If your product is for a specific kind of professional, you probably know people who’ve held that role. They’re the fastest path to honest feedback and often the warmest path to first users. Talk to them. 

In our experience, founders who start with the “manual solvers” get an especially sharp early signal. These are people who already have a budget line for dealing with the problem, even if it’s being spent on a workaround. Willingness to pay is easier to establish because they’re already paying for something.

What to Ask in Early User Interviews

We recommend that early user interviews focus on three core questions, in sequence. Most comprehensive user interview guides over‑engineer this. Three questions, asked carefully and followed up with silence, will give you most of what you need.

Question 1: The Cost Question

“Walk me through the last time this problem actually cost you something.”

This is the most important question in early customer discovery. “Would you use this?” is too easy to answer kindly. “How often does this come up?” just touches on frequency, and frequency without consequence is not a signal. 

Ask about cost: time, money, opportunity, reputation. The specificity of the answer tells you how painful the problem actually is.

Then stop talking. Let the story complete. Founders who get the most useful signal let the person finish before responding or pitching.

Question 2: The Workaround Question

“What have you already tried?”

This tells you what’s failed, what’s partially working, and what they’re currently paying, in money or time, to manage the problem. The answers here map directly to your Jobs to Be Done aka your running list of the functional job the product has to perform, the emotional job it has to fulfill, and the social job it has to support. 

Every workaround they describe is a feature requirement in disguise.

Question 3: The Requirement Question

“What would a solution have to do to be worth paying for?”

This is the question that separates the problem from the requirement. The answer isn’t a feature wishlist, it’s a threshold. What’s the minimum the product has to do for this person to justify the cost of switching? The answers here become the foundation of your MVP scope.

The language people reach for when answering these three questions is the language your product should speak. It’s the copy that converts your first 100 users, so we recommend you write it down verbatim.

How Many Interviews Before You Build?

Take this with a grain of salt. 

Five to seven honest conversations with people who have the problem are usually enough to establish the patterns you need to build with more confidence. This is not a statistically significant sample size for research purposes, but often functions as a threshold for directional signal.

After five to seven conversations, you should start noticing patterns emerging independently: the same phrases in different mouths, the same workarounds described by people who don’t know each other, the same point in the workflow where things break. That convergence is finally more than an anecdote; it’s the beginning of problem–solution fit evidence.

If you’re at seven conversations and patterns haven’t emerged, you probably have one of two problems: either you’re talking to the wrong people, or the problem isn’t consistently painful enough to drive purchase. 

Both are worth knowing before you spend on a build.

Turning Early Conversations Into First Users

Once patterns have emerged from your conversations, go back to the people who produced them with a direct invitation:

“Based on what you told me, here’s what I’m building. You’d be among the first to see it. Do you want in?”

That’s the close: a direct invitation, grounded in something they already told you was real.

The people who say yes are your first customers. They’re people who have the problem, understand what you’re solving, and are expecting to see it because they helped shape what it is.

Founders who follow a process like this often report a surprising outcome: their first users don’t need to be “sold.” The product already fits because it was built around their description of the problem.

What if you can’t find anyone willing to talk?

If you genuinely cannot find five people willing to have this conversation, that’s information. It doesn’t necessarily mean the problem doesn’t exist. It might mean your network doesn’t overlap with the people who have it, in which case the communities approach becomes more important. Or it might mean the problem isn’t painful enough to motivate people to give you 20 minutes.

That second possibility is worth sitting with before you build. A problem that’s real but not urgent enough to discuss is a problem that may not be urgent enough to pay to solve.

The goal isn’t to reach ten interviews and check the box. The goal is to accumulate enough honest signals that the first version of what you build is aimed at something real, owned by someone specific, who has already told you what it would cost them not to solve it.

What comes after validation conversations?

A signal‑before‑scope approach produces two things: clarity on who has the problem and what it costs them, and a draft of the requirements any solution would need to meet.

What it doesn’t produce on its own is an architecture, a technical scope, a realistic timeline, or a cost estimate. That’s the next phase of work, and it’s where many founders make a second major mistake: going from conversations directly into a development engagement without the structural layer in between.

We recommend that founders run a short product architecture and scoping phase before committing to a build. That phase should cover technical feasibility, feature prioritization, architecture decisions, realistic timelines, and risk identification. Some founders do this with their development partner; others do it independently or with a separate advisor. Either way, the goal is the same: a clear, realistic plan you can execute against.

If you’re at the conversation stage and wondering what the build actually looks like, that’s the path: signal, then scope, then build.

What happens when founders skip user research?

Founders who skip this work often build everything, and they launch to silence, followed by spending the next six months trying to figure out why no one is using something that technically works.

The problem usually isn’t the engineering quality. It’s that the product was built for a user who was imagined rather than known. The features are right for someone, just not the specific person with the urgent, costly, unsolved version of the problem that would justify switching to something new.

Five conversations before you build is not a significant investment. Founders who do this consistently tend to outperform those who don’t on the metrics that matter at the earliest stage: time to first paying customer, retention after the first 30 days, and the quality of feedback they can act on.

Get the conversations first. The build follows from that.

Frequently Asked Questions

How many users do I need to talk to before I start building my startup?

At Coura, we recommend a minimum of five to seven customer discovery conversations with people who currently have the problem, not hypothetical users. Five is often enough to start seeing pattern convergence; if patterns haven’t emerged by seven conversations, that’s a signal worth investigating before you build.

What’s the difference between user interviews and a landing page test?

A landing page test measures whether your headline was interesting enough to capture an email address. A user interview surfaces the cost and consequence of the problem, the language your target user reaches for, and the threshold they’d need a solution to meet before paying for it. These are different kinds of signal, and only one of them tells you what to build.

What questions should I ask in early startup user interviews?

We suggest focusing on three questions:

1. “Walk me through the last time this problem actually cost you something.”
2. “What have you already tried?”
3. “What would a solution have to do to be worth paying for?”

Asked in sequence, with silence and follow‑ups after each, these three usually produce most of the signal you need to build with confidence.

How do I find people to interview for my startup idea?

Start with four sources: your professional network, communities where the problem is already being discussed, people who’ve already tried to solve the problem manually (workarounds, consultants, spreadsheets), and former colleagues who held the role your product is designed for. The “manual solvers” tend to produce the highest‑quality signal because they’ve already proven the problem is worth solving.

What comes after customer discovery conversations?

Once you have five to seven conversations showing pattern convergence, the next step we recommend is a structured architecture and scoping phase. That phase should produce a clear technical scope, feature prioritization, architecture decisions, and realistic cost and timeline estimates before any development begins.