Generic discovery questions like "what's your pain point?" yield generic answers. A better question is, "If you hired someone to sit next to you, what would you have them do?" This reveals the tedious, unglamorous tasks that are ripe for an automation-focused product solution.

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.

To get unbiased user feedback, avoid asking leading questions like "What are your main problems?" Instead, prompt users to walk you through their typical workflow. In describing their process, they will naturally reveal the genuine friction points and hacks they use, providing much richer insight than direct questioning.

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.

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.

Early demos shouldn't be used to ask, "Did we build the right thing?" Instead, present them to customers to test your core assumptions and ask, "Did we understand your problem correctly?" This reframes feedback, focusing on the root cause before investing heavily in a specific solution.

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.

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.