Validation · 11 min read

How to Get Your First SaaS Customers: The 40-Name First-Use Test

How to Get Your First SaaS Customers: The 40-Name First-Use Test Most founders who ask how to get their first SaaS customers do not have a traffic problem first. They have a first-use problem.…

← All articles

How to Get Your First SaaS Customers: The 40-Name First-Use Test

Most founders who ask how to get their first SaaS customers do not have a traffic problem first. They have a first-use problem.

They can make a landing page. They can post on Product Hunt. They can run a few ads, collect a few hundred visits, and watch the dashboard with growing anxiety. What they often cannot answer is simpler: can one specific person get value from this product today?

That question matters more than a launch spike because it changes what you do next. If a person uses the product once, gets the promised result, and can explain that result in plain language, you have learned something real. If they only say, “This is cool,” you have learned much less.

A recent discussion among SaaS founders described an unusually useful early-stage approach. Instead of trying to find an audience, one founder began with a handwritten list of roughly 40 people who already had the problem. They contacted each person with a question rather than a pitch, then did the initial setup with early users by hand. The work was not scalable. That was the point.

This article turns that signal into a practical test you can run before you spend months chasing reach.

The metric that comes before sign-ups

Sign-ups are easy to misread. A person can sign up because they are curious, polite, bored, or saving something for later. A paid plan is a stronger signal, but even payment can be misleading if a user never gets started and asks for a refund.

The early metric to watch is first useful outcome.

For a reporting tool, it might be a team that connects a data source and finds one answer they needed. For a design tool, it might be a designer who produces one usable asset. For a workflow product, it might be an operations manager who completes one task without returning to a spreadsheet.

Your product should make that moment observable. Write one sentence to define it:

A new user has reached first value when they have ______ without help from our team.

If you cannot complete that sentence, your onboarding is probably trying to serve too many people or promising too much at once.

The difference is important. “The user explored the dashboard” is activity. “The user sent their first invoice” is an outcome. “They created a project” is activity. “They invited the client and received approval” is an outcome.

Early validation improves when you stop measuring attention and start measuring completed outcomes.

Where to find the first 40 SaaS customer prospects

The phrase “make a list of 40 people” can sound simple until you open a blank spreadsheet. The answer is not to purchase a generic lead list. A first-customer list should be built from proximity to the problem, not proximity to an email address.

Start with three circles. The first is people you know professionally: former clients, co-workers, peers, suppliers, and people who have watched you work in the relevant domain. The second is visible practitioners: people who post useful questions, job stories, or requests for recommendations in a focused online community. The third is adjacent contacts: one introduction away from somebody who clearly owns the workflow.

For each prospect, add four fields: role, evidence of the problem, likely current workaround, and the most respectful first question. This turns a vague prospecting task into a research list. A prospect who merely matches an industry label is weak. A prospect who recently complained about consolidating reports, chasing approvals, or reconciling an export is strong.

Do not make a different list for every possible customer type. Pick one narrow segment for the test. “Small agencies” is still broad. “Two-to-ten-person design agencies that send weekly performance reports” is much easier to find, question, and serve. A narrow list does not limit the eventual company. It gives the first version a chance to become useful.

A first-message template that does not feel like outreach

Use the evidence you recorded, but do not pretend you know the answer. A good first message has three parts: context, a present-tense question, and permission to ignore it.

Hi Maya — I saw you mentioned preparing campaign reports for several clients. I am trying to understand how small agencies handle that handoff today. Are you still pulling figures from several tools manually, or have you found a system that works? No pitch; a one-line answer would help.

The message is short because it asks for observation, not a meeting. If the person replies with detail, ask one useful follow-up. If they do not, leave them alone. Early customer research should build trust, not burn a future relationship.

The first-customer scorecard

Not every interested person should be given the same amount of founder time. Score prospective first users after a conversation, not before it. A simple 0–2 score across five factors is enough:

Factor 0 1 2
Pain frequency rare occasional weekly or more
Workaround cost trivial inconvenient costly or risky
Decision access no influence can recommend can buy or run a pilot
Urgency someday this quarter active problem now
Learning value unusual case useful case representative target user

Prioritise people scoring eight or more. This is not a scientific market score. It is a way to avoid giving the same attention to a curious commenter and a target customer with an active, expensive problem. A small list becomes powerful when you know why one conversation should happen before another.

Why 40 names are better than 4,000 anonymous visitors

Four thousand visitors feel impressive because the number is large. But visitors are not a group you can learn from unless they become conversations. Forty names are small enough to know and large enough to reveal a pattern.

The list should not be forty random LinkedIn profiles. It should contain people who have one trait in common: you have a defensible reason to believe they experience the job, friction, or workaround your product addresses.

Good candidates include:

  • people you have worked with before;
  • people who have publicly described the problem in a niche community;
  • customers of a service business in the same workflow;
  • friends of existing contacts who have the right role; and
  • people already paying for an awkward workaround.

The last group is especially valuable. If somebody pays a contractor, uses three spreadsheets, or maintains a recurring manual process, the pain has a budget attached to it. You do not need to persuade them that the problem exists. You need to learn what a better solution must do.

This does not mean you should spam forty people. The useful move is to start a focused conversation with a short, honest question. For example:

Are you still preparing weekly client reports by copying numbers from several tools?

Or:

