How to Run a Perfect Customer Discovery Call for SaaS Validation?

The best discovery questions are about what the person has actually done, not what they think of your idea, because opinions and predictions are polite fiction and past behavior is fact. Bad customer interviews aren't just a waste of time, they're dangerous: they convince you that you're on the right track when you aren't. This post gives you the questions that get the truth, the ones that quietly guarantee a false positive, and how to tell a real signal from a compliment worth nothing.

What is the one rule behind every good discovery question?

The one rule is to ask questions so grounded in the person's real life that even your mom couldn't give you a misleading answer. That's the essence of The Mom Test, the framework most founders use for customer interviews, and it comes down to three principles that shape every good question.

The three rules:

• Talk about their life, not your idea. The moment you pitch, people get polite and defensive. When you ask about their actual situation, they relax and tell you real stories.
• Ask about specifics in the past, not opinions about the future. People are poor predictors of their own behavior and reliable narrators of their past. Anything about the future is an over-optimistic guess.
• Talk less, listen more. Aim for the customer speaking around 80% of the time. Your job is to learn, not to sell, so give them room to narrate and follow the emotion when you hear pain.

The reason this works is subtle. Most interviews fail not because the customers lie deliberately, but because the questions are designed, often unconsciously, to fish for validation rather than truth. The Mom Test removes the flattery by making it impossible for the person to answer with anything but their actual experience.

Why does pitching my idea ruin the interview?

Pitching ruins the interview because the instant you describe what you're building, everything the person says afterward becomes a reaction to your pitch instead of an honest account of their problem. You've contaminated the data, and you can't un-contaminate it in the same conversation.

Here's the mechanism:

1. People compliment ideas to be nice. When you reveal what you're making, most people shift into being supportive rather than honest, because they don't want to hurt your feelings.
2. Their answers stop being about them. Before the pitch, they were describing their own life. After it, they're evaluating your product, which is a completely different and far less useful thing.
3. You hear what you want to hear. "That sounds great, I'd totally use that" feels like validation but measures politeness, not need.

The discipline is simple and hard: don't mention the idea at all until you've finished learning. You can say you're working on something in the problem space, but don't explain what it does. Keep your solution out of the conversation until the data is collected, and you'll get answers you can actually trust.

What questions should I ask in a discovery call?

Ask open, past-tense questions that make the person narrate real events and real costs, because those produce factual data you can build on. Every strong question points backward at something that actually happened, not forward at something hypothetical.

The questions that reliably work:

• "Walk me through the last time you dealt with this problem. What did you do?" The single most useful question. It gets a concrete story instead of a generic opinion.
• "What did that cost you, in time, money, or stress?" Quantifies the pain and reveals whether it's a painkiller problem or a vitamin one.
• "What have you already tried to fix it? Why didn't it stick?" Existing search effort proves the pain is real. If they've never looked for a solution, they won't buy yours.
• "How often does this actually come up in your week?" Separates a constant, urgent pain from a rare annoyance.
• "How do you handle it today?" Surfaces the workaround, the spreadsheet, the manual process, the contractor, which is your strongest evidence the problem is worth paying to remove.
• (Only at the very end, if at all): "Here's roughly what I've been thinking about. What's your honest reaction?" Treat the answer as a bonus, not the point of the call.

Notice that none of these ask what the person thinks of your idea, and none ask about the future. They ask what they did, what it cost, and what they've already tried. That's where the truth lives.

Why is "would you use this?" the worst question to ask?

"Would you use this?" is the worst validation question because it combines the two things that most reliably produce false positives: a hypothetical about the future and an invitation to be polite. Everyone says yes, and the yes carries no information about whether they'll ever actually pay.

The question fails on two independent counts:

• It's about the future. You're asking the person to forecast their own behavior in a situation that doesn't exist yet. People overestimate their willingness to change, underestimate friction, and forget competing priorities, so even a sincere answer is unreliable.
• It invites politeness. Faced with an excited founder, most people give the encouraging answer to avoid an awkward moment. This is social desirability bias: people present themselves positively and give answers that make everyone comfortable rather than answers that reflect reality.

The result is the classic trap: you describe your idea, the person is kind, they say "that sounds great, I'd totally use that," and you walk away encouraged. Then you build, launch, and discover the enthusiasm evaporated the moment real money and real effort entered the picture. This is why bad interviews are worse than no interviews, a false yes makes you confident enough to spend months building the wrong thing, while no data at least keeps you cautious.

What questions should I never ask, and what do I ask instead?

Never ask questions that invite a polite yes or request a prediction about the future, because they produce encouragement you can't trust and mistake for validation. Every good replacement points backward at a real event the person can't easily distort to be polite.

The questions to cut, and their fixes:

Never ask (fiction)	Why it fails	Ask instead (fact)
"Would you use this?"	A hypothetical about the future; everyone says yes to be polite.	"How do you handle this today?"
"Would you pay for this?"	People are wildly optimistic about hypothetical spending.	"What have you spent trying to solve this already?"
"Do you think this is a good idea?"	Directly requests validation; your mom would say yes too.	"Walk me through the last time this came up."
"Wouldn't it be great if…?"	A leading question that contaminates the answer.	"What's the most frustrating part of doing this now?"
"Don't you hate when…?"	Puts words in their mouth and confirms your bias.	"Tell me about the last time that happened."

The common thread among the bad questions is that they all seek agreement with something you already believe. Any question fishing for validation fails the Mom Test. The good versions all do the opposite: they hand the person a blank space and let them fill it with their real experience. Replace "would you" with "did you," and replace opinions with events, and you turn agreeable noise into data you can build on.

How do I tell a real signal from a polite compliment?

You tell them apart by what the person has actually committed, because real validation comes in one of three currencies, time, reputation, or money, and compliments come in none of them. "I love this" costs the speaker nothing, so it proves nothing. A commitment costs them something, so it means something.

The three currencies of a real signal:

• Time. They schedule a real working session with you, agree to test something, or block out an hour to dig into the problem. Spent time is evidence.
• Reputation. They introduce you to their boss, their team, or a peer with the same problem. Putting their name on the line is a strong signal.
• Money. They pre-order, put down a deposit, or commit to a pilot. Money before the product exists is the strongest signal there is.

Alongside commitments, weigh the evidence of existing behavior: an active workaround (a spreadsheet, a manual process, a contractor) and real past spend both prove the pain is real without any prediction required. When you synthesize your interviews, count these facts, not the number of people who said your idea sounded nice. A stack of "that sounds useful" responses can all point the wrong way at once, because compliments are free and people give them freely. If you asked about the past and found eight people already paying to solve the problem badly, you have something real, even if none of them ever said "I'd use your product." Facts over forecasts, every time.

Why shouldn't one person run all the interviews?

You shouldn't let a single person run and interpret every interview because it hands that person an unchallengeable trump card, they can win any product argument by claiming "it's what the customer wants." Customer conversations are open to interpretation, and one interpreter for the whole team is a single point of bias.

The problems this creates:

1. An imbalance of power. Whoever owns the interviews owns the narrative, and no one else can check it against what was actually said.
2. Uncorrected interpretation. Every conversation gets filtered through one person's assumptions, and their blind spots become the team's blind spots.
3. Lost nuance. A takeaway summarized secondhand loses the specific stories, the emotional signals, and the exact wording that make discovery useful.

The fix is to share the load and compare notes. Have more than one person conduct interviews, and decide together, before you start, what your top three questions are. That way the findings are triangulated across several listeners rather than funneled through one, and the patterns you act on are ones the whole team actually heard.

---

This closes Stage 2 of the Forgex SaaS Growth System, customer discovery. Next week: demand validation, how to prove people will actually act, sign up, and pay, before you build anything, and why a smoke-test landing page beats another round of interviews.