How to Define Your Ideal Customer for Your SaaS

When you start building a SaaS product, it is easy to focus on the product itself. You decide what to build, create the first version, and then start thinking about how to get people to use it.

Who exactly should you try to sell it to?

You might have a general idea. Maybe your SaaS is for small businesses, developers, marketing agencies, or freelancers. These descriptions are usually too broad to help you find your first customers.

If I tell you that my SaaS is for small businesses, you still don't know which businesses I should contact or what problem I should talk to them about.

I need to get more specific.

I want to understand who has the problem I am solving, how they deal with it today, and what would make them spend money on a different solution.

That gives me a much better starting point for finding customers.

Start with the problem

I would start with the problem I am trying to solve.

Let's say I build a SaaS product that automatically creates reports for marketing agencies.

My first description might be:

My SaaS is for marketing agencies.

That doesn't tell me enough.

I need to understand what these agencies are doing that my product could improve.

Perhaps I discover that some agencies manage several clients and prepare weekly reports manually. Someone has to collect information from different advertising platforms, put it together, and send a report to each client.

Now I have a more useful description of the customer.

I am looking for agencies that have this particular workflow and are spending significant time on it.

That gives me something I can investigate.

I can find agencies that fit the description. Then I can talk to them about how they currently prepare their reports.

Look at how they solve the problem today

A potential customer already has some way of dealing with the problem.

They might use another SaaS product. They might use a spreadsheet. They might have someone on the team doing the work manually.

They might also decide that the problem isn't serious enough to spend money on.

All of these situations tell me something.

Let's say I discover that my potential customers spend two hours every Friday preparing reports in a spreadsheet.

That spreadsheet is part of the competition.

I am asking the customer to change a process that already works well enough for them. So I need to understand what is wrong with their current process.

Maybe it takes too much time.

Maybe it produces mistakes.

Maybe the process becomes difficult when they get more clients.

Maybe they are paying an employee to do repetitive work.

These details help me understand whether there is a real reason for someone to switch to my SaaS.

A problem needs to be important enough to solve

People have problems all the time.

They don't pay for software to solve every problem they encounter.

Someone might tell me that an automated reporting tool sounds useful. That doesn't mean they are going to pay for it.

I would ask about the last time they had to prepare a report.

How did they do it?

How long did it take?

Who did the work?

What happened when something went wrong?

Questions like these give me information about what the customer actually does.

Y Combinator recommends asking about real situations and understanding the cost of the problem rather than relying on hypothetical answers about what someone might do in the future.

There is a big difference between:

"I would probably use that."

and:

"I spend three hours every Friday doing this."

The second answer gives me something I can investigate.

The cost doesn't always have to be financial.

A problem can be interesting because it happens frequently, takes a lot of time, causes mistakes, or prevents the customer from doing something else.

I want to understand how serious the problem is from the customer's point of view.

Find out when the problem becomes important

A customer can have a problem for years without looking for software.

Something can change their situation.

A company gets more customers. A team becomes larger. An existing process becomes too slow.

Let's go back to the reporting SaaS.

A marketing agency with three clients may have no problem preparing reports manually. An agency with 20 clients may spend several hours every week doing the same work.

The number of clients may be an important part of my customer definition.

It also gives me a useful signal when I start looking for potential customers.

I can look for agencies that have reached the point where manual reporting is becoming expensive in terms of time.

Think about what the customer is trying to accomplish

Another useful question is:

What is the customer actually trying to get done?

A person doesn't buy reporting software because they want another piece of software.

They want to produce reports for their clients without spending hours preparing them.

A developer doesn't necessarily want API documentation software because they enjoy writing documentation.

They want other developers to understand and use their API without constantly asking questions.

This way of looking at customer needs is related to the Jobs-to-be-Done approach. It focuses on the situation in which a customer uses a product and the outcome they are trying to achieve.

I find this useful because it moves the discussion away from product features.

Instead of asking, "Who might like my feature?" I can ask, "Who is trying to accomplish this particular thing?"

That usually gives me a better customer definition.

Don't confuse an ICP with a buyer persona

If you are building a B2B SaaS, you will often hear the term Ideal Customer Profile, or ICP.

An ICP describes the type of organization that is a good fit for your product.

A buyer persona describes a person involved in the buying process. That person may use the product, make the purchasing decision, or influence the decision. HubSpot makes this distinction in its current guidance on ICPs and buyer personas.

Imagine that my SaaS is designed for small software companies.

My ICP might be:

B2B software companies with 10 to 50 employees that receive a growing number of customer requests and need a better way to organize product feedback.

The people I need to talk to could be founders, product managers, or engineering managers.

