How to choose your first customer segment: name a problem, not an industry

Choose your first customer segment by naming a specific problem in a specific setting, then checking it against evidence. An industry label is too broad to guide early product work. "Manufacturing" contains many jobs, constraints, buyers and purchasing processes. "Procurement coordinators onboarding small local suppliers at a single-site manufacturer" gives you something you can investigate.

Treat the first segment as a working focus. You are choosing where the next round of research or a small product test is most justified, and writing down what would make you change course.

The framework below is our own, and its supplier-onboarding example is made up.

1. Describe the situation before the company category

A useful segment definition has four parts: the person doing the work, the situation that triggers it, the constraints around it and the outcome they need.

For example: "An operations coordinator at a small agency who needs to collect new subcontractor details before a project starts, without a dedicated procurement team." That is still a guess, but it tells you whom to recruit and what to ask.

Compare it with "SMBs that need automation." That covers too many unrelated workflows, and it has already decided that automation is the answer.

GOV.UK's research planning guidance connects the groups you study to the questions you need answered. Use that link to decide which differences between potential customers actually matter.

2. Judge reach, problem and money separately

A segment can look good on one of these and bad on another, so judge them apart:

• Research access: can you reach relevant people and understand their work?
• Problem fit: does this particular workflow have an unresolved need your team could address?
• Commercial fit: is there a realistic path to adoption and payment?

An accessible group may be a good place to learn without becoming your first customers. A group with a serious problem may have purchasing rules your current product can't meet. Record both facts instead of collapsing them into one "good segment" verdict.

3. Build an evidence matrix where "unknown" is allowed

Make a column for each candidate segment and a row for each uncertainty. Start a cell at "unknown" until you have evidence. Unknown is different from weak demand.

The right-hand column lists things to investigate, not rejection rules. A rare event can still matter a great deal, and a long buying process is fine for some businesses. Judge the evidence against the business you are actually trying to build.

4. Fill the matrix with next questions, not invented pain scores

Back to the made-up example. The supplier-onboarding founder is considering three starting points:

• Small agencies: an operations generalist coordinates new subcontractors.
• Single-site manufacturers: procurement staff coordinate new local suppliers.
• Small nonprofit organizations: an administrator coordinates vendors for programs or events.

Don't score each one's pain from your desk. Write the next evidence each one needs. For agencies, find out what happens when a subcontractor joins an active project. For manufacturers, find out which checks are required before an order can be placed. For nonprofits, find out who gathers the information and who authorizes payment.

The same phrase, "supplier onboarding," may hide three different jobs. If the work differs substantially, you may be evaluating three products rather than three audiences for one product.

5. Count the spreadsheet as a competitor

Competition includes doing the work by hand, handing it to someone else, using a broader system and living with the delay. Ask what people actually choose and why.

The SBA's market research guidance covers demand, alternatives, market context and competition across segments. Use that kind of secondary research for context, then study the specific workflow directly.

A spreadsheet is not proof of an opportunity. It may be cheap and entirely sufficient. Your research has to explain what is unresolved, beyond the fact that something could be rebuilt in software.

6. Keep users, beneficiaries and buyers in view

The person doing onboarding feels the repetitive work. A manager cares whether projects are ready. Finance needs accurate payment details. Someone else may approve a software purchase.

For each segment, sketch the path from the task to a buying decision. Which role can describe the problem? Which can approve a change? Which might block adoption for a reason your product doesn't address yet?

If you have interviewed only one role, mark the others as missing. A friendly user's enthusiasm is not a completed buying path.

7. Write your conditions for moving forward before you read your notes

For example: a recurring unresolved situation, a coherent set of requirements, access to people who can test a proposed change and a plausible purchasing route.

Attach evidence to each judgment. A numeric score helps only when its meaning is clear. Adding up several guesses gives you a bigger guess.

A decision note can be short:

We will focus the next round on [segment] because [observed evidence]. The largest unresolved issue is [uncertainty]. We will test it by [action]. We will reconsider if [counterevidence]. This decision does not establish [limits].

8. Change the segment when the explanation changes

You may find that company size was a poor dividing line, and transaction complexity or responsibility for the task mattered much more. Update the definition.

Keep rejected and deferred segments in the record with their reasons. "No reachable participants yet," "existing tools appear sufficient" and "requirements exceed our scope" each point to a different next step.

Then pick the segment with the strongest evidence and book your next conversations there. You don't need to have proven the market to do that.