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.

A common misconception is that user research involves asking customers to design the product. This is wrong. The process is a clear division of labor: customers articulate their problems and pain points. Your team's role is to then use its expertise and resources to devise the best solution.

Treat customer conversations like coded messages. Create a "translation guide" by categorizing every statement into three buckets: their core goal (demand), the tools they use (supply), and random noise (irrelevant). This structure reveals what they'll actually pay for.

Customers use the same words and grammar as you, but the meanings are often different. This creates a dangerous illusion of understanding, leading you to build the wrong product. You must actively translate their language, which is a mix of demand, supply, and noise.

While customer feedback is vital for identifying problems (e.g., 40% of 911 calls are non-urgent), customers rarely envision the best solution (e.g., an AI voice agent). A founder's role is to absorb the problem, then push for the technologically superior solution, even if it initially faces resistance.

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.

Customers frequently complain about their current tools (e.g., "We're struggling with Salesforce"). Founders mistakenly interpret this as a request for a direct alternative. This is a trap. The real demand is the underlying job they're trying to do, which the tool is failing to support.

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.