For a small company, one person may fill all of these roles.

For a larger company, they may be different people.

That distinction becomes important when you start selling to businesses with more complicated buying processes.

If you are building a B2C SaaS, the situation is different. There isn't a company-level ICP in the same sense, so you would focus on the characteristics, behavior, and situation of the individual customer.

Your first ICP is a hypothesis

If your SaaS is new, you probably don't have enough information to know exactly who your ideal customer is.

That's normal.

You can start with a hypothesis.

For example:

I believe my first customers will be freelance web developers who manage several client websites and spend significant time handling maintenance requests.

Now I have something I can test.

I can find people who fit that description and talk to them.

I can ask how they handle maintenance today. I can ask what takes the most time. I can find out whether they have already tried another solution.

Maybe I discover that freelance developers don't have a serious enough problem.

Maybe agencies have the same problem much more often.

Maybe both groups have the problem, but agencies are more willing to pay for a solution.

Any of those results can change my customer definition.

Paul Graham has written about manually recruiting early users and paying attention to the people who respond particularly well to the product. Those early customers can help a founder understand who the product is really useful for.

Talk to people who fit your hypothesis

If you don't have customers yet, find people who match your initial customer definition.

You don't need a huge research project.

Start with a group of people who appear to have the problem.

Ask them about their experience.

I would ask questions like:

How did you handle this the last time it happened?

What are you using today?

How often do you have this problem?

How much time does it take?

Have you tried another solution?

What happens if you don't solve it?

These questions are more useful than asking whether someone likes your product idea.

The person may say that your idea is great.

Then you discover that they only experience the problem once every six months.

That is very different from someone who deals with the problem every week.

Ask about real behavior

One of the easiest ways to get misleading customer feedback is to ask people to predict what they would do.

For example:

"Would you pay $30 per month for this?"

The answer isn't very strong evidence.

Someone can say yes and never buy the product.

I would rather ask:

"Are you paying for something that solves this problem today?"

Or:

"What did you spend the last time you tried to solve it?"

Actual behavior gives me better information.

If someone already pays for another product, has built a complicated workaround, or spends several hours every week dealing with the problem, I have stronger evidence that the problem matters to them.

That still doesn't guarantee that they will buy my SaaS.

It gives me a much better starting point.

Don't turn a discovery interview into a sales pitch

If the goal of the conversation is customer discovery, I would not start by explaining my product.

I want to understand the customer's current situation first.

Suppose someone tells me that they spend three hours every week preparing reports.

I could immediately explain that my SaaS can do the work in five minutes.

But I would rather ask why the process takes three hours.

What information do they collect?

Where does it come from?

Who prepares the report?

What happens after it is sent?

I can show my product later when I want to test the solution.

Customer discovery, prototype testing, and sales conversations have different goals. Product Talk makes a similar distinction in its guidance on customer interviews and discovery.

Look for patterns

One conversation can give me a useful story.

It doesn't tell me that an entire customer segment has the same problem.

I want to talk to several people who fit the same general description.

Then I compare what they tell me.

Do they describe the problem in similar ways?

Do they use similar workarounds?

Does the problem happen often?

Have they already spent time or money trying to solve it?

Are they actively looking for something better?

I don't need a magic number of interviews.

I want enough conversations to start seeing repeated patterns.

If every person gives me a completely different story, I may be targeting a group that is too broad.

Pay attention to strong signals

Not every piece of feedback has the same value.

There is a big difference between someone saying:

"That's a cool idea."

and someone saying:

"We deal with this every week and currently spend five hours doing it manually."

The second statement tells me much more.

I would pay attention when someone describes a recent problem, explains the workaround they use, tells me what it costs them, or shows me that they have already spent money trying to solve it.

Even stronger evidence comes from behavior.

Someone who agrees to try the product is giving me more information than someone who simply likes the idea.

Someone who pays for it gives me even stronger evidence.

That doesn't mean one payment proves product-market fit. It means I should pay more attention to actions than compliments.

If you already have customers, start there

Existing customers give you useful information because you can look at what they actually do.

Compare customers who continue using the product with customers who sign up and disappear.

Look at product usage, retention, revenue, and the problems those customers originally came to solve.

You may find something you didn't expect.

Perhaps your best customers all have a certain company size. Perhaps they use the product for the same workflow. Perhaps they all started looking for a solution after the same kind of event.

HubSpot recommends using existing customer data together with interviews when developing an ICP. Their guidance includes looking at factors like retention, product adoption, and revenue.

I would not simply copy every characteristic shared by my best customers.

I would look for the characteristics that seem connected to why these customers get value from the product and continue using it.

Who uses the product and who pays for it?

