Problem Interviews for Technical Founders in Plain English

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

What They Are

A conversation. You sit down with an engineer 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. No special equipment. No certification. No methodology. If you have ever genuinely asked a colleague how the on-call rotation 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 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 technical 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 internal to help with this?

That is genuinely the whole interview. Everything else is follow-up 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 engineer in fantasy mode. Fantasy mode is unreliable. Story mode about specific past incidents is reliable. Stick with story mode.

Where You Find People

Wherever the engineers who have the problem already hang out. LinkedIn for senior engineers and managers. X / Twitter for visible practitioners. Niche Slack and Discord communities. GitHub for open source contributors. Cold email for B2B operators when you can demonstrate you understand their world.

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. Mechanism not exotic. Just asking.

What You Do With the Notes

You read them. After every five interviews, you read all five back-to-back. Look for things that came up more than once. Same workaround. Same trigger. Same exact phrase. Same internal tool. 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 user? What is the problem? What do they do about it now?

If you can, stop interviewing and start building the smallest version that helps. 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 engineers. Ask about specific past incidents. Do not pitch and do not solution. Take notes. Look for repeats. Stop when you can summarize the user in three sentences. Then build the smallest thing that helps.

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