Problem Interviews Without Overengineering (Non-Technical Founders)

Non-technical founders sometimes hesitate on problem interviews because the methodology content feels overwhelming. Five-page interview guides. Tagging systems. Notion templates. Affinity diagrams. If you read enough of it, you will conclude that doing this properly takes a research team and a quarter.

It does not. For a non-technical founder with no team and no time, here is the lightweight version.

Five Calls, Three Questions, One Notebook

The whole system. Find five people who plausibly have the problem. Bring three open-ended questions. Take notes in a single doc or notebook. Repeat next week with five more.

Enough to start seeing patterns. You do not need a research stack. You do not need a Notion database with eighteen properties. You need momentum and honest listening.

The Questions

You can write your own, but if you want a tested set, use these.

One: tell me about the last time this came up for you - what were you trying to do, and what happened?

Two: what did you try to make it better? Did anything work?

Three: have you ever paid for or built anything to help with this?

That is enough. Each one is a story prompt. None mention your product. From those three, you can usually get thirty minutes of useful conversation just by asking follow-ups.

The Notebook

One doc. Date at the top. Name and role of the person. Direct quotes when they say something specific. A short summary at the bottom. The single most overengineered part of most interview processes is the notetaking, and it usually delivers the least extra value.

If you find yourself building a tagging taxonomy for your interviews, you are procrastinating. You only need to tag things if you are doing dozens of them and need to retrieve patterns later. For five or ten interviews a week, plain notes are enough.

Where to Find People

For non-technical founders, sourcing is often the scariest part. It does not need to be elaborate.

Send fifteen polite, short, honest messages on LinkedIn or in a relevant community. Tell them you are researching how people handle X right now and ask for thirty minutes. Promise no pitch. Be specific about why you are asking them. Some will say yes. That is your interview pipeline. The mechanism is just asking, repeatedly, kindly, briefly.

What You Can Skip

You can skip the discussion guide. You can skip the persona definitions before you start. You can skip building a CRM for interview subjects. You can skip the post-interview synthesis workshop. You can skip the affinity mapping. You can skip the heatmap of pain points. You can skip almost everything that turns up when you Google "how to run customer discovery."

None of that is useless in principle. It is heavy infrastructure for a first-time founder who has not yet done the basic thing, which is sit down with five strangers and listen.

What Not to Skip

Do not skip the discipline of not pitching. Do not skip the discipline of writing down what people actually said in their own words. Do not skip the discipline of doing five interviews even when the first two seem to confirm everything you hoped.

Those three habits are the entire engine. The frameworks are scaffolding around the engine, useful when you are running thirty interviews a week with a team, mostly noise when you are doing five with no team.

When to Add More Structure

You will know when to add more structure because the work itself will demand it. If you are doing twenty interviews a week and cannot remember which themes came from which call, add tagging. If you are talking to multiple distinct audiences, split your notes by segment. If insights are getting lost between you and your co-founder, add a shared synthesis doc.

The structure should follow the volume, not precede it. Non-technical founders fail at problem interviews not because they were not rigorous enough but because they did not do enough of them. Keep it lightweight. Do more of them. Add structure later, if and when it earns its place.