This deserves separate attention in B2B SaaS.

The person using your product may not be the person buying it.

For example, developers may use a product every day while an engineering manager approves the purchase.

In another company, a team member might use the product, a manager might choose it, and someone in finance might approve the payment.

You don't necessarily need a complicated map of the entire buying process when you are starting out.

You do need to know who experiences the problem and who can decide whether the company spends money to solve it.

That information will become useful when you start writing your sales messages.

Can you actually reach these customers?

I would ask one practical question before deciding that a particular group is my first target:

Can I actually find these people?

Suppose I decide that my SaaS is perfect for a very specific type of business owner.

That's useful only if I have a realistic way to reach them.

Maybe they participate in an industry community. Maybe they are easy to identify on LinkedIn. Maybe there is a directory that lists these businesses.

The channel depends on the customer.

I want to be able to take my customer definition and turn it into a list of real people or companies I can investigate.

This is not really part of the formal definition of an ICP. It is a practical question about whether this customer segment makes sense for my current go-to-market strategy.

Keep your assumptions separate from your evidence

I like to write down what I believe and what I have actually learned.

Suppose I write:

Small marketing agencies need automated reporting.

At first, that's an assumption.

Then I talk to ten agencies.

Eight tell me that they spend several hours every week preparing reports. Six already use some kind of workaround. Three agree to try my product.

Now I have evidence.

It still doesn't prove that every small marketing agency is a good customer.

But I have learned something about this particular group.

I can continue testing the same hypothesis. Or I can change it when the evidence tells me to.

Keeping these assumptions visible helps prevent me from treating my first guess as a fact.

Don't make your customer definition too narrow

There is a temptation to keep adding details to the profile.

You might end up with something like:

Freelance Java developers in Ontario who have five clients, use GitHub, work from home, and have been freelancing for more than three years.

That sounds very specific.

But those details don't necessarily tell me anything about whether the person needs my SaaS.

If those characteristics affect the problem or buying decision, they can be useful.

If they don't, they are just extra information.

I want the customer definition to be specific because of the problem, not because I added as many personal details as possible.

Don't make it too broad either

The opposite problem is easier to recognize.

"Small businesses" is too broad for many SaaS products.

"People who want to save time" is even broader.

Compare that with:

Small accounting firms with several employees that spend hours every week manually collecting documents from clients.

Now I have somewhere to start.

I know what kind of company I am looking for.

I also know what problem I should ask about.

A simple way to write your first ICP

Once I have done some initial research, I would write down the current version of my customer definition.

For a B2B SaaS, I would include:

Customer

Who is the company?

Problem

What problem are they dealing with?

Current solution

How do they solve it today?

Frequency

How often does the problem happen?

Cost

What does the problem cost in time, money, mistakes, or missed opportunities?

Trigger

What makes them start looking for a solution?

Desired outcome

What are they trying to accomplish?

Buyer

Who decides whether to purchase the product?

Reachability

Where can I find these companies and people?

Evidence

What have I actually observed that supports this definition?

The exact fields will depend on the SaaS.

I would not create a complicated document just because an ICP template has 30 fields.

A one-page document with useful information is better than a detailed profile full of guesses.

Put it into one sentence

After doing the research, try to describe the customer in one sentence.

For example:

I help small marketing agencies with several active clients reduce the time they spend preparing weekly campaign reports.

This isn't necessarily a marketing slogan.

It is a quick test of whether I understand the customer.

If I cannot explain who I help and what problem I solve without using broad terms like "businesses" or "professionals," I probably need to do more research.

Your first ICP is not your forever market

Your first customer definition is based on what you know today.

It can change.

You may discover that the people you expected to be good customers don't have a strong enough problem. Another group may care much more about the same product.

You may also discover that your product solves a different problem from the one you originally had in mind.

That's useful information.

The first ICP gives you a specific group to investigate. Customer conversations, product usage, payments, retention, and referrals give you new information.

You can then update the definition.

This is particularly important for a new SaaS because you simply don't have enough data at the beginning to know everything about your market.

What I would do before looking for customers

I would start with a simple customer hypothesis.

Who do I believe has the problem?

How are they solving it today?

How often does the problem happen?

What does it cost them?

What makes them look for a solution?

Can I actually find these people?

Then I would talk to people who fit that description.

I would listen to what they say, but I would pay even more attention to what they actually do.

If the conversations keep pointing in the same direction, I have a stronger customer definition.

If they don't, I change the hypothesis and keep researching.

That is a much better process than creating a fictional customer profile and assuming it is correct.

Once I know who I am looking for, I can start thinking about where those people spend time and how I can reach them.

And that is the next part of the process: finding your first SaaS customers.