Why Users Lie to You (And You Keep Believing Them)

You asked your users what they want.
They told you.
You built it.
Nobody used it.
This isn't bad luck. This is a trap that kills products every single day — and almost nobody in the dev world talks about it honestly because it means admitting that the entire foundation of "user research" has a rotting floor.

1. The Problem Has a Name Behavioral scientists call it the Intention-Action Gap. It means this: what a person says they'll do and what they actually do are two completely different things — and the gap between them is not small. Harvard Business Review studied it directly. 65% of consumers said they want to buy from purpose-driven brands. Only 26% actually did. A 39-point gap between stated intention and real behavior. (Askrally) That's not a rounding error. That's a structural lie — not malicious, but baked into how human cognition works. People find it genuinely difficult to predict their own future behavior, especially outside the real-life context in which that behavior would happen. (Bamboo Brands) Ask someone in a calm survey whether they'd pay for a productivity app — they say yes. Confront them at 11pm with a $9.99 checkout screen after a long day — they close the tab. The context you research in is never the context they buy in. That gap is where your product dies

• Why Devs Get Hit Hardest
  Designers and marketers have been burned by this enough times that they've built entire methodologies around it — ethnographic research, diary studies, contextual inquiry. They've accepted that users lie, not out of malice but out of cognitive limitation.
  Devs? We still run user interviews like they're depositions.
  We ask: "Would you use a feature that does X?"
  User says: "Yes, absolutely, that would be super helpful."
  We spend 3 weeks building X.
  User opens the app, sees X,
  doesn't touch it, churns in week 2.
  Traditional user interviews are built on a faulty premise — that users can accurately report their own behaviors, preferences, and needs. (LinkedIn) They can't. Not because they're stupid. Because the brain that answers your interview question is not the same brain that makes decisions at the moment of use. One is reflective, calm, and aspirational. The other is distracted, impatient, and running on autopilot.
  Research shows that roughly 50% of everything humans do daily is done with little or no conscious thought — purely out of habit. (UI-Patterns) Your users aren't making considered decisions when they use your product. They're reacting. And you can't interview a reaction.

• The Amazon Fire Phone Was Built on User Lies
  Amazon had resources. Amazon had research. Amazon had a team that probably ran more user interviews than you'll run in your entire career.
  The Fire Phone launched in 2014 and cost the company around $120 million. It was overloaded with features users said they wanted — and failed to compete because nobody actually wanted them when the moment of truth arrived. (Scrum.org)
  The features weren't bad engineering. They were bad psychology. Amazon confused stated preference with revealed preference. Users will always tell you they want more power, more features, more options. What they actually want is less friction and more certainty.
  The Fire Phone didn't fail because it was built wrong. It failed because Amazon asked the wrong question — "what do you want?" instead of "what do you actually do?"

• What You Should Be Watching Instead
  Forget what users say. Watch what they do.
  Three signals that actually tell the truth:

• Where they stop.
  Your drop-off points in onboarding aren't random. They're the exact locations where your assumed user intent collides with real user behavior. A user who said they "definitely want to try the app" and then ghosts after step 3 of your signup flow — that's the truth. That's the gap made visible.

• What they use without being prompted.
  If you ship 5 features and users organically reach for 1 of them without you pushing it — that's a revealed preference. That feature has a real internal trigger. The other 4 don't. Kill them.

• What they complain about that you didn't ask about.
  Support tickets, 1-star reviews, Reddit threads about your product — these are behavioral artifacts. Someone was so moved by friction or failure that they overcame the effort of complaining. That's signal at a premium. That's the gap screaming at you.
  The Framework: Stop Interviewing, Start Trapping
  Here's the shift in how you approach user understanding:
  Old way: Ask users what they want → build it → wonder why nobody uses it.
  New way: Build the smallest possible version of one thing → put it in front of real users in a real context → watch what they do → then ask why.
  The question "why" only becomes useful after you've seen real behavior. Before that, it produces fiction.
  Fake door tests — where you build a landing page or button for a feature that doesn't exist yet and measure real clicks — show you genuine buying intent far better than any survey. You're observing actual behavior, not self-reported intention. (Gethorizon)
  This isn't a new idea. It's just one that most devs skip because writing survey questions is easier than designing behavioral experiments. Easier, and far more expensive in the long run.
  What This Means for Your Next
  Build

• Before you write a line of code for a new feature, ask yourself:
  Am I building this because users said they want it, or because I watched them try to do it without the feature existing?
  Where in my current product do users stop? Have I treated that drop-off as hard data?
  Is there one feature users reach for unprompted? Can I make that feature the center of gravity instead of a sidebar?
  You don't need a PhD in behavioral science. You need to stop treating user interviews as evidence and start treating them as hypotheses.
  The lie isn't malicious. But it will kill your product just as dead