Problem Interviews

You've got a solution your team believes in. But when you're honest about it, nobody's confirmed that the problem it solves is real, frequent, or painful enough to make people change.

Problem interviews are a Lean Startup validation technique. You talk to potential customers about their context, workflow, pain points, and existing workarounds — deliberately avoiding any discussion of your solution.

The discipline of not pitching solutions is surprisingly difficult; interviewers naturally want to test their ideas. That restraint is exactly where the technique earns its keep. Problem interviews reveal whether people actually experience the problem, how they currently address it, and whether they care enough to switch.

Reach for them before investing in solutions — they surface problems that are frequent, intense, and currently unaddressed. The failure mode is subtle: asking about the problem while steering toward your preferred answer, which gives you confirmation without insight. Without clear problem hypotheses going in, the conversations drift and you'll leave with anecdotes instead of evidence.

Your next move: Could you describe how five real customers currently solve the problem your product addresses — without inventing the answer in the next meeting?

What it looked like for them

Outbox, 2012–2014. Outbox intercepted physical mail, scanned it, and delivered a digital version. The founders had solved hard logistics problems — interception at scale, secure scanning, privacy compliance. They'd built something genuinely clever.

What they hadn't done was sit with customers and ask about the problem they were solving. People who still received physical mail weren't suffering from it. They tolerated it. The amount they'd pay to make it go away was well below the cost of the operation.

The founders' post-mortem names the moment: every customer conversation had been with people who liked the idea of the product, not people who desperately needed it.

A problem interview — the kind that asks about the customer's current workflow, existing workarounds, and tolerance for pain — would have surfaced this before the infrastructure was built. Liking and needing are different things. Problem interviews exist to find out which one you're looking at before you commit.