The Problem Interview

The Customer Is Not There to Validate You

The dangerous interview is the pleasant one. The founder explains the idea, the customer nods, everyone agrees the problem sounds real, and the notes fill with sentences that are easy to mistake for demand. No one lies. The customer is being socially generous. The founder is hearing relief.

A problem interview has a narrower job: make the customer reconstruct how the problem already behaves in their world. What happened last time? What did they do? Who got pulled in? What did they use instead? What did it cost? Who would have to approve a different approach? What event would make switching worth the disruption?

For a solo founder, this is not research theater. The interview must protect scarce build time. If it does not change what you build, fake, defer, price, or stop pursuing, it was probably a conversation, not discovery.

Recruit for the Moment, Not the Persona

Early interviews fail before the first question when the founder recruits “people who might like this” instead of people who recently lived the situation.

A useful recruit touches the work, budget, risk, or outcome. They can remember a recent episode rather than imagine a future one. Something was at stake: time, money, delay, rework, customer trust, or exposure. General interest in the category is a weak substitute for any of these.

The outreach should screen for the episode, not sell the product.

Warm outreach can be simple:

I am studying how small home-care agencies recover when a caregiver cancels a shift on short notice. I am not selling anything on this call. I am trying to understand what happens today, especially the last time it occurred.

Is shift recovery part of your work? If so, would you be open to a 25-minute conversation this week?

Cold outreach needs the same precision:

I am interviewing operations managers at agencies with 20-100 field staff about last-minute shift coverage. I am trying to understand the current workflow before deciding whether to build anything.

If you have dealt with a same-day cancellation in the past month, could I ask you a few questions about how you handled it? No pitch during the call.

Notice the promise. You are not asking for feedback on an idea. You are asking for access to a recent operational fact pattern.

Consider a fictional composite that will run through this chapter. A founder is considering an AI scheduler for small home-care agencies. The imagined product already has calendar views, staff profiles, client matching, payroll rules, notifications, and manager approvals. Before building it, the founder recruits an operations manager who handled a same-day caregiver cancellation two weeks ago. That recent cancellation—not an interest in AI or scheduling—is why this person belongs in the interview.

Give the Call a Narrow Contract

The first two minutes decide whether the call becomes discovery or a disguised pitch. Set the frame before the customer tries to be helpful.

Use a short contract:

Thanks for making time. I am trying to understand how this works today, not pitch you a product. I will ask mostly about the last real example you remember. If I drift into solution mode, I may stop myself and come back to what happened. At the end, if you want, I can briefly say what I am exploring.

Then confirm relevance:

Before we get into it, is this actually part of your work?
How often does it come up?
When was the last time it happened?

If the customer has no recent episode, do not force the interview. Ask who does. A founder with ten vague calls is behind the founder with three interviews anchored in real incidents.

If you want to record, ask permission and say how you will use and store the recording. A transcript can preserve wording, but it does not relieve you of listening. In a sensitive workflow, notes may be more appropriate than a recording. Discovery does not entitle you to customer, employee, or patient data that the participant is not allowed to share.

Rewind, Do Not Tour

The central move in a problem interview is the rewind. You are not asking the customer to evaluate your future. You are asking them to replay their past.

Start with:

Walk me through the last time this happened.
What kicked it off?
What did you do first?
What happened next?
Who else got involved?
What tools, spreadsheets, messages, or documents did you touch?
Where did it slow down or get messy?
How did you know it was resolved?

Good interviewers tolerate detail. They ask “what happened next?” until the customer reaches the end of the episode. They ask for the actual spreadsheet, message, report, checklist, or handoff when the customer is allowed to share it. They listen for names of tools and people because those details reveal product surface area.

In the shift-coverage interview, the cancellation arrived by text at 6:12 a.m. The manager checked the scheduling system, then opened a separate spreadsheet of caregiver preferences. Two caregivers appeared available, but one could not visit this client because of a past complaint. The manager spent 42 minutes texting candidates before finding coverage.

Those details are more valuable than a declaration that scheduling is painful. They reveal an urgent trigger, an official system that does not contain all the decision context, and a judgment problem hidden inside what first looked like calendar automation.

Stay with the episode, but avoid turning the call into full workflow discovery too early. The immediate job is to learn whether the problem deserves deeper mapping. Chapter 13 follows the strongest episodes into actors, inputs, handoffs, data, and trust points.

