We scan new podcasts and send you the top 5 insights daily.
Customers often overvalue solutions to hypothetical problems. A feature that sounds brilliant in a demo may be ignored in practice when users are time-poor and focused on their core job. Differentiate between users' stated desires and their actual, revealed preferences.
Users often don't know what they want. Instead of direct questioning, create live prototypes or social experiments. Observing how people naturally use these tools in a real-world context provides more honest and insightful data than traditional interviews.
Customers describe an idealized version of their world in interviews. To understand their true problems and workflows, you must be physically present. This uncovers the crucial gap between their perception and day-to-day reality.
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.
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 customers talk, trust their articulation of what they're trying to accomplish (demand) and why their current tools fail (supply problems). However, completely disregard their suggestions for what product or feature you should build (supply they want). That is your job to design, not theirs.
People are unreliable at predicting their future behavior. Instead of asking if they *would* use a new feature, ask for a specific instance in the last month where it *would have been* useful. If they can't recall one, it's a major red flag for adoption.
Founders are mistakenly taught to find customer pain points. However, a customer can acknowledge a significant pain point yet have no urgent priority to solve it. This disconnect leads founders to build products for problems that customers won't actually pay to fix, resulting in wasted time and resources.
Sridhar Ramaswamy learned that user surveys and stated preferences about privacy or ad intrusiveness are misleading. In practice, revealed preferences show that convenience and accessibility consistently win over these concerns. For this class of problems, what people do is the only truth.
The selection process for marketing technology often goes wrong when decision-makers are seduced by flashy, new features they may never use. This is exacerbated by excluding daily, hands-on users from the evaluation, leading to a tool that doesn't fit the team's actual workflow and needs.
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.