Problem Interviews in Plain English (First-Time Founder Guide)

Strip out the framework names. Strip out the methodology jargon. Here is what problem interviews actually are, in language a person can use without studying first.

What They Are

A problem interview is a conversation. You sit down with someone who has the problem you are thinking about. You ask them to tell you stories about that problem. You listen. You write things down.

That is it. There is no special equipment, no certification, no script you have to memorize. If you have ever genuinely asked a friend how their week went and meant it, you have already done a worse version of a problem interview. The professional version is a little more disciplined. That is the only difference.

Why You Do Them

Because building anything is expensive, and building the wrong thing is even more expensive. The cheapest way to find out if you are about to build the wrong thing is to talk to a few people first. Thirty minutes per conversation, ten conversations, and you have spent five hours of your life learning whether the next three months of building are aimed at a real target.

Most first-time founders will not spend the five hours. They will spend the three months. The math is bad and the regret comes later.

What You Ask

Three things, mostly. Tell me about the last time this came up for you. What did you try? Have you ever paid for or built anything to help with this?

That is genuinely the whole interview. Everything else is just follow-up questions to those three. "Tell me more about that." "What happened next?" "Why did that not work?" "How long did that take?"

What You Do Not Ask

You do not ask if they would buy your product. You do not ask if they would use a tool that did X. You do not ask what features they want.

Those questions sound useful and are not. They put the customer in fantasy mode. Fantasy mode is unreliable. Story mode about the past is reliable. Stick with story mode.

Where You Find People

Wherever the people who have the problem already hang out. LinkedIn for professionals. Reddit for hobbyists. Niche Slack and Discord communities for specific roles. Twitter for tech people. Email for B2B operators.

Send a polite three-sentence message. Tell them you are doing research, you are not selling, and you would love thirty minutes. Some will say yes. The mechanism is not exotic. It is just asking.

What You Do With the Notes

You read them. After every five interviews, you read them all back-to-back. You look for things that came up more than once. Same workaround. Same trigger. Same exact phrase. Those are your patterns.

If five out of ten interviews told you the same story, that story is real. If only one of ten told you that story, it is interesting but not enough to bet on.

When You Stop

When you can answer three questions in one sentence each. Who is the customer? What is the problem? What do they do about it now?

If you can, stop interviewing and start building the smallest version that helps with the answer. If you cannot, do five more interviews. There is no exact magic number. The signal is how clearly you can summarize what you have heard.

Plain English Summary

Talk to the right people. Ask about their actual past. Do not pitch. Take notes. Look for repeats. Stop when you can summarize the customer in three sentences. Then build the smallest thing that helps.

That is the whole practice. Anything more elaborate is decoration. Anything less is guessing.