You Keep Saying "Users Will Tell Us What They Want" — They Won't

The Most Dangerous Phrase in Early-Stage Building

"We'll just listen to our users."

It sounds so reasonable. So humble. So lean-startup-approved.

You launch something, get feedback, iterate based on what people tell you, and eventually arrive at product-market fit. That's how it works, right?

Except it almost never works that way.

What actually happens is this: you talk to 20 users. You get 20 different opinions. Some want it simpler. Some want more features. One person wants an integration with Notion. Another wants it to work offline. Someone says the pricing is too high. Someone else says the free tier is too generous and makes the product feel cheap.

So you try to accommodate everyone. You add a little of this, tweak a little of that. Six months later, you've got a bloated, confused product that tries to do everything and does nothing particularly well.

Congratulations. You listened to your users. And it wrecked your product.

Why Users Can't Tell You What to Build

This isn't a knock on your users. They're not dumb. The problem is structural.

People are excellent at describing symptoms and terrible at prescribing solutions.

Think about it in a medical context. A patient walks into a doctor's office and says, "My chest hurts when I breathe deeply." That's real, useful information. But if the patient then says, "I think I need heart surgery," the doctor doesn't just book an OR. The symptom is reliable. The self-diagnosis is not.

Your users are patients. They can tell you:

"This is confusing."
"I expected it to do X but it didn't."
"I stopped using it after a week."
"I wish it was more like [competitor]."

All of that is valuable data. But none of it is a product roadmap. It's raw signal that needs interpretation.

Here's the classic example. Before the iPhone, if you'd asked mobile phone users what they wanted, they would have said things like "longer battery life," "better T9 typing," and "a more durable flip mechanism." Nobody would have described a multi-touch glass rectangle with no physical keyboard. The symptoms ("texting is slow," "I can't browse the internet easily") were real. The solution required vision that users simply couldn't articulate.

Henry Ford probably never actually said "If I had asked people what they wanted, they would have said faster horses," but the principle is sound. Users frame solutions within the world they already know. Your job is to understand the underlying need and solve it in ways they haven't imagined yet.

The Frankenstein Product Trap

When you don't have a framework for interpreting user feedback, every piece of feedback feels equally important. And that's where the Frankenstein problem starts.

Here's how it plays out:

Month 1: User A says they need a calendar view. You build it.

Month 2: User B says they need CSV export. You build it.

Month 3: User C says they need team collaboration. You build it.

Month 4: User D says the product is too complex and they want something simpler.

You're now stuck. Every feature you added was requested by a real user. But you never stopped to ask: are User A, User B, User C, and User D even the same type of person? Do they have the same problems? The same context? The same willingness to pay?

Usually, the answer is no.

You've been building for everyone, which means you've been building for no one. Your product is a patchwork of disconnected features stitched together by good intentions. A Frankenstein monster.

The Missing Piece: A Persona Framework

This is where most "just listen to users" advice falls apart. It skips a critical step: knowing who you're listening to and why their opinion matters for your specific product.

This is what I call the Personas station — Station 3 in the diagnostic framework I use. It's the work of defining, with real specificity, who exactly you're building for.

Not "small business owners." Not "busy professionals." Not "anyone who needs project management."

I mean:

What's their specific situation?
What triggered them to look for a solution?
What have they already tried?
What does their day actually look like?
What would they pay for, and what do they consider table stakes?
What's their level of technical sophistication?

When you have this kind of clarity, user feedback transforms from noise into signal. Here's why:

1. You Can Filter Feedback by Relevance

Not all users are your users. When someone requests a feature, you can ask: "Does this person match our persona?" If yes, that feedback gets weighted heavily. If no, you can note it and move on without guilt.

This is liberating. Suddenly you don't have to build everything everyone asks for. You have a principled reason to say no.

2. You Can Translate Symptoms into Solutions

When a persona-matched user says "this is confusing," you can interpret that through the lens of what you know about them. A non-technical solo founder saying "this is confusing" means something completely different from a developer saying "this is confusing." The solution for each is wildly different — one needs fewer options, the other probably needs better documentation or an API.

Without the persona lens, "this is confusing" is just a vague complaint. With it, it's a specific design problem you can solve.

3. You Can Spot Patterns Instead of Chasing Outliers

When you know your persona, you can look across multiple conversations and find the common pain points. Not the one-off requests, but the themes. "Seven out of ten of our target users mentioned struggling with X" is actionable. "One user wants Y" is not.

How to Actually Listen (With a Framework)

So I'm not saying ignore your users. I'm saying stop treating their words as literal instructions. Here's a better approach:

Step 1: Define Your Persona First

Before you do a single user interview, have a hypothesis about who you're building for. Write it down. Be specific. Give them a name if it helps. Describe their situation, their pain, their alternatives.

This doesn't have to be perfect. It's a starting point that you'll refine.

Step 2: Talk to People Who Match That Persona

Don't just talk to anyone who's willing. Seek out people who fit your persona description. If your persona is a freelance designer who's overwhelmed with client management, go find freelance designers. Don't interview agency owners or in-house designers and assume the feedback transfers.

Step 3: Ask About Problems, Not Solutions

The best user research questions are about their life, not your product:

"Walk me through the last time you dealt with [problem]."
"What did you try? What happened?"
"What was the most frustrating part?"
"How are you handling this today?"

Notice none of these questions are "What features would you want?" That question is almost useless.

Step 4: Interpret Through Your Persona Lens

After conversations, sit down and look at the patterns through the lens of your defined persona. What are the common frustrations? What workarounds keep coming up? Where is the real pain — not the surface-level annoyance, but the thing that's costing them time, money, or sanity?

Step 5: Design Solutions They Couldn't Articulate

This is your job as the founder. You take the symptoms and context you've gathered and design a solution. The user told you the problem. You figure out the fix. That's the value you bring.

A Real-World Example

Let's say you're building a tool for freelancers to manage their invoicing. You talk to ten freelancers. Here's what you hear:

"I wish I could track time in the app."
"I need better reporting."
"Can you integrate with QuickBooks?"
"I want to send automatic payment reminders."
"I just need something simpler than what I'm using."

Without a persona framework, these all seem like feature requests to add to the backlog. With one, you might realize:

Your persona is a solo freelancer doing under $100K/year who's currently using spreadsheets or nothing. They don't use QuickBooks (that's for a different, more established freelancer). They don't need advanced reporting. What they actually need is the fastest possible path from "I did work" to "I got paid."

Suddenly, the roadmap becomes clear. Automatic payment reminders? Yes, that's core. Time tracking in the app? Maybe, if it's dead simple. QuickBooks integration? No — that's a different product for a different person. Advanced reporting? Later, if ever.

Same feedback. Completely different interpretation. The persona made the difference.

The Hard Truth

"Listening to users" feels productive. It feels humble. It feels like you're doing the right thing.

But without a framework to interpret what you hear, you're just collecting noise and calling it strategy. You'll build features nobody asked you to prioritize, solve problems that aren't central to your core user, and end up with a product that's a mile wide and an inch deep.

The fix isn't to stop listening. It's to know who you're listening to, understand what they're really saying beneath the surface, and take responsibility for the solution. That's your job as a founder.

Your users will tell you where it hurts. But they won't hand you the cure. That part's on you.

If you're not sure whether you've nailed your personas — or if you suspect you've been building for too many people at once — that's exactly the kind of thing Clari Station's diagnostic helps you see. It takes about five minutes and shows you which foundational stations (like Personas) might be the real reason you feel stuck. No pitch, no commitment — just clarity on what to fix first.