How do you know a problem is real before you build anything to solve it?

Enthusiasm is not evidence

Start by separating two claims that get merged: that a problem exists, and that your solution is wanted. Almost all bad discovery collapses the first into the second, because the second is more interesting to talk about. Once you show someone a mock-up, everything they say afterwards is a reaction to your idea rather than a report of their life, and reactions are unreliable — people are agreeable in interviews, they want the conversation to go well, and they cannot forecast their own future behaviour.

So the question you are answering in discovery is not "would you use this?" It is "what do you currently do about this, how often, and what did it cost you last time?" A problem worth building for leaves evidence behind: a workaround, a spreadsheet, a person hired to do it manually, a recurring support ticket, a competitor being paid money. If you can find no trace, the strong prior is that the problem is real but not painful enough to act on, which for product purposes is the same as not real.

Interviewing without putting the answer in their mouth

The technique is to ask about specific past episodes and let the person narrate. Anchor to the last time it happened, because a concrete memory is far more accurate than a generalisation, and generalisations are where people describe the person they wish they were.

Leading question	What it actually measures	Behavioural replacement
"Would a shared dashboard be useful?"	Politeness	"Walk me through the last time you needed this number. Where did you get it?"
"Is reconciliation painful?"	Your framing repeated back	"How long did last month's close take? What went wrong in it?"
"How often would you use this?"	Optimism	"How many times did you do it last week?"
"Do you care about speed?"	Nothing — nobody says no	"What did you do the last time it was slow?"

Two habits do most of the work. Follow every complaint with "and then what did you do?", because that reveals whether the pain was sufficient to trigger action or merely sufficient to mention. And ask what they have already tried and abandoned; a graveyard of attempted fixes is the strongest signal you will get from a conversation, and a completely empty one usually means you are the only person who thinks this is a problem.

Keep your solution out of the room until the end. If you must show something, show it after you have finished asking, and treat everything said after that point as a separate, lower-quality class of data.

The gap between saying and doing

People misreport their own behaviour systematically rather than randomly, and the direction is predictable: they overstate virtuous behaviour, understate embarrassing behaviour, understate price sensitivity, and overstate willingness to change tools. So interviews are excellent for discovering why something happens and unreliable for estimating how much. Use them to form the hypothesis and something behavioural to size it.

Sources you usually already have, costing a day rather than a sprint: in-product searches that return nothing, funnel steps where people drop and come back, features used at a frequency contradicting what users said, support tickets clustered by cause rather than by product area, and closed-lost reasons read as raw CRM text rather than as the dropdown the rep picked. Sales calls are rich with a known bias — the request has been translated by someone incentivised to promise it — so treat a sales-sourced problem as strong evidence about one account and weak evidence about the market.

The best position is when the two disagree and you find out why. If users say the export is the worst part and nobody opens the export screen, one of those is wrong, and the answer is nearly always more interesting than either input.

Then make it fail cheaply

Once the problem looks real, stop validating it and attack the riskiest assumption in your solution. Write the assumption as a sentence that can be false, attach a number, and pick the cheapest instrument that could return a no: a fake door for demand, a concierge run delivering the outcome manually for five customers for demand plus willingness to pay, a spreadsheet sent to one team for whether the workflow even helps.

State the kill criterion first. "If fewer than one in twenty who see this click through, we do not build it" is a decision; "we will see what the data says" is not. A candidate who cannot name a disconfirming outcome has never genuinely risked being wrong, which is exactly what this question is checking.

Where good candidates still lose the round

The commonest failure is confusing volume of validation with quality of it. Twelve interviews recruited from people who already like your product, all asked whether the problem is painful, produce twelve yeses and no information — every source shares one bias, so agreement between them proves nothing. One interview with someone who churned, contradicted by your funnel data, is worth more than all twelve.

The subtler failure is validating existence and never sizing. You establish the problem is genuine and painful, then solve it without asking how many people have it, how often, and what it costs them — which is how a team spends a quarter shipping a good solution to a real problem affecting two hundred users. "Is it real?" and "is it worth a team?" are two questions, and a strong answer visibly asks both. If you say only one thing about your process, say that you look for what people already spend money or effort on, because that is the one form of stated preference that has already been paid for.