A Practical Guide to Problem Interviews for Non-Technical Founders

This is the pillar guide for non-technical founders running their first round of problem interviews. The framing is intentionally non-technical: customer conversations are one of the few founder activities where being non-technical is not a disadvantage, and may even be an advantage. Read all the way through and you will have everything you need to start the round this week.

Step One: Define the User by Two Filters

Before any outreach, define the user. Two filters: a job-or-role and a recent behavior. Examples: course creators who launched a paid course in the last twelve months. Operations leads at agencies under twenty people who manage their own client status reports. Solo SaaS founders who shipped a product this year.

Two filters is the whole spec. Anything looser produces noisy data. Anything tighter is hard to reach.

Step Two: Reach Fifteen of Them

Plan to land fifteen calls. Reply rates of 25 to 40 percent are normal, so plan to send 40 to 60 messages.

For non-technical audiences: LinkedIn search filtered by title and company size, niche communities (Indie Hackers, course creator Slacks, agency Slack groups), Reddit subreddits matched to the topic, Twitter for visible practitioners, well-targeted cold email when you can demonstrate familiarity with their work.

The message is three sentences. One on why specifically them, one on what you are researching and that you are not selling, one asking for thirty minutes. Do not include a deck. Do not include a Loom of your no-code build.

Step Three: Build a Three-Question Spine

Three story prompts about specific past events. The rest of the call is follow-up.

Question one: walk me through the last time this came up for you. What were you trying to do, and what happened?

Question two: what did you try? Did anything work?

Question three: have you ever paid for or built anything yourself to handle this?

That is the entire interview. Each question is a story prompt. None mention your product. The follow-up question that does most of the work is "tell me more about that."

Step Four: Run the Call

Open with a low-stakes intro. "Thanks for the time. I am researching how people handle X right now, I am not selling anything today, I just want to learn from people who have lived through it." That sentence does a lot of work. It signals no pitch, lowers their guard, and frames them as the expert.

Ask question one. Then shut up. After every answer, count to three before responding. That silence often produces the most useful sentence of the call.

If they ask what you are building, deflect: "Still figuring it out, that is why I am asking these questions. Can we come back to that at the end?" They will say yes. Save the description for the last three minutes if at all.

Do not apologize for being non-technical. It is not relevant to the conversation. The interviewee will not notice or care.

Step Five: Capture Vocabulary, Not Paraphrases

When the interviewee says something specific or vivid, write it in quotes. The verbatim phrasing is half the value of the round. It will end up in your landing page, your sales emails, your onboarding copy.

After the call, spend five minutes writing a short summary. Three things: what was the trigger event, what did they actually do, what surprised you. The third one is most important. If nothing surprised you, you might not have been listening hard enough.

Step Six: Synthesize Every Five Calls

Reread the previous five sets of notes back-to-back. Look for repeats. Same trigger event. Same workaround. Same vocabulary. Same complaint.

Patterns are signal. Idiosyncrasies are interesting but not actionable. After fifteen calls you should be able to write one paragraph that names the user, the trigger, the workaround, and the smallest version of a better solution.

Step Seven: Decide What You Have

Three questions. Is the problem real, frequent, and painful enough that people are already doing something ugly to handle it? Is the user reachable - did they take your call and would they take a follow-up? Is the workaround expensive enough in time, money, or stress that something better could plausibly earn money?

If yes, yes, and yes: build the smallest possible version (no-code, contractor, or agency) and put it in front of the same fifteen people. If any of those is no, you have learned something equally valuable. Adjust your filter or your direction.

Common Failure Modes

Apologizing for being non-technical. Not necessary. Not helpful. Skip it.

Demoing a no-code build during the call. The audience reacts to your build, not their own world. Save demos for a separate later call.

Asking about the future. "Would you pay for this?" produces fantasy data. Ask about the past instead.

Talking to friends. Friendly samples produce friendly data. Find strangers.

Stopping at three. One sample is not validation. Get to ten before drawing any conclusion you bet money on.

When You Should Skip This

Two cases. One: you are the user, you have lived in this problem for years, your gut already encodes what the round would surface. Two: you are running a one-week throwaway prototype as a learning exercise.

Most non-technical founders are in neither case and assume they are in the first. Test the assumption: spend a week running interviews. If they surface nothing surprising, you might be exempt. If they surface anything at all, you were not.

The Trade

Twenty-five to thirty hours over two to four weeks. At the end, you have a one-paragraph spec grounded in real conversations and a list of fifteen people to launch to. The build that follows is narrower, more focused, and aimed at things real users said.

For a non-technical founder, this trade is especially favorable. The build is the part that costs real money. The interview round is the part that does not. Doing the cheap thing first and aiming the expensive thing better is exactly the playbook your situation rewards. Run the round. Then build.