A Practical Guide to Problem Interviews for Technical Founders

This is the pillar guide for technical founders running their first round of problem interviews. It is engineering-flavored on purpose. The framing treats the round as input gathering for a system you have not yet designed, with the same rigor you bring to any other spec.

If you read all the way through, 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: backend engineers at companies between fifty and three hundred people who shipped a production incident last month. Devops leads at startups under twenty engineers who run their own on-call rotation. Be that specific.

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 technical audiences: LinkedIn search filtered by title and company size, X / Twitter for visible practitioners, niche Slack and Discord communities, GitHub for open source contributors, and 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 pitch. Do not include a deck. Do not include a Loom.

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 of them 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 teams 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.

Step Five: Capture Vocabulary, Not Paraphrases

Engineers tend to take notes in their own words. Resist. 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 docs, your sales motion.

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 internal tool. 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 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

Solutioning out loud. The interviewee hears your idea and politely engages with it. Conversation contaminated. Fix: write your design ideas in private notes, not into the call.

Stack-listing instead of workflow-tracing. Asking about tools rather than incidents produces decorative data. Fix: ask about specific past events, not setups.

Talking to your old colleagues. Friendly samples produce friendly data. Fix: target by audience filter, not by network.

Stopping at three. One sample is not validation. Get to ten before drawing any conclusion you bet a quarter of work 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 to learn a tool, not a real launch attempt.

Most technical founders are in neither case and assume they are in the first. The fix is to test the assumption. Run a week of interviews. If they surface nothing surprising, you might genuinely be exempt. If they surface anything at all, you were not.

The Trade

Twenty-five to thirty hours of work 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.

The alternative is making up the spec and finding out by launching. That is the more expensive test. Do the cheaper one first, place the bet better, and let the engineering you are good at compound on a target you actually got right.