Problem Interviews for Technical Founders Who Hate Complexity

Engineers tend to bounce off methodology. Mom Test, jobs-to-be-done, customer development, persona docs - the names alone make most technical founders close the tab. If that is you, here is the version stripped to the parts that actually do the work. Three rules.

Rule 1: Talk to People Who Have the Problem

Not your friends from the bootcamp. Not random Twitter followers. Not five people from your old company. Engineers who, recently, did the specific workflow you are thinking of changing.

Find them on LinkedIn by title and team size. On X by visible practitioners. In niche Slack and Discord communities. On GitHub via open source contributions. Cold message ten of them. Some will say yes. The mechanism is not exotic. The discipline is filtering for the right audience instead of the available one.

Rule 2: Ask About Past Incidents, Not Future Hypotheticals

Do not ask "would you use this." That is a question about an imagined future. Engineers are bad at it - everyone is. You will get polite garbage.

Ask "walk me through the last time this happened." That is a question about a specific past event. Engineers are good at remembering specific past events because the events cost them sleep. You will get a story. Stories carry data. Stack lists do not.

Rule 3: Do Not Pitch and Do Not Solution

Two failure modes wrapped into one rule. Do not describe what you are building. Do not propose how to fix what you are hearing. The moment you do either, the conversation tilts toward politeness and away from honesty.

If a design idea hits you mid-call, write it in private notes. The engineer should never see your hypothesis during the call. They might see it during a later solution interview. Different shape, different goal.

What That Adds Up To

Three rules. Talk to engineers who have the problem. Ask about specific past incidents. Do not pitch and do not solution.

That is enough. Run ten interviews following those three rules and you will have more useful information about your market than most first-time technical founders ever collect.

What You Can Skip

You can skip the framework names. You can skip the persona doc. You can skip the affinity map. You can skip the tagging system. You can skip the customer journey diagram. You can skip the synthesis workshop. None of those are bad in principle. They are scaffolding for teams running thirty interviews a week. You are running ten.

What You Cannot Skip

You cannot skip the calls. The reason all the methodologies exist is that the calls are the part that matters, and the methodologies are scaffolding around them. Strip the scaffolding and the calls still do the work.

You also cannot skip writing things down. Even minimal notes - a few quotes, a one-paragraph summary, the trigger event, the workaround - are non-negotiable. Patterns evaporate fast.

If You Want to Be Even Lazier

Do five calls. Just five. Use the three rules. Take messy notes. Write a one-paragraph summary at the end of each.

You will know more after five than you knew before. That is the point. You can always do more later. The biggest mistake is doing zero because the methodology felt overwhelming, not doing too few because you got tired.

The Plain English Version

Find engineers with the problem. Ask them about specific past incidents. Do not sell or design out loud. Take notes including the words they used. Repeat a few times.

That is problem interviews for people who hate complexity. The rest is decoration. If the decoration helps you, keep it. If it stops you, throw it out and just do the calls.