Customer Discovery Questions to Ask Before Building a SaaS

You found someone who already complained about a problem. They posted, they were annoyed, and they agreed to talk. Now you have maybe 20 minutes, and the questions you ask will decide whether you learn something real or just collect polite encouragement.

This is a question set for that first conversation. It is built for people who complained in public, so you already know the topic. Your job is not to confirm the idea. It is to find out what they do today, what it costs them, and whether they have ever tried to fix it.

Who this question set is for

Use it when the person on the other end has already described the problem in their own words. That might be a Reddit post, a forum thread, or a comment on a competitor's page.

If you are still working out where to find those people, start with how to find SaaS ideas on Reddit. This article picks up after they reply to your message.

A complaint is a starting point, not proof. Someone venting for a minute is different from someone who has lost money, built a spreadsheet, or paid for a tool. These questions separate the two.

Set the rules before the call

A few ground rules keep the conversation honest.

• Talk about their life, not your idea. Do not pitch. If you describe a solution, people start judging it instead of describing their problem.
• Ask about the past, not the future. What someone did last month is more reliable than what they say they would do.
• Aim to listen for most of the call. If you are talking more than they are, you are probably leading.
• Write down their exact words. Phrases they use become your landing page copy later.

Send one line before the call so expectations are clear: you are researching a problem, you are not selling anything, and you want to hear how they handle it today.

Opening questions (first 3 minutes)

Start wide. Do not mention their post yet.

1. "Can you tell me a bit about your role and what a normal week looks like?" This gives you context and gets them talking.
2. "Where does [the area of work] fit into that week?" You learn how big the problem is relative to everything else on their plate.

Then bring up the complaint, neutrally:

1. "You posted about [topic] recently. What was going on that day?"

Notice what this does. It does not say "you said it was a big problem." It lets them tell you how big it was.

Questions about the last time it happened

The most useful stretch of the call is a walk through a specific recent event. General answers are mostly opinion. Specific stories are evidence.

1. "Walk me through the last time this came up."
2. "What happened right before that? What happened right after?"
3. "Who else was involved?"
4. "How long did it take from start to finish?"
5. "What was the most frustrating part of that?"

If they say "it happens all the time," ask for the most recent time anyway. You want one real example, not a summary.

Here is how this plays out with a real complaint. A Reddit user wrote, "Every time i took on a new client i was doing the same manual analysis over and over." (source post). Good follow-ups would be: "Walk me through the last new client. What did you do first? How long did the analysis take? What did you do with it afterward?"

None of those follow-ups suggest an audit tool. They just map the work.

Questions about current workarounds

Workarounds are the strongest signal in discovery. If someone has built something themselves, even an ugly spreadsheet, the problem matters to them. If they have done nothing, it may be a minor annoyance.

1. "What do you do today to deal with this?"
2. "How did you come up with that approach?"
3. "What have you tried that did not work?"
4. "What do you like about how you handle it now?"
5. "If you stopped doing it that way tomorrow, what would break?"

Question 12 is easy to skip, and it is valuable. Whatever people like about their current approach is something your product has to match or beat.

Pay attention to how much effort the workaround takes. A recurring manual process, a person assigned to it, or a template passed around the team all show the problem is real enough to organize around.

Sometimes the workaround is just "I put up with it." That is also an answer. It usually means low urgency.

Questions about time, money and spending

Most first interviews skip this part because it feels awkward. Do not skip it. You are not asking whether they would buy your product. You are asking what the problem already costs.

1. "Roughly how much time does this take you in a typical month?"
2. "What happens if it does not get done, or gets done badly?"
3. "Are you paying for any tools or services related to this today?"
4. "What do they cost, and who approves that spending?"
5. "Have you ever looked for a paid solution? What did you find?"
6. "Why did you not buy it?" (or, if they did: "What made you decide it was worth paying for?")

The last question is the one people remember. Someone who looked at paid options and walked away tells you what a competitor got wrong. Someone who bought something tells you what a buyer values.

Take stories of real spending more seriously than hypothetical interest. A person who says "I would pay for that" has not paid for anything yet.

