The Customer Want Detector
Discover what customers want through their behavior not their words
The Customer Want Detector is Graham's framework for discovering what customers actually want by observing their behavior rather than listening to their stated preferences. Graham argues that customers are unreliable narrators of their own needs — they will tell you they want dozens of features they would never use, and they will fail to mention the one capability that would make your product indispensable. The only reliable signal is behavior: what they actually do with your product, where they struggle, what they use repeatedly, and what they ignore. The framework requires launching a minimal product as quickly as possible and then watching intently. Graham used this approach at Viaweb, where the feedback loop was so tight that he would discover missing features while building a merchant's store and implement them in hours. The framework directly challenges the build-in-isolation approach where founders spend months perfecting a product before exposing it to users.
- Customers are unreliable narrators of their own needs
- Behavior reveals true needs while words reveal aspirational wishes
- Launch quickly with minimum utility and observe rather than building in isolation
- The tighter the feedback loop between users and development the better the product
- Features users request are often different from features users would actually use
- Launch with Minimum UtilityGet your product in front of users as soon as it provides any value at all — not when it is feature-complete, polished, or ready. Graham argues that your initial model of users is always wrong, and the only way to correct it is to observe real usage. A month of building plus real user observation beats a year of building in isolation.
- Watch What Users Do Not What They SayObserve how users actually interact with your product rather than asking them what they want. Track which features are used frequently and which are ignored. Notice where users get confused, frustrated, or give up. Watch for workarounds — when users hack together solutions to problems your product does not solve, those workarounds are feature requests expressed through behavior.
- Tighten the Feedback LoopMake the cycle from user observation to product change as short as possible. Graham's ideal at Viaweb was hours — discovering a problem while helping a user and implementing the solution immediately. Modern tools make this even more feasible. The faster you can cycle between observation and implementation, the faster your product converges on what users actually need.
- Build for Observed Behavior Not Requested FeaturesWhen deciding what to build next, prioritize problems you have observed users struggling with over features users have explicitly requested. Feature requests are contaminated by imagination, aspiration, and social desirability. Observed struggles are genuine unmet needs. The product roadmap should be driven by behavioral data, not by feature request lists.
While building online stores for merchants at Viaweb, Graham would frequently discover that a needed feature did not exist. Rather than adding it to a backlog, he would pause, implement the feature in a couple of hours, and then resume building the store. This created a product that was shaped entirely by actual merchant needs rather than imagined requirements.
Graham developed this insight at Viaweb, where the team would build online stores for merchants and discover product gaps in real time. When a merchant needed a feature that did not exist, Graham would implement it in hours and continue building. This produced a product shaped entirely by actual usage rather than imagined requirements. At YC, Graham saw the pattern repeat: startups that launched early and iterated based on behavior consistently outperformed those that built in isolation based on assumptions about what users would want.