Follow the Workaround

The current workaround is the real competitor. It may be a spreadsheet, an incumbent product, a contractor, a Slack channel, a manual checklist, a trusted employee, a quarterly cleanup, or the decision to do nothing.

Ask:

What do you use today when this happens?
How long have you handled it that way?
What works about the current approach?
What breaks?
What have you tried before?
Why did that not stick?
If nothing has changed, why has this been acceptable so far?

The last question matters. Many problems are annoying but stable. Customers may complain about them for years without changing because the workaround is familiar, the pain is intermittent, the buyer is different from the user, or the perceived risk of switching is worse than the current frustration.

Do not treat the workaround as evidence against the opportunity. Treat it as the shape of reality. Your first product must beat the workaround on a dimension the customer already cares about.

For the home-care manager, the scheduling system and preference spreadsheet are only part of the alternative. The rest is memory, trusted relationships, and a burst of text messages. A product that is faster but recommends an unfamiliar or unsuitable caregiver would lose to that untidy system. The workaround has exposed a trust requirement before the founder has designed a screen.

Ask About Urgency, Budget, and Authority Without Flinching

Founders often avoid money questions because they feel premature. In discovery, money is not only price. It is a way to understand whether the pain has economic weight and whether anyone can act on it.

Ask about urgency first:

What happened because this took too long or went wrong?
Who noticed?
What would have happened if you had ignored it?
When does this become urgent instead of merely annoying?
Is there a deadline, customer promise, compliance issue, revenue risk, or executive concern attached to it?

Then ask about spend:

Have you paid for software, services, contractors, staff time, or internal tools to handle this?
How much time does your team spend on it in a typical week or month?
When it goes wrong, where does the cost show up?

Then ask about authority:

If your team decided to fix this, who would own that decision?
Who would approve budget?
Who would object?
Who would have to trust the result before it could be used?

These questions separate user pain from business opportunity. A user may desperately want relief and still have no authority, no budget path, and no permission to change the workflow. That does not always kill the idea, but it changes the next test. You may need to interview the economic buyer, find a smaller self-serve wedge, or choose a segment where the user and buyer are the same person.

In the composite interview, the coordinator feels the daily pain, but the agency owner approves software. Families lose confidence when they hear that coverage is uncertain, so the consequence reaches beyond administrative time. The staffing marketplace the agency tried did not stick because the manager distrusted unknown caregivers. The founder now has a buyer to interview and a switching barrier to investigate. Neither fact would have emerged from asking whether an AI scheduler sounded useful.

Let Contradictions Do Their Work

The most valuable sentence in an interview may be the one that damages your idea.

Contradictions sound like:

• “This is a huge problem, but we have never tried to fix it.”
• “I hate the current tool, but everyone trusts it.”
• “I would love automation, but I still need to check every output manually.”
• “The manager owns the budget, but the coordinators do the work.”
• “We only feel the pain during the last week of the quarter.”
• “We already built an internal script, but no one uses it.”

Do not argue with contradictions. Label them. They reveal hidden requirements, missing buyers, weak urgency, trust barriers, seasonality, or a segment boundary.

Use neutral follow-ups:

That seems important. Why has it stayed this way?
What makes the current approach hard to replace?
What would have to be true before you changed it?
Who benefits from keeping the current process?
What would make a new tool risky here?

A founder who ignores contradictions will build a product for the customer’s stated frustration and miss the system that keeps the frustration in place.

Do not rush to reconcile every contradiction during the call. “This is critical” and “we have tolerated it for years” can both be true. The gap may contain seasonality, a missing buyer, fear of migration, an informal control, or a pain that is vivid but too rare to support a product. Keep the tension visible until more evidence explains it.

Carry One Interview Card

Do not read a script like a questionnaire. Use one card as a spine, and let the episode determine the order.

1. Frame: “I am trying to understand today’s process, not pitch a product.”
2. Screen: “Is this part of your work? When did it last happen?”
3. Rewind: “Walk me through the last time. What happened next? Who and what did you rely on?”
4. Pressure: “What happened because of it? What did it consume or put at risk?”
5. Alternative: “How do you handle it today? What have you tried? Why does the current approach survive?”
6. Action: “Who could decide to change this? What would make change worth the disruption? May I follow up with a narrow test?”

The card is deliberately short. Questions about frequency, money, authority, trust, and contradictions belong where the customer’s account makes them relevant. A fixed questionnaire encourages the founder to complete the script instead of understanding the episode.

If the customer asks what you are building, do not be evasive. Answer briefly near the end:

I am exploring whether there is a narrow way to reduce this recovery work. I am intentionally not showing a product yet because I do not want the idea to distort what I learn. Based on what we discussed, what would make an approach like that fail in your environment?

That last question turns curiosity about your idea back into risk discovery.

Turn Notes Into Decisions

Immediately after the call, write a short interview memo while the details are fresh. Begin with the segment and the recent episode. Record the current workaround, consequence, frequency, existing spend or staff time, authority path, switching trigger, and every fact that weakens your assumption. End with a build implication and one next decision.

Tag the basis of each note. Observed means you saw an artifact or behavior. Reported means the customer described something that happened. Inferred means you interpreted what it may imply. All three can be useful, but they are not interchangeable. A vivid quote is still reported evidence; a product requirement extracted from it is still an inference.

The build implication is the discipline. “They liked the idea” is not an implication. “A manual weekly exception report could test value before integrations” is. “The user feels pain but budget belongs to a different role” is. “The problem is quarterly, not weekly, so the product may need event-based outreach rather than daily workflow software” is.

The shift-coverage memo changes the build. A full scheduler is premature. A concierge test that produces a ranked shortlist of known backup caregivers for the morning coordinator may reach the painful moment without calendar views, payroll rules, or vendor accounts. Before even that test, the founder needs to interview the agency owner about authority and map the recovery workflow closely enough to understand which preferences and trust signals make a shortlist usable.

One interview has not validated a company. It has done something more modest and more useful: it has replaced a broad product idea with a sharper uncertainty and a cheaper next move.

When You Have Enough Interviews for Now

You do not need statistical certainty before the next test. You need enough evidence to make the next product decision less imaginary.

Keep interviewing while new calls change the segment, reveal different workarounds, surface new buyers, or contradict the pain. Pause when recent episodes begin to repeat and you can name the next behavior test.

Repetition alone is not enough. If the pain is real but the buyer is elsewhere, interview the buyer. If the workaround is strong and the switching trigger rare, seek a higher-urgency segment or stop. If customers use the same label for different problems, split the segment and recruit more precisely. If enthusiasm is high but no one has spent time, money, or political capital trying to improve the situation, probe the cost of change before you build.

Interviewing can become avoidance just as coding can. The output is not a perfect research report. The output is a sharper bet with a cheaper next test.

Failure Modes

The obvious failure is pitching. The founder talks more than the customer and leaves with compliments instead of behavior.

The common failure is future-tense questioning: “Would you use this?”, “Would this help?”, “Would you pay?” These questions invite the customer to imagine a generous future self.

The subtle failure is laundering opinions into evidence. A quote is not strong because it is vivid. Strong evidence is attached to a recent event, current workaround, consequence, spend, authority path, or switching trigger.

The expensive failure is avoiding contradictions. If customers say the pain is critical but have tolerated it for years, the founder has not discovered demand. The founder has discovered an unresolved tension.

The solo-founder failure is leaving the interview without a decision. Notes that do not change action become emotional support for whatever the founder already wanted to build.

Decision Gate

A problem interview has done its job when it changes a decision. A confirmed painful episode may justify more discovery in the segment. A weak or stale episode may change recruiting or kill the assumed problem. The workaround sets the first value benchmark. The urgency trigger tells you when change is plausible. The authority path tells you who else belongs in the conversation. A contradiction may change the segment, trust model, or scope. A manual opening may let you test the value before product code.

If an interview produces none of these, fix the recruit, the opening contract, or the questions before booking more calls.

After the call, write one sentence:

Because of this interview, the next product decision is __________.

If you cannot fill in the blank, the call may have been interesting, but it was not yet useful.

Exercise

Take the product idea you most want to explain. Write a ten-question interview script without naming the product.

Every question must point to one of five things: a recent episode, a current workaround, a consequence, budget or authority, or a switching trigger. Add one explicit contradiction prompt: “What makes this hard to replace even though it is painful?”

Run the script once. Within ten minutes of the call, complete the interview memo and choose one next decision: recruit a sharper segment, interview a buyer, map the workflow, test a manual offer, build a narrow prototype, or stop.

The interview earns its place when it changes the build—not when it makes the founder feel better about the build they already wanted.