If you want a real-world sense of what a costly manual problem sounds like, look at the post behind this quote from r/sysadmin: "8 months post-acquisition and we still have 200 people with active accounts in both tenants." (source post). Follow-ups worth asking someone like that: who owns the cleanup, what it is delaying, and whether they have budgeted anything for it.

Questions about who decides

A person can feel the pain and still have no power to buy. Find out early.

1. "If you wanted a better solution, who would need to sign off?"
2. "Is this your problem, your team's problem, or your company's problem?"
3. "Has anyone else brought this up internally?"

For solo operators, replace these with: "Is this something you would pay for out of your own pocket, or does it come out of a client budget?"

Closing questions

End with questions that open doors, not ones that fish for compliments.

1. "Is there anything about this I should have asked and did not?"
2. "Who else deals with this that I should talk to?"
3. "Would it be okay to follow up if I have more questions?"

Question 24 is how you get your next interview without cold outreach. Question 25 gives you permission to come back later with something concrete.

Leading questions to avoid

Leading questions sneak your assumptions into the answer. Here are common ones and what to ask instead.

The pattern: swap hypotheticals for history, and yes-or-no questions for open ones.

Also avoid describing your idea in the middle of a question. "We are thinking of building X, and I wondered..." changes everything the person says next.

How to read what you hear

After each call, sort what you heard into three buckets.

Strong signals

• They described a specific recent event without prompting.
• They built or bought something to cope.
• They can name a cost in time, money, or missed work.
• They have already searched for alternatives.

Weak signals

• "That sounds cool."
• "I would probably use that."
• General agreement with no story behind it.
• Interest in the idea, but no change to what they do today.

Red flags

• They cannot remember the last time it happened.
• They have tried nothing and feel no urgency.
• The person who feels the pain has no say in buying.

Do not count a single call. Look for the same workaround, the same frustration, or the same phrases appearing across several conversations. Patterns across five or more people are worth more than one enthusiastic person.

A simple one-page call template

If you want to keep it short, copy this structure:

1. Role and context (2 minutes)
2. The last time it happened (8 minutes)
3. Current workaround and what is missing (5 minutes)
4. Time, money and tools already spent (5 minutes)
5. Who decides, and who else to talk to (3 minutes)

That is about 23 minutes. Ask for 15 or 20 and let them extend it if they want.

Take notes in two columns: what they said, and what you think it means. Keep the columns separate so your interpretation does not leak into your evidence.

Finding people who already complained

The hardest part of discovery is often getting the first conversation. People who posted a complaint publicly are warmer than strangers, because they already told the world the problem exists.

SaasNiche scans Reddit communities for pain points, scores them 0–100 for intensity, frequency and willingness to pay, and shows verbatim quotes with source links. It also lets you message the original poster, so you can ask these questions in a real conversation. You can check the evidence behind each quote before you reach out. The Starter plan includes a 7-day trial if you want to try it on a niche you are exploring.

FAQ

How many discovery interviews should I do before building a SaaS?

There is no fixed number. A practical approach is to keep talking until you stop hearing new things. If your first handful of conversations describe the same problem and the same workarounds, you are probably seeing a pattern. If every person describes something different, you may have a vague problem or the wrong audience.

Should I mention my idea during a discovery call?

Not in the first conversation. Describing a solution pulls the discussion toward whether they like it, and people tend to be polite. Stay on their current situation. If you want feedback on a concept, do that in a separate, later conversation once you understand the problem.

How do I ask about money without making it awkward?

Ask about what they already spend, not what they would spend. Questions like "Are you paying for any tools for this today?" and "What does that cost?" are factual and comfortable. They also give you a realistic price anchor from real behavior.

What if the person says the problem is not that important?

That is useful information. Ask what they do about it now and what would make it more urgent. If nothing would, treat it as a weak signal and move on to another problem or another audience before building anything.

How long should a customer discovery interview be?

Twenty to thirty minutes is enough for a first conversation. Ask for less time than you need, stay on schedule, and let the other person extend the call if they are engaged.