Problem Interviews for Technical Founders Without Overengineering It

Technical founders have a particular failure mode when they decide to take problem interviews seriously. They build a research system. Notion database. Tagged transcripts. Auto-summarization scripts. By the time the system is ready, the actual interviewing has not started yet.

This post is the antidote. The lightweight version stripped down to the parts that earn their place.

Five Calls, Three Questions, One Notebook

That is the entire system. Find five people who plausibly have the problem. Bring three open-ended story prompts. Take notes in a single doc. Run another five next week. After ten you will see patterns. After fifteen you can summarize the customer in three sentences.

That is enough to stop interviewing and start building. No research stack required.

What You Can Skip

Skip the tagging taxonomy. Skip the persona doc. Skip the affinity diagram. Skip the customer journey map. Skip the AI summarizer. Skip the Notion database with seventeen properties. None of those are bad in principle. They are infrastructure for teams running thirty interviews a week. You are running five.

You can also skip the discussion guide longer than three lines. The script is: open with a no-pitch intro, ask the three questions, follow up with "tell me more about that," thank the person. That is the whole script.

What You Cannot Skip

You cannot skip the calls. The whole reason research stacks exist is to scaffold the calls, and the calls are where the value lives. No scaffolding can replace doing them.

You also cannot skip writing things down. Even minimal notes - direct quotes, a one-paragraph summary, the trigger event, the workaround - are non-negotiable. Patterns evaporate fast. Notes that fit on half a page per call are enough.

Engineering-Brain Reframe

If you need a frame that lets you take this seriously: treat the round as input gathering for an API you have not designed yet. The user is the caller, the trigger event is the input event, the workaround is the current degraded handler. You would not write production code without knowing those three. The interview round produces them.

Spec gathering does not need a framework. It needs five conversations and a doc.

When Heavier Tooling Earns Its Place

Past about thirty interviews across multiple audiences, lightweight breaks. You will not remember which segment said what. Patterns within a segment will collide with patterns across segments. At that point, add tags. Add a small spreadsheet with one row per call. Add a weekly sync if there is more than one of you.

The infrastructure should follow the volume, never precede it. Adding it before you need it is procrastination dressed as rigor.

The Honest Output

The smallest defensible output of the round is a paragraph that names the customer, the trigger event, the workaround, and the one-sentence direction the next build should take. If you can write that paragraph after fifteen calls and have it survive a sanity-check call with one of the interviewees, you got what you came for.

If you cannot, do five more calls and try again. The fix is more interviews, not better tooling.

The Real Trade

Five calls a week for three weeks. About ten hours total, including notes. At the end you have warranted confidence about who to build for and what to build first.

That trade is wildly favorable for technical founders, and it stays favorable specifically because you did not let it become a project. Keep it small. Run it. Then build.