Your Users Won't Tell You What They Need. They'll Tell You What Broke.

The feature request form was a graveyard

When we launched Sonic Linker, I did what every good PM does. I set up a feature request board. I added a "Submit Feedback" button. I even sent out surveys asking users what they wanted next.

The responses were useless.

People asked for things like "better integrations" or "more customization." One person literally wrote "make it faster." Cool. Super actionable.

Meanwhile, our support chat was on fire. Users were complaining. A lot. And buried in those complaints was every single insight I needed to build the next three months of product.

I just wasn't listening properly.

Complaints tell you what actually matters

Here's what I noticed. When someone fills out a feature request form, they're trying to be helpful. They're in solution mode. They think about what *might* be nice to have.

But when someone complains, they're in pain mode. They're telling you what's *actually blocking them* right now.

At Finvestfx, I managed 20+ enterprise treasury clients. One of them sent me a heated email about how our reconciliation flow was "a joke" because they had to manually export data, clean it in Excel, and re-upload it. They didn't ask for a better export feature. They just vented.

I could have written it off as them being annoyed. Instead, I dug in. Turns out, six other clients were doing the exact same workaround. They just hadn't complained yet.

We shipped an automated reconciliation feature in two weeks. Retention went up. Expansion revenue followed.

That feature never would have made it onto a roadmap if I'd only looked at the "nice to have" lists. It was hiding inside someone being angry about a broken workflow.

The complaint audit I started doing

After that, I changed how I approached feedback. Every week, I'd pull up support tickets and angry emails and look for patterns. Not in what people were asking for, but in what was making them reach out in the first place.

I started categorizing complaints into three buckets:

Friction complaints – "This takes too long" or "I have to do this manually." These usually pointed to automation opportunities or workflow gaps.

Confusion complaints – "I don't understand why this works this way" or "Where is X?" These were onboarding or UX problems, but they also revealed mismatched expectations.

Workaround complaints – "I have to use another tool for this" or "I export everything to Excel." These were the gold. They told me where the product was leaking value.

At Sonic Linker, we found a pattern in workaround complaints. People kept saying they were "jumping between tabs" to cross-check data. They weren't asking for a dashboard. They were just annoyed. But that complaint led us to build a consolidated view that became one of our stickiest features.

Why most PMs miss this

I think the reason complaints get ignored is because they feel like noise. They're messy. They're emotional. They don't fit neatly into a prioritization framework.

Feature requests, on the other hand, feel like data. Someone took the time to write "I want feature X." It feels concrete. You can put it in a spreadsheet, count votes, and pretend you're being rigorous.

But here's the thing. Feature requests are hypothetical. Complaints are real. A complaint means someone cared enough to stop what they were doing and tell you something is broken. That's signal.

When I worked with 60 insurance advisors and IFAs at NJ Group, I learned this the hard way. I kept running training sessions and asking people what features they wanted in the tools they were using. Crickets.

But when I sat with them during their actual workflow, they'd mutter things like "why do I have to open three screens for this" or "this calculation never matches." That's when I knew what actually mattered.

What I do now

I don't ignore feature requests. But I weight complaints way higher. Especially complaints that come with workarounds.

If someone is annoyed enough to hack together a solution, that's a feature screaming to be built.

I also stopped treating support conversations as someone else's job. I read them. I join calls. I ask follow-up questions. Not because I'm trying to be a hero, but because that's where the real product insights live.

The takeaway

Your users aren't going to hand you a roadmap. They're going to tell you what's broken, what's annoying, and what they're working around. Your job is to listen to the complaints and decode the need underneath.

Stop waiting for perfect feature requests. Start paying attention to what's making people swear at your product. That's where the good stuff is.