Your Users Are Lying to You (And It's Your Fault)

Henry Ford may or may not have said "if I asked customers what they wanted, they'd have said faster horses." Doesn't matter - the point is real.

Users are bad at predicting what they want. They're excellent at telling you what they're feeling right now.

Those are very different things, and most feedback tools are optimized for the wrong one.

The Lie You're Collecting

Feature request boards are a survey. Users answer the question: "What would make this product better for you?"

That's a hypothetical. A prediction. A rationalization.

And humans are terrible at hypotheticals. We're wired for the present moment.

When you ask someone what they want, they tell you what sounds reasonable. What they can articulate. What they've seen done in other products. What would make them look like a thoughtful, helpful user.

They're not lying intentionally. They just don't have access to the real data.

The real data is in their behavior. In the moment of frustration when the export button doesn't work. In the tiny hesitation before clicking "upgrade." In the page they always navigate away from too quickly.

None of that is on your feature board.

What "Feedback" Actually Means

There are two kinds of signal your users generate:

Expressed preferences - what they say they want. Feature requests. Votes. Survey responses. These are rationalizations after the fact.

Behavioral signals - what they actually do. Where they get stuck. Where they leave. What they do right before they churn. These are truth.

Most feedback tools only capture expressed preferences. And expressed preferences, without behavioral context, are noise dressed up as data.

"Users want X" based on 14 upvotes on your Canny board means almost nothing without knowing: which users? How active are they? Are they the users who churn or the ones who stay? What were they doing when they requested it?

The Moment That Matters

There's a specific moment in every user's journey where their signal is loudest and most accurate.

It's not when they're filling out your NPS survey a week later.

It's not when they're browsing your feature board at 9am with coffee.

It's the exact moment of friction, delight, or confusion while they're in your product.

That moment is brutally honest. The emotion is live. The context is immediate. The memory is perfect - they haven't had time to rationalize or soften it.

That's the moment you need to capture.

Which is why every second of friction between that moment and the feedback submission is a second of signal decay. By the time a user navigates to your feedback portal, creates an account, and types out their request, they've already started editing themselves. The raw signal is gone.

What Captures the Moment

The only feedback mechanism that captures the moment is one that's already on the page.

Not a link to a portal. Not an email. Not a scheduled user interview.

An embedded widget. Right there. Always visible. Two clicks to submit.

Sentiment-first works best. Instead of asking users to articulate what they want (which triggers rationalization), ask them how they feel. Love it. Like it. Dislike it. Frustrated.

That's a gut reaction. It doesn't require language or framing. It's the honest version before the PR version kicks in.

Then - and only then - offer a text field for them to add context if they want to.

You'll get the raw signal first. The articulated request second. In that order, the articulated part is colored by the emotion, not the other way around.

The Feedback You Should Trust

Not all feedback is equally trustworthy.

Trust more:

• Submissions from the exact page where the problem occurred
• Submissions with negative sentiment (people don't bother to complain if they don't care)
• Patterns across different users on the same page or flow
• Feedback submitted immediately, not days later

Trust less:

• Feature requests with no behavioral context
• Highly-voted ideas from power users with no indication of whether average users share the priority
• Survey responses collected asynchronously
• Anything that required more than two clicks to submit (the bar self-selects for the motivated)

The harder it is to submit feedback, the more you're hearing only from people with strong opinions. That's useful sometimes. But it's not representative.

What To Do About It

Stop treating feedback as a category of event to be collected in one place.

Start treating it as a signal layer on top of your product - always on, always ready, zero friction.

Put a feedback widget on every page of your product. Not a help button. Not a "report a bug" link. An always-visible, emotion-first feedback mechanism that takes two clicks.

Read what comes in. Don't run it through a voting algorithm. Just read it. Pattern-match with your own judgment. Look at which page each submission came from.

You'll start seeing your product the way your users see it. Not through the filter of what articulate power users prefer. Through the raw experience of everyone.

That's the feedback that builds better products.

Palmframe is the two-line embed that makes this happen. Free for your first project. The widget captures sentiment, a message, and the page URL - so every piece of feedback arrives with full context, from the exact moment it was felt.