There are three ways to treat the customer’s voice: obey it (“the customer is always right,” so build to every whim), ignore it (pure visionary conviction), or take Ries’s route and listen to it as data. Gather it continuously, then test it through experiments. At IMVU, the team spoke with early adopters every day and, pointedly, did not simply do what they asked. They ran experiments on them.
Two mechanisms explain why a request is not a requirement:
- Stated and revealed preferences diverge. Words about future behavior are unreliable; behavior in an experiment is the reliable signal (objective metrics such as logins and registration speed). Hence the paradoxical formula: learn what customers want without asking them.
- Data do not interpret themselves. The selection and interpretation of signals are determined by mental models - the ladder of inference in Adaptation to the environment depends on objective perception. A user’s request is their interpretation of their problem, not the problem itself. The product version in Cagan’s Inspired is that a product manager solves the user’s problem rather than executing the user’s request.
The boundary matters: this claim does not permit ignoring users. Qualitative feedback is collected alongside quantitative feedback; experiments are run on and about users. The only thing revoked is the automatic authority of their words as orders.
The rule also applies to input from internal stakeholders: an internal customer’s request for a feature is likewise input to an experiment designed to falsify an assumption, not a finished specification.
How this supports A startup exists to learn how to build a sustainable business
Validated learning depends on this claim: an experiment is meaningful only when behavior weighs more than words. Otherwise, surveys alone would be sufficient for “validated knowledge.” This claim gives the method its signal source.