I noticed you run onboarding for small agencies. What is the part that still lives in a spreadsheet?

Those questions give the other person an easy way to correct you. That is a feature, not a failure. A “no, we do not have that problem” response saves you more time than a vague compliment ever will.

Do not pitch before you understand the workaround

The quickest way to get weak feedback is to show a polished demo and ask, “Would you use this?” Most people will say something encouraging. They are reacting to your effort, not making a buying decision.

Ask about the present instead.

  1. What happened the last time this problem showed up?
  2. What did you do instead of solving it properly?
  3. How much time, money, or risk did that workaround create?
  4. Who else is involved in the process?
  5. What would make a new tool too annoying to switch to?

These questions reveal the language that should appear in your product, sales page, and onboarding. More importantly, they reveal whether the pain is frequent enough to matter.

Look for three kinds of evidence:

  • repetition: the problem occurs weekly or monthly, not once a year;
  • cost: the workaround consumes money, time, reputation, or sleep; and
  • ownership: a clear person is responsible for fixing it.

If all three are present, you have a plausible early customer. If only the first is present, you may have a nice-to-have feature. If none are present, do not build more product to force the issue.

The first-use test: make the first five customers unscalable

Founders often treat manual work as a sign that the product is not ready. At this stage, manual work is research.

For the first five to ten serious prospects, offer to help them reach the promised outcome. Join a call. Import the first file. Configure the integration. Create the first workflow with them. Watch where they hesitate, what they call things, and what they refuse to do.

This is sometimes called concierge onboarding. The label does not matter. The rule does: do not confuse an unfinished onboarding flow with an unproven product.

If you can manually help the right person get value, you can learn whether the core result is worth automating. If you cannot help them even with your full attention, a better tooltip will not save the idea.

Keep a short note after every session:

Question What to record
Trigger What made them try the product now?
First obstacle Where did they pause or become confused?
Outcome What concrete result did they get?
Exact language How did they describe the value?
Next action Did they ask to repeat, invite someone, or pay?

After five sessions, do not summarize from memory. Read the notes and mark the phrases that repeat. Repeated language is often more valuable than feature requests. It tells you the job people are actually hiring the product to do.

Ask for commitment after value, not before it

There is a useful middle ground between giving everything away and demanding payment too early. Ask for a small commitment after the user has experienced the core outcome.

That commitment can be payment, a paid pilot, a calendar date for a second session, access to real data, or an introduction to another person with the same problem. The right choice depends on your product. What matters is that the user gives up something scarce.

Why wait until after first value? Because early customers need to trust that you understand their situation. A founder who has just watched them solve a real problem has earned more of that trust than a landing page can.

Do not, however, hide from the money question forever. A useful phrase is:

If this keeps saving you this amount of work each week, would you be comfortable paying for it when the pilot ends?

It is direct without pretending the product is finished. Listen for conditions. “Yes, if my teammate can use it too” is not a yes, but it is excellent product information. “Yes, if it works with our current system” identifies the integration that may matter most.

A seven-day version of the test

You do not need a month-long launch campaign to do this well. Try this seven-day sequence instead.

Day 1: define the outcome

Write the single outcome a person should reach on their first use. Remove any extra outcome from the test.

Day 2: build the list

Create a list of forty people or teams. Add one sentence next to each name explaining why they may have the problem. If you cannot write that sentence, they do not belong on the list.

Day 3: start ten conversations

Send short, personal questions. Do not include a calendar link in the first message unless the person asks. Your job is to understand the current workaround.

Day 4: run two discovery calls

Ask about the last time the problem happened. Capture the exact wording. Do not rush to demonstrate your product.

Day 5: invite two people into a guided first use

Show only enough product to create the defined outcome. Take notes on every place where you must explain something twice.

Day 6: request a commitment

Ask for the next scarce action: a pilot fee, real data, a follow-up session, or an introduction. Record the reason if they decline.

Day 7: decide what to change

Do not add a broad feature list. Choose one friction point that blocked first value and one repeated phrase that should change your positioning.

What a pass looks like

This test passes when you see a pattern, not when everybody says yes. A reasonable early signal looks like this:

  • several people independently describe the same costly workflow;
  • at least two complete the first useful outcome with your help;
  • at least one person makes a meaningful commitment; and
  • you can describe exactly who should be contacted next.

It fails when the conversations produce unrelated pains, people admire the idea but will not make time to try it, or you cannot get anyone to a useful outcome even with hands-on support.

Failure is not a verdict on you. It is an instruction to narrow the audience, alter the outcome, or stop investing in a weak idea before it becomes expensive.

A quick checklist

  • [ ] I can name the first useful outcome in one sentence.
  • [ ] I have a list of 40 people with a reason each may feel this pain.
  • [ ] My first message is a question, not an announcement.
  • [ ] I know the current workaround before showing the product.
  • [ ] I will personally help the first five serious users reach value.
  • [ ] I will ask for a scarce commitment after value appears.
  • [ ] I will change one onboarding friction point, not add ten features.

Traffic will matter later. But early on, one person who uses the product successfully can teach you more than thousands who scroll past a landing page. Start with the names. Earn the first useful outcome. Then build the repeatable system around what actually worked.

Sources & further reading

The discussion

Add your perspective

Keep it useful and specific. Your email address is never published.

Still building?

Get the next useful signal in your inbox.