Customers suggest features (supply) they believe will solve their problem. Your job is to ignore their proposed solution and investigate the underlying struggle (demand) that prompted the request. This prevents over-engineering and building features that miss the mark.
Asking "why" a customer wants a feature keeps the conversation in "supply land," as they'll justify their proposed solution. Asking "when" or "what was going on" forces them to tell a story, revealing the real-world context and underlying demand.
Each feature built without understanding the core demand adds to the product's surface area. This bloat isn't a one-time cost; it's a recurring tax that complicates maintenance and slows all future development, compounding over time.
To prevent teams from defaulting to supply-side thinking (building features), embed demand discovery into your documentation. Start every product requirements document by defining the customer's situation and the 'project' on their to-do list before ever proposing a solution.
Don't just show a mockup and ask if a customer would pay. Instead, offer to solve their problem immediately as a paid service. This tests if the demand is strong enough for them to part with money for a solution, not just a future product, providing immediate revenue and invaluable insight.
Don't assume a customer's proposed solution is the right size. Often, a much smaller, elegant solution can perfectly address the underlying demand. Basecamp replaced a complex 'permissions' feature request with a simple warning dialog, solving the core problem with a fraction of the effort.
A customer telling sales "I'll buy if you build X" is just another feature request, not a validated demand signal. It's crucial for product teams to intervene and investigate the underlying "why" behind the request. Otherwise, the roadmap becomes dictated by one-off customer solutions, leading to product bloat.