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.

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.

The goal of asking questions isn't just for you to gather information. It's a Socratic dialogue designed to help stakeholders think differently and arrive at the real need themselves. By guiding their thought process, you build deeper alignment and co-create a better solution, rather than just extracting requirements for yourself to fulfill.

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.

Clients often provide solutions disguised as requirements, like "we need an 8-hour battery." By questioning the context—how, where, and for how long the product is actually used—you can uncover the true need. This can lead to a radically different, simpler, and more elegant solution that better serves the user.

Resist the instinct to explain what a feature is and does. Instead, first explain *why* it was built—the specific business problem it solves and why that's relevant to the prospect. This framing turns a feature walkthrough into a personalized 'test drive'.

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.