Asking users for solutions yields incremental ideas like "faster horses." Instead, ask them to tell detailed stories about their workflow. This narrative approach uncovers the true context, pain points, and decision journeys that direct questions miss, leading to breakthrough insights about the actual problem to be solved.

Users aren't product designers; they can only identify problems and create workarounds with the tools they have. Their feature requests represent these workarounds, not the optimal solution. A researcher's job is to uncover the deeper, underlying problem.

During customer discovery, don't just ask about current problems. Frame the question as, 'If you had a magic wand, what would the perfect solution be?' This helps users articulate their ultimate desired outcome, revealing profound insights beyond tactical feature requests.

Customers request specific features (supply), but this masks the true demand—the underlying problem they're trying to solve. Focusing on the 'why' behind the request leads to simpler, more effective solutions, like building a digest email instead of a complex 'advanced settings' page.

When customers talk, trust their articulation of what they're trying to accomplish (demand) and why their current tools fail (supply problems). However, completely disregard their suggestions for what product or feature you should build (supply they want). That is your job to design, not theirs.

When handed a specific solution to build, don't just execute. Reverse-engineer the intended customer behavior and outcome. This creates an opportunity to define better success metrics, pressure-test the underlying problem, and potentially propose more effective solutions in the future.

Directly asking customers for solutions yields generic answers your competitors also hear. The goal is to uncover their underlying problems, which is your job to solve, not theirs to articulate. This approach leads to unique insights and avoids creating 'me-too' products.

Customers often suggest solutions (e.g., "add this feature") based on their limited understanding of what's possible. A founder's job is to look past the specific request and identify the core problem or desired outcome. Building exactly what the customer asks for verbatim is a mistake; solving their underlying goal is the key.

When users request a specific feature, like an API, don't take it at face value. Ask 'why' to uncover the underlying job-to-be-done. The user's goal might be a centralized view of comments, which can be solved with a dedicated feed—a much simpler solution than building a full API.