Problem Interviews: Capturing Real B2B Evidence

Anchoring Conversations in Observable Facts

When speaking with business stakeholders, it is easy to fall into the trap of abstract speculation. People often praise concepts out of polite interest when no commitment is required. To make an interview truly informative, anchor the discussion in verified work routines and concrete experiences rather than vague predictions about the future.

In public Y Combinator lectures on talking to users, the advice is to listen actively and explore specific past experiences, because hypothetical praise never substitutes for factual behavior.

What Questions to Ask About the Workflow

To discover whether an operational problem is genuine, examine how staff handle their recurring daily duties. Focus your inquiries on the following points:

• The latest instance: Ask the respondent to describe how the task was handled most recently, step by step.
• Current solutions: Identify which tools, spreadsheets, or manual checklists the team relies on right now.
• Operational costs: Clarify how many work hours this task consumes and what operational errors routinely occur.
• Prior attempts: Ask whether the team previously attempted to automate or fix this workflow and why those attempts fell short.

Hypothetical Example: Order Entry from Emails

Consider an explicitly hypothetical example of an industrial supplies distributor. A discovery team is reviewing how internal staff transfer incoming email orders into an enterprise resource planning system.

After speaking with the team, the researchers record a concise observation card:

• Context: The company receives approximately 80 purchase orders via email attachments daily.
• Current action: An operator opens each attachment and manually retypes part numbers, quantities, and prices into the database.
• Friction and cost: Two staff members spend two hours each day on manual entry, and occasional typos cause shipping delays.
• Workaround: Employees maintain a shared spreadsheet to double-check product codes before entering them into the main system.

Rather than building complete software, the researchers suggest an immediate low-effort test: the business provides fifteen anonymized order samples to evaluate a simple parsing script. A willingness to share sample data demonstrates initial interest, though it does not yet constitute proof of a viable market.

Checklist for Logging Evidence and Next Steps

• Ground questions in actual workplace routines and observable actions rather than speculative promises.
• Record measurable parameters: staff hours spent, headcount involved, and how often the issue arises.
• Identify whether the company has previously allocated time or budget to address the situation.
• Propose a practical next action (such as testing sample files) that requires a modest effort from the client.

Keep in mind that no specific number of completed interviews serves as universal proof of market demand. Genuine demand is proven only when customers demonstrate an ongoing willingness to alter operations, allocate real resources, and pay for a solution.