The Best Product Ideas I Found Were Hiding in Support Tickets Marked 'Won't Fix'

At Sonic Linker, we had a support ticket that sat in our backlog for six weeks. The subject line was just "THIS IS BROKEN" in all caps. The body was even better: a three-paragraph rant about how our AI linking feature "doesn't understand what I'm trying to do" and "keeps suggesting irrelevant connections."

I almost marked it as a bug report and moved on. Instead, I called the user.

Turns out, the feature wasn't broken. It was doing exactly what we designed it to do. The problem was we built it for a workflow that didn't exist. This user (and 12 others who complained similarly) needed the AI to *learn from their edits*, not just make suggestions based on initial input. We had built a one-shot prediction engine. They needed an iterative assistant.

That conversation led to our adaptive learning feature, which became our biggest differentiator when we pitched to enterprise clients three months later.

Why complaints are better signal than feature requests

When someone files a formal feature request, they're already translating their pain into what they think the solution should be. That translation loses context. They might ask for "better filters" when what they really need is a different way to organize data entirely.

Complaints, especially angry ones, come with the raw emotion still attached. And emotion is signal. It tells you where the product is actually failing them, not where they think it should improve.

At Finvestfx, we had a client who complained every two weeks about our reconciliation workflow being "too slow." The feature request would have been "make it faster." But when I sat with their ops team, I realized speed wasn't the issue. They were doing reconciliation at the wrong time in their process because our workflow forced them to. They needed the ability to defer reconciliation, not accelerate it.

We shipped a "save draft" feature instead of optimizing load times. Complaints dropped by 60% in that segment.

The pattern I started looking for

After that Sonic Linker ticket, I changed how I read support logs. I stopped looking for the word "feature" and started looking for three things:

Workarounds. When users describe hacky solutions they've built around your product, they're showing you the job they're actually hiring your product to do. At Stampede Capital, we had users exporting data to Excel to do calculations we could have done in-platform. Each workaround was a missing feature screaming at us.

Emotional intensity. If someone uses words like "frustrating," "confusing," or "waste of time," they're not just reporting a bug. They're telling you the product broke a promise. That's where you find real friction. I tag these differently now. They don't go into a "complaints" bucket, they go into "workflow breakdowns."

Frequency without volume. Sometimes the best signal isn't the complaint you get 50 times. It's the complaint you get from five users in your ideal customer profile. At Sonic Linker, we had a handful of power users complaining about lack of bulk actions. Everyone else was fine. But those power users were the ones spending 10+ hours a week in the product. We built for them, and it pulled the entire user base upmarket.

What I actually do with this now

I run a monthly "complaint mining" session. I pull every ticket marked as a complaint, ignore the ones that are actually bugs, and sort the rest by user segment. Then I look for patterns.

The goal isn't to fix every complaint. It's to find the ones that reveal a gap between how we think the product works and how users are actually trying to use it.

At NJ Group, I did this with our advisor training feedback. The most common complaint wasn't about the content. It was about timing. Advisors kept saying they "didn't have time" to go through modules. That wasn't a content problem. It was a delivery problem. We switched from weekly long-form sessions to daily 10-minute micro-lessons. Completion rates tripled.

The real insight

The best feature ideas don't come from users who know how to articulate product requirements. They come from users who are mad enough to tell you the product isn't working, but engaged enough to still be using it.

Those are the ones solving a problem you built for but didn't fully understand yet.

So the next time you see a support ticket that starts with "Why can't I just...", don't dismiss it as a rant. That sentence is usually followed by the feature you should have built three months ago.

You just have to be willing to listen past the frustration.