---
title: How to find your first SaaS customers
slug: find-first-saas-customers
status: cms-draft
topic: Acquisition and channels
description: Find early SaaS customers by choosing a specific problem, researching relevant prospects, running useful evaluations, and learning from real usage.
author: Jon Bishop
---
# How to find your first SaaS customers

Finding your first customers starts with a narrow problem and a credible way to help someone solve it. Use conversations to test your understanding, then offer an evaluation that lets a potential customer experience the result. Track what people do as well as what they say.

The working output is a candidate evidence log and one bounded evaluation: a useful result, clear responsibilities, and a decision to buy, stop, or answer a named remaining question.

## Decide what you need to learn

“Get customers” leaves too many questions open. You might need to learn whether a problem happens often, whether your product can solve it, whether someone will change their workflow, or whether a buyer will pay. Those are different tests.

Write the uncertainty before choosing an activity. If you do not understand the problem, start with research. If people already describe it clearly but your product has no usage, focus on a small evaluation. If users get value but cannot buy, investigate the purchasing process.

Keep three roles distinct. A research participant helps you understand a workflow. A design partner agrees to help shape or evaluate a solution. A customer makes a purchasing commitment under agreed terms. Someone can move between these roles, but a friendly conversation does not make them a customer.

![Research participants describe experience; design partners help explore a scoped solution; customers accept an offer and terms. One relationship does not automatically become another.](https://jonbishop.co/learn/assets/first-customer-commitments.png)

A useful interview or enthusiastic design partner can inform the product without proving a willingness to buy. Make each agreement explicit.

[Open the full-size graphic](https://jonbishop.co/learn/assets/first-customer-commitments.png)

## Choose one plausible starting audience

Describe a group through its problem and working context. “Small SaaS companies” is usually too broad to guide a conversation. “The person responsible for investigating unreliable API tests at a small SaaS company” gives you a workflow to ask about.

Add only the constraints that matter to delivering value: a particular integration, enough usage to encounter the problem, or the ability to run an evaluation. Do not add company-size bands or job titles just to make the audience sound precise.

The [audience definition guide](https://jonbishop.co/learn/resources/define-your-saas-audience/) explains how to distinguish useful constraints from assumptions. Treat your first audience as a hypothesis. You can change it when evidence shows that another group has a more urgent problem or an easier path to value.

## Look for evidence of the problem

Start where the workflow is visible: your existing relationships, communities you participate in, relevant discussions, company websites, and public requests for help. A conversation about a recurring manual task can give you a reason to investigate. A job title alone cannot establish need.

Record the source, date, exact observation, and your interpretation separately. A company hiring a reliability engineer may care about reliability; it does not prove that it needs your monitoring product. A public complaint may describe an old issue that has already been resolved.

Use a short candidate log:

| Field | What belongs here |
|---|---|
| Observed signal | The specific statement or workflow you saw |
| Possible relevance | Why your problem hypothesis may apply |
| Unknown | What you still need to learn |
| Disqualifier | A condition that makes an evaluation inappropriate |
| Next step | A relevant question or useful resource |

Prefer a small set you can research thoughtfully to a large list you cannot explain. Do not collect personal details you do not need. Respect community rules and a person's decision not to continue.

## Make a request that fits the relationship

A useful first request is concrete and easy to assess. Explain why you contacted the person, what you are trying to understand, and what you are asking them to do. Avoid implying that a public signal proves they have a problem.

A fictional message might read: “You mentioned that inconsistent API tests make releases harder to assess. I’m researching how teams investigate those failures. Would you be open to a short conversation about your current process? I can share the investigation checklist I’m putting together.”

Use that wording only when the observed statement exists and the checklist is real. Adapt the request to your relationship and the setting. A warm introduction, a reply within an existing discussion, and a direct sales message require different context.

If you already know the problem and have a usable product, say so. Use the [discovery call guide](https://jonbishop.co/learn/resources/run-a-saas-sales-discovery-call/) when the next step is a commercial fit discussion. Ask about a specific evaluation instead of disguising a sales request as research. Make the scope, effort, price if applicable, and expected result clear.

## Ask about the last real occurrence

People are better at describing a recent event than predicting whether they would buy a hypothetical product. Ask them to walk through the last time the problem occurred.

Useful questions include:

- What triggered the work, and who noticed it first?
- What did you do, in what order, and with which tools?
- What happened when the issue stayed unresolved?
- What have you already tried, and why did you keep or abandon it?
- Who would need to approve a change to this workflow?

Keep notes in the person's language. Separate observations from your conclusions. “They spent part of Tuesday investigating a failed release” is an observation. “This is a high-intent buyer” is an interpretation that needs more evidence.

Do not turn every conversation into a pitch. Explain your solution when it helps answer the question under discussion, then check whether the person sees a relevant use for it. A clear mismatch is useful learning.

## Offer a small, useful evaluation

Agree on a result the potential customer cares about. For a fictional API monitoring product, that might be investigating one recurring test failure with enough context to choose the next action. “Log in and click around” does not define success.

Set the scope together: the workflow to try, what the customer provides, what you provide, who participates, how long the evaluation lasts, and how you will review the result. Clarify any payment, support, access, and data-handling expectations before starting.

Remove avoidable friction without concealing the product's limitations. Manual help can be appropriate early, but record where you intervened. If you perform the entire task for the customer, you have learned about a supported service, not necessarily independent product adoption.

An evaluation should have a useful ending even when the answer is no. Summarize what worked, what did not, and whether to buy, extend a specific test, or stop. Avoid indefinite “pilot” relationships with no decision.

## Look beyond signup and praise

Track whether the person reached the agreed result, returned when the problem happened again, and included the relevant decision maker. Record the time and support required. These observations help you understand whether the audience and product fit each other.

A signup measures interest or willingness to try. A compliment measures a reaction. A purchase measures a commercial commitment. Repeat use and renewal answer additional questions. None should silently stand in for all the others.

For each evaluation, capture the starting situation, result, remaining obstacle, next decision, and owner. Use the [funnel analysis guide](https://jonbishop.co/learn/resources/analyze-a-saas-funnel/) when you have enough consistent records to examine where people stop. Small samples can reveal questions to investigate without supporting precise conversion forecasts.

## Read an evaluation as a decision record

Consider two fictional responses to the same offer. One participant praises the idea but has no current task to try. Another has the recurring problem, confirms a supported environment, and agrees to evaluate one real workflow. The second response supports an evaluation; the first supports keeping a research note. Neither establishes repeatable demand.

At the review, ask whether the result happened independently, with assistance, or not at all. If the result occurred only because you manually gathered the inputs, record that contribution. The next test may concern setup rather than acquisition.

Close with a concrete decision: purchase under stated terms, stop for a recorded reason, or extend to answer one named question with a new end condition. This keeps an encouraging conversation from becoming an indefinite pilot.

![A bounded evaluation agrees on the task, observes completion and assistance, then chooses buy, stop, or a scoped extension to answer a named question.](https://jonbishop.co/learn/assets/first-customer-evaluation.png)

Positive comments are not the evaluation result. Record the work performed and the basis for the decision, including any help required.

[Open the full-size graphic](https://jonbishop.co/learn/assets/first-customer-evaluation.png)

## Change one meaningful assumption at a time

After a few conversations or evaluations, review the evidence together. Are you reaching the wrong people, solving an occasional inconvenience, asking for too much setup, or failing to deliver the promised result?

Choose the next change that addresses the clearest obstacle. You might narrow the audience, change the evaluation, improve onboarding, or revise the problem statement. If you change all of them together, it becomes harder to understand why the next outcome differs.

## Use the first-customer workbook

Download the [first-customer research and evaluation workbook](https://jonbishop.co/learn/resources/first-saas-customers-workbook/) to keep your hypothesis, candidate evidence, conversation notes, and evaluation decisions in one place. Start with one audience and one result; expand when your records give you a reason.

For the next step, use [choosing a SaaS marketing channel](https://jonbishop.co/learn/resources/choose-a-saas-marketing-channel/) to turn a promising route to customers into a bounded channel test.

Explore the SaaS growth guides and templates to choose another problem to work on.