Once you start shipping, feedback arrives. Lots of it.

Feature requests. Bug reports. Complaints. Suggestions. Ideas. Criticism.

Some of this feedback will make your product better. Some of it will make it worse. Some of it is noise that sounds like signal.

The hard part isn't getting feedback. It's knowing which feedback to act on.

The Feedback Firehose

Early on, feedback feels precious. Someone cared enough to tell you something! You want to listen to everything.

But not all feedback is equal. Acting on everything means acting on nothing effectively.

Here's the problem: users are telling you what they want. But what they want isn't always what you should build.

Feedback That Matters

Pay attention when:

It comes from people who paid (or would pay). Free users have opinions. Paying users have skin in the game. Their feedback is more reliable because they've demonstrated willingness to invest.

It's about problems, not solutions. "I can't figure out how to do X" is more valuable than "You should add a button that does X." The first reveals a problem. The second assumes a solution.

Multiple people say the same thing independently. One request is an opinion. Three people with the same struggle is a pattern. Patterns are signal.

It's about what's broken, not what's missing. Fix what prevents people from getting value before you add new value.

Feedback That Doesn't Matter

Tune out when:

It comes from people who won't use it anyway. The person who says "I'd use this if it had feature X" often won't use it with feature X either. They're not your customer.

It starts with "Would be nice if..." Nice-to-haves are infinite. They're not priorities.

Only one person wants it. Individual requests are often individual quirks. Wait for patterns.

It's comparisons to competitors. "Competitor X has this feature" isn't a reason to build it. You're not building Competitor X. You're building your product.

The Vocal Minority Problem

Loudest isn't most valuable.

The people who email you, tweet at you, and comment extensively are a specific type of user. They're comfortable giving feedback. They have strong opinions.

They're not necessarily representative.

Power users want complexity. They've mastered the basics and crave advanced features. But new users need simplicity.

One angry email ≠ systemic problem. Sometimes someone is having a bad day. Sometimes they're just wrong.

Forums amplify the vocal. Online discussions are dominated by a small percentage of users. The majority is silent.

Don't let the loud minority drown out the quiet majority.

How to Gather Good Feedback

The best feedback comes from observation, not surveys.

Watch behavior, not just words. What do people actually do? Not what they say they do. Analytics and session recordings tell the real story.

Ask about the problem, not the solution. "What are you trying to accomplish?" is better than "What feature do you want?"

Dig into the why. When someone requests a feature, ask what they're trying to do. The underlying need might have a better solution than the one they proposed.

Look for workarounds. When users hack together solutions, they're showing you unmet needs.

Processing Feedback

Here's how I handle incoming feedback:

Document everything. Every piece of feedback goes somewhere. Tag it by source, type, and topic. You're building a database of user insight.

Act on little. Most feedback gets documented and nothing else. Not ignored—filed. Waiting for patterns.

Look for patterns. Once a week or month, review the accumulated feedback. What themes emerge? What are multiple people struggling with?

Sleep on requests. Urgent feature requests usually aren't urgent. Wait a day or a week before deciding to build.

Saying No

You cannot build everything. Every feature you add has costs:

  • Development time now
  • Maintenance time forever
  • Complexity for users to navigate
  • More things that can break

Most requests deserve "no." A polite no, but a firm one.

"That's a great idea—it's not something we're focused on right now, but I'll keep it in mind."

This isn't dismissive. It's honest. Your job is to build the right product, not to implement every suggestion.

Your Judgment Still Matters

Here's the thing nobody tells you: you know more than your users do.

Not about their problems—they know their problems better than you.

But about your product, your vision, your constraints, your market. You have context they don't.

Users can tell you where they're struggling. They can't tell you what to build. That's your job.

Balance listening with leading. Take in the feedback. Filter it. Process it. Then make the call yourself.

Vision comes from you. Refinement comes from users. Don't mix up the order.

Related Reading