How to define a useful audience for your SaaS

A useful audience definition helps you decide whom to learn from, what to say, and where your product can deliver value. Build it around a real workflow and the conditions that make your solution relevant. Treat every unverified detail as an assumption.

Use this guide to write one audience hypothesis, with product requirements kept separate from discovery filters. The worksheet records the evidence and the next question to test.

Start with the decision the definition must support

An audience description is useful when it changes a decision. It might help you recruit research participants, choose prospects for an evaluation, write a homepage, or select a distribution channel. Begin by naming that decision.

A broad market estimate and a practical prospecting definition serve different purposes. “Companies that use software” may describe a large market, but it does not help you choose tomorrow's conversations. A detailed imaginary persona may be equally unhelpful if its age, hobbies, or preferred social network have no bearing on the buying decision.

For an early product, start with one group you can learn from and support. You are choosing a starting point, not declaring that no other customer could ever benefit.

Describe the job and working context

Write what someone is trying to accomplish, when the work happens, and what makes it difficult. Use their vocabulary where you have evidence. If you have no customer evidence yet, label the description as a hypothesis.

A fictional example: “Engineering teams that need to distinguish unreliable API tests from genuine release problems.” This gives you a job to investigate. “Innovative, fast-growing technology leaders” does not.

Now add the context that affects the solution. Does the team run tests before every release? Does the person investigating them have access to the required logs? Does the product support their environment? Each relevant condition narrows the audience for a reason.

Avoid inferring a technology stack from company size or industry. Those attributes can help you find candidates, but the actual integration requirement still needs verification.

Separate users, champions, and buyers

The person who experiences a problem may not control the budget. Your definition should describe the people involved without forcing them into one persona.

One person may hold several roles in a small company. In another organization, several people may share one role. Record what you have observed instead of assuming that a title always carries the same authority.

For each role, capture the relevant concern. A user might care about investigation time, a buyer about predictable costs, and a reviewer about acceptable access. These are questions to verify, not universal truths about those roles.

Map the responsibilities that affect adoption. These are roles to confirm, not assumptions about authority based on job titles.

Open the full-size graphic

Find triggers and current alternatives

A trigger explains why someone might investigate a solution now. Examples include a recurring failure, a new responsibility, or a workflow becoming too expensive to handle manually. Record the actual event when known.

A trigger is different from a generic company attribute. Funding, headcount growth, or an industry label may correlate with a need, but none proves that a particular team is ready to act.

Ask what people currently do instead. The alternative may be a competing product, a spreadsheet, an internal script, outsourced help, or accepting the problem. Understand why that alternative persists. It might be sufficient, familiar, inexpensive, or tied to another process.

Your audience definition becomes more useful when it says why change is plausible and what would prevent it. A painful problem with an adequate existing solution may still be difficult to displace.

Distinguish requirements from discovery filters

A requirement determines whether you can serve the customer. A discovery filter helps you locate likely candidates. Keep them in separate fields.

For the fictional monitoring product, a supported integration could be a requirement. An engineering team-size range might be a discovery filter because it helps you search. If teams outside that range also benefit, the range should not automatically become a disqualifier.

Disqualifiers prevent wasted evaluations. Examples include an unsupported environment, no recurring use case, or a required capability your product does not provide. State them plainly. “Not a good cultural fit” is too vague to guide a decision.

You may also have temporary operating constraints, such as being able to support only one timezone during a hands-on pilot. Label these as constraints of the current offer so they do not become permanent assumptions about the market.

Check whether a criterion excludes the right people

Imagine a fictional reporting product that requires a supported data source. An agency has that source and a recurring reporting job but sits outside your preferred company-size range. It may still be worth interviewing. Another agency matches the size range but uses an unsupported source; it cannot complete the current evaluation.

The source requirement changes product fit. The size range helps discovery until evidence establishes that size changes the workflow or purchasing decision. Keeping those fields separate prevents a convenient search filter from discarding suitable customers.

For every exclusion, ask: “What fails if this condition is absent?” If you cannot answer, mark it as a filter to investigate rather than a permanent disqualifier.

In this fictional example, company size helps find candidates while data-source support determines compatibility. Neither size matching nor compatibility alone proves demand.

Open the full-size graphic

Build an evidence ledger

For every meaningful audience claim, record its source and confidence. Keep the original observation separate from the interpretation it supports.

A useful ledger includes the claim, the conversation or observation behind it, the date, evidence against it, and the next question. “Two interviewees described investigating the same issue weekly” is more useful than “This segment has high demand.”

Do not invent quotes, purchasing intent, or behavioral details to fill gaps. A gap identifies something to learn. Public research can help you locate candidates and understand terminology, but it cannot replace direct evidence about a specific customer's workflow.

If your evidence comes only from people already in your network, note that limitation. Their needs, accessibility, or willingness to help may differ from people reached through a broader channel.

Compare a few plausible segments

When several audiences seem promising, compare them using the same questions: how consequential is the problem, can the product deliver a result, can you reach relevant people, what blocks a purchase, and how much support does delivery require?

Use qualitative judgments supported by notes before introducing a weighted score. An unsupported “9 out of 10” can hide uncertainty. If you use scores, define what each score means and retain the evidence behind it.

Pick the segment with the strongest combination of fit, access, and a feasible next test. A larger theoretical market is not automatically the best first audience. A group that is easy to reach is not automatically the best long-term business.

Keep alternatives in the ledger rather than building a separate campaign for every variation of stage, funding, role, and company size. Segment further when a difference changes the problem, offer, buying process, or channel decision.

Write a definition you can use tomorrow

Use this sentence structure: “We are testing whether [people in a specific context] who encounter [problem or trigger] can achieve [result] with our product, provided [requirements]. We will initially reach them through [observable route].”

For the fictional product: “We are testing whether engineers investigating recurring API test failures can reach a useful diagnosis with our monitoring product, provided their test environment is supported. We will initially recruit through existing engineering relationships and relevant discussions we participate in.”

The sentence makes uncertainty visible. It tells you whom to speak to and what to evaluate without pretending you already know the answer.

Revise from observed outcomes

Use the definition in conversations and evaluations. Record who reached the result, who did not, and why. Look for differences in workflow, requirements, urgency, decision authority, and support effort.

Use customer-fit analysis when you have enough customer history to compare actual results and delivery effort. Update a criterion when the evidence changes a decision. Preserve previous versions and the reason for the change. This makes it possible to distinguish a deliberate refinement from a team quietly using different definitions of the customer.

Download the audience hypothesis and evidence worksheet to create your first version. Then use finding your first SaaS customers to test it through real conversations and evaluations.

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