The solution trap
Before describing how this phase is executed, we need to talk about an invisible force that sabotages most discovery processes: the unstoppable urge to jump to solutions.
It's an almost physiological mechanism. The human brain isn't designed to sustain the discomfort of an open problem. When we hear a problem, our mind starts generating solutions automatically, often before the other person has finished speaking. In a professional context, this urgency is amplified by deadline pressure, the culture of fast execution, and the belief that value is measured by what you produce, not by what you understand.
This urgency is the solution trap. And it's the number one enemy of good discovery.
The trap works like this: someone describes a symptom ("our team wastes too much time searching for information"), your mind instantly constructs a solution ("they need an internal AI-powered search engine"), and from that moment on, everything you hear is filtered through that solution. Interviews become validation. Questions are oriented to confirm. Data that doesn't fit is discarded. It's not bad faith. It's the normal functioning of a brain seeking certainty in an environment of ambiguity.
The antidote is not trying not to think about solutions. That's impossible. The antidote is making the solution your mind generated explicit — writing it down, putting it on paper, hanging it on the wall — and then doing the deliberate work of seeking evidence that contradicts it. Not that confirms it. That contradicts it.
The scene: In a kickoff meeting, the operations director says: "We need an AI tool to automate monthly reports. Our team loses an entire week each month preparing them."
What the team hears: "We need to build an AI report generator."
What a rigorous discovery uncovers: The team doesn't lose a week preparing reports. They lose three days collecting data from seven different systems that don't talk to each other, and two days formatting that data into the template that management requires. The problem isn't report generation. It's data fragmentation and an inherited format that nobody has questioned in five years.
The solution changes completely when the problem is defined correctly.
How to detect it: The proposed solution looks suspiciously like the first idea someone said in the kickoff meeting. The Problem Statement describes a symptom ("the team wastes time making reports") instead of the real gap between the current and desired situation.
How to prevent it: Before accepting the problem formulation, apply the 5 Whys test. If the problem description contains an implicit solution ("we need an X that does Y"), destroy it and reformulate in terms of the gap. The gap never contains the words "we need."