The Simplest Way to Think About Problem Interviews for AI SaaS

Problem interviews have accumulated a lot of ritual. Books, frameworks, question templates, ongoing debate about the correct way to run them. For AI SaaS teams who just want to know whether they are building something people will actually pay for, most of that noise is a distraction. Here is the stripped-down version: what problem interviews are, what changes for AI products, and how to run one without a methodology degree.

Strip Away the Method

A problem interview is a structured conversation with someone who has the problem you want to solve. You are not pitching. You are not demoing. You are not even asking whether they would use your idea. You are asking them to describe what their life actually looks like around the pain you think exists.

The reason teams overcomplicate this is that they want certainty. They layer on methodology hoping that enough rigor will produce a clear yes or no they can act on. It will not. Problem interviews reduce uncertainty — they do not eliminate it. The faster you accept that, the simpler the whole process gets.

Think of it as listening with intent. Your job is to understand the current state of the world for someone who has the problem you care about. Not to evaluate your idea. Not to collect market data. To understand what is actually happening, in specific terms, for a specific person.

What Changes for AI SaaS

For traditional SaaS, problem interviews surface friction. People describe a slow process, a manual step, a workflow that breaks at scale. You are looking for time wasted or money lost. That is still true for AI SaaS, but there is an additional layer worth knowing about.

People often cannot describe what they want from AI because they have no clear reference point for what AI can actually do in practice. This creates a specific trap. If you ask an operations manager whether AI could help them summarize meeting notes, they will say yes. If you ask whether that is actually a painful problem, they might say yes too. Neither answer tells you whether the problem is bad enough to pay to fix, or whether they are already handling it in ten minutes with a Google Doc.

The question that matters is not whether AI could theoretically help with something. The question is what currently happens that causes actual damage, delay, or cost — and what the person has already tried to do about it. That question applies whether your solution involves AI or not.

The Three Questions That Do Most of the Work

You do not need a twenty-item interview guide. Three question categories carry most of the useful signal:

• Tell me about the last time this actually happened. You want a specific story. Not what usually happens. What happened last week. Specific stories surface the operational details that general answers always bury.
• What did you do about it? This surfaces the real competition — not necessarily other software. Could be a spreadsheet, a contractor, a workaround that mostly works, or simply ignoring the problem entirely.
• How much does that cost you, roughly? Time, money, opportunity, frustration. Make it concrete. If they cannot estimate this without much thought, the problem probably is not painful enough to justify a product.

Everything else in the conversation is either warmup or follow-up to one of these three. Keep returning to them when the conversation drifts.

What You Do with the Answers

After five or six conversations, patterns emerge. The pattern is usually in the workaround. If three people independently describe the same messy fix and each estimates it costs them something real, that is your signal. If half the people say the current tool handles it fine, the problem is weaker than you thought and you need to either narrow the audience or reconsider the problem entirely.

The pattern also shows up in vocabulary. People who share the same problem describe it in similar language, often reaching for the same phrases unprompted. That language is one of the most practical outputs of problem interviews. It belongs on your landing page, in your onboarding copy, in your support docs. Copy borrowed directly from interviews converts better than copy written in a brainstorm.

How to Keep the Process Simple

You need three things to run problem interviews: a calendar link, a short outreach message, and a rough question list. The message should say something like: "I am researching how teams handle X. No pitch. Thirty minutes to walk me through how you currently deal with it?" Post it in communities where your target audience lives. Send it on LinkedIn. Ask for introductions from people you already know.

Your question list should map to the three categories above, customized for your specific problem space. You do not need a word-for-word script. You need to be comfortable sitting in silence after someone answers, because the second thing they say after a pause is almost always more useful than the first thing they said.

Take notes on exact words, not your interpretation of what they meant. A shared doc works fine. A voice recording you transcribe later works fine. The format matters less than capturing the actual language people use to describe their situation.

The Bottom Line

The simplest way to think about problem interviews for AI SaaS is this: before you build features, confirm that the problem they solve is real, that it hurts enough for someone to pay to fix it, and that they do not already have a solution that works well enough. The interview is how you find that out.

Five conversations will not make you certain. Ten will make you less uncertain. Fifteen will usually rearrange your assumptions enough to save you months of wasted build time. The methodology is secondary. What matters is doing the conversations before you build, not after something launches and nobody shows up.