The Simplest Way to Think About Problem Interviews (Non-Technical Founders)

Most writing on customer discovery is full of frameworks. Mom Test, jobs-to-be-done, customer development - all useful, all overwhelming when you are a non-technical founder trying to figure out where to even begin.

Here is the simplest possible way to think about it. A problem interview is a conversation where you collect stories instead of opinions.

Stories Beat Opinions

If you ask someone "would you use a tool that helps you do X," they are answering with their imagination. Imagination is cheap. Everyone is generous with hypothetical praise.

If you ask someone "tell me about the last time you tried to do X," they have to remember an actual event. They have to describe what they actually did. They have to admit if they did nothing. That answer is real data. The first answer is theater.

That single shift, from opinion-asking to story-collecting, is the entire point of a problem interview. Everything else is just technique on top of that.

Why This Especially Works for Non-Technical Founders

You are not constrained by an engineering reflex to architect things during the call. The conversation can stay in the customer's world the whole time. You are also more likely to ask the soft, curious questions that keep people talking.

Lean into that. The interview is a place where being non-technical is actually an advantage.

Three Questions That Almost Always Work

If you are nervous about your first one, just bring these three.

One. Walk me through the last time this came up for you. What were you trying to do, what did you try, what happened?

Two. What is annoying or frustrating about how you handle it now?

Three. Have you ever paid for or built anything to make it better? What was that?

Each one is a story prompt. None mention your product. They put the person back in their own life. Your job is to listen, ask follow-ups, and write down the words they use.

What Counts as a Good Interview

Not one where they say they would buy your thing. A good interview is one where you walk away knowing something you did not know before. Maybe the problem only happens at a certain scale. Maybe the workaround they have already kind of works. Maybe they do not actually have the problem at all and you just believed they would.

All three are wins. The only bad interview is one where you spent the whole time pitching and learned nothing.

How Many Do You Need

Enough that you start hearing the same things twice. For most early ideas this means roughly ten to fifteen. After about five you will get suspicious of your own assumptions. After about ten you will start seeing real patterns. After fifteen you will know whether to keep going or pivot.

You do not need a hundred. You need enough to overwrite your own confidence.

The Mistake Almost Everyone Makes

The mistake is talking about the solution. As soon as you do, the conversation tilts. The person stops being a witness and starts being polite. They will tell you the idea sounds great, you will leave feeling validated, and you will have learned almost nothing.

The discipline is to keep your mouth closed about what you are building until the very end of the call, if at all. Many of the best problem interviews end with the founder saying, "Thank you, this was incredibly helpful," and the person on the other side never quite figuring out what the founder is actually working on. That is a feature, not a bug.

Just Start

If you have read three blog posts about problem interviews and not done one yet, the next blog post is not going to fix that. Send one message today. Ask one person for thirty minutes. Bring those three questions. Listen. Write down what they actually said.

The simplest way to think about problem interviews is the same as the simplest way to think about most founder skills. You learn them by doing them badly the first three times and noticeably better the fifth.