The Simplest Way to Think About Problem Interviews (Technical Founders)

If you are technical and bouncing off the soft methodology framing, here is the engineering version. Treat problem interviews as input gathering for a system you have not yet designed. The system is the product. The inputs are the human variables that no doc captures.

The Mental Model

You would not write production code without knowing the input shape. Problem interviews are how you discover the input shape on the human side. They produce three things: who the user is, what triggers the relevant behavior, and what the current degraded process looks like.

You would not commit to an API design without knowing what callers actually want to do with it. Same logic for product design. The interviews are the API discovery phase. The build is the implementation.

The Three Inputs You Need

One: the user's identity. Specific role, specific organization size, specific recent behavior. This is your audience filter, equivalent to the type signature on your function.

Two: the trigger event. The specific moment in their day or week when the problem shows up. This is the input event your system has to react to.

Three: the current handling path. The workaround they use today. This is your competition - even if it is not a product, it is the path of least resistance for this user.

If you do not know all three after your interview round, you are missing required parameters. The build will compile but it will not solve anything for anyone.

The Anti-Pattern Engineering Brains Love

Technical founders often try to skip the interviews by writing the spec themselves. They imagine the user. They imagine the workflow. They write a thorough internal doc and start building.

This is the equivalent of mocking your own data and calling that a system test. It works against the data you invented, not against the data the real world produces. The bug shows up when real data hits the system. By then, you have committed to an architecture shaped by your invented data.

What "Spec Gathering" Actually Looks Like

Three open-ended questions, run on ten to fifteen people who fit the audience filter. The questions are story prompts about the past, not opinions about the future.

One: walk me through the last time this came up for you. Two: what did you try, and what worked or did not? Three: have you ever paid for or built anything to help with this?

You take notes that include exact phrases. After every five interviews, you reread the previous five. You look for things that came up in three or more. Those are your inputs.

The Output of the Round

By interview fifteen, you can write a one-paragraph spec that includes: the user, the trigger event, the current workaround, the cost they pay for the workaround, the vocabulary they use to describe the problem, and the smallest version of a better solution.

That paragraph is your spec. The build is implementation. You will still have engineering decisions to make - the spec does not write the code - but you are no longer making them in a vacuum.

The Failure Modes

Pitching during the call. This is the equivalent of leaking your test data. The user starts answering questions about your hypothesis instead of describing their actual world.

Asking about the future. "Would you use this" is asking the user to invent data, and they will invent data that pleases you. Useless.

Talking to the wrong sample. Interviewing five entrepreneurs about an accountant problem produces information about entrepreneurs, not accountants. Garbage in, garbage out.

Stopping at three calls. One call is a single sample. Patterns require ten or more. You would not test a system on three inputs. Same here.

Why This Framing Works for Engineering Brains

Treating problem interviews as spec gathering removes the soft-methodology framing that makes technical founders bounce. It positions the work as a known-good engineering practice applied to a different layer of the system. Same rigor, different inputs.

Most technical founders who get past their initial resistance to interviews do so by adopting this framing. The activity is the same. The reframe is what makes it tractable.

The Net Trade

Ten to fifteen calls. Two to four weeks. Notes in a single doc. Inputs gathered. System designed against real shape. Build proceeds with materially better odds of producing a useful product.

The alternative is making up the inputs and finding out by launching. That is the more expensive test. Spec gathering is cheaper, even when it feels slower.