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.

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.

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.

Avoid the trap of building features for a single customer, which grinds products to a halt. When a high-stakes customer makes a specific request, the goal is to reframe and build it in a way that benefits the entire customer base, turning a one-off demand into a strategic win-win.

When designing for kids, the founder learned not to take feature requests literally. A child asking for a bike basket to hold rocks isn't just asking for a rock holder; they're expressing a deeper need for a versatile container for their adventures. The key in user research is to infer the underlying problem from their specific examples.

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.