Hacker News has a reputation for being brutally honest. Developers and technical founders don't soften their feedback — they explain exactly why something failed, what they tried before giving up, and what they wish existed instead. If you know how to read those threads, you're sitting on a goldmine of validated market pain.
The problem is that most founders skim HN for inspiration and miss the signal entirely. They see a complaint and think "interesting" — then move on. This post is about slowing down and actually extracting what those complaints are telling you.
Why HN complaints are different from other feedback
Most user feedback lives on a spectrum from vague ("the UI is confusing") to performative ("loving every feature!"). Hacker News skews toward a very specific type of user: engineers, technical founders, and power users who have already tried to solve their own problems programmatically. When they complain on HN, it usually means they've exhausted the obvious options.
That specificity is what makes it valuable. A complaint on HN often includes:
- What they tried first (and why it failed)
- The exact workflow that broke down
- Workarounds they hacked together (which signal genuine pain)
- Tools they're comparing against (which shows you the competitive landscape)
None of this maps directly to a product idea. But it does map to a problem worth investigating.
Where to actually look on HN
Don't just watch the front page. The real research happens in the corners.
Ask HN threads are the most direct signal. Search for patterns like "Ask HN: Is there a tool that..." or "Ask HN: How do you handle..." These threads surface unmet needs explicitly. Someone asking "is there a tool that automatically reconciles Stripe payouts with accounting entries?" is describing a product that doesn't exist well enough yet.
HN Search via Algolia is criminally underused. You can search full comment text, filter by date, and sort by relevance. Try searching terms like "I gave up on", "nothing works for", "I ended up just building", or "I can't believe there's no tool for". Each of those phrases is a frustrated person describing a gap.
Negative product launch threads are another goldmine. When a startup launches on HN and gets critical comments, pay close attention to what people are criticising. Is it positioning? Missing features? Wrong pricing model? Comments like "this would be great but it doesn't handle X" are literally telling you what the successful version of that product looks like.
Reading the complaint beneath the complaint
Here's where most founders stop too early. They read a complaint at face value and either dismiss it ("too niche") or over-index on it ("I'll build exactly this"). Neither works.
The better approach is to treat each complaint as a symptom and ask: what's the underlying behaviour this person is trying to complete?
Take a real example. Imagine you find an Ask HN thread where someone says: "I've tried every monitoring tool and they all send me alerts I don't care about. I've turned off notifications entirely at this point."
Surface reading: they want better alert filtering.
Deeper reading: they've lost trust in their monitoring tool entirely, which means they're flying blind — and they know it. The real product opportunity might not be "better filtering" at all. It could be proactive anomaly detection that only surfaces things that actually matter, or a way to progressively build context over time so alerts become more relevant. The complaint tells you the symptom; your job is to diagnose the disease.
Cross-referencing with other platforms
A single HN complaint proves nothing. The research process is about triangulation — finding the same pain expressed differently across multiple communities.
Once you've spotted a pattern on HN, check:
GitHub Issues on competing or related tools. If multiple repos have open issues describing the same missing feature — and those issues have lots of "+1" comments — that's strong confirmation. GitHub Trending can also help you spot adjacent tools in an ecosystem you're researching.
Stack Overflow Unanswered questions in relevant tags. Questions that go unanswered for months (or years) often represent genuine knowledge gaps that tools haven't addressed. If people are asking how to do something and nobody has a clean answer, that's either a hard problem or an underserved workflow.
Product Hunt reviews, particularly the comments on products that received middling scores. A product that gets a 3.5/5 with 200 upvotes is interesting — it's popular enough that people want it, but not satisfied enough that they love it. The comments usually explain why.
The patterns worth acting on
Not every complaint deserves your attention. After you've done this research for a while, you start to recognise the patterns that indicate real opportunity versus noise.
High signal patterns:
- Multiple people in the same role describing the same workaround (spreadsheet hacks, Zapier chains, manual copy-paste flows)
- Complaints that have been consistent across time (search HN for the same term over two or three years — if the frustration persists, the gap persists)
- Technical users who've partially built their own solution and then stopped — this shows the problem was real enough to start solving but too costly to finish
- Feature requests on popular tools that have been open for 2+ years with no resolution
Lower signal patterns:
- One-off complaints tied to a specific vendor's bug rather than a category problem
- Requests for features that already exist and the person just hasn't found them
- Complaints from people who appear to be outliers in their workflow (their process is unusual, not their problem)
Turning research into a validated hypothesis
The goal isn't to find a complaint you like. The goal is to form a falsifiable hypothesis: "[specific persona] struggles with [specific task] because existing tools do [specific thing wrong], and they would pay for [specific improvement]."
Every word in that sentence should come from something real you've read — not your interpretation of what people probably need.
When you've populated that sentence from actual evidence, you have something worth testing. Not building — testing. Write a landing page. Run some targeted outreach. Post your own Ask HN thread explaining what you're building and who it's for.
If you're doing this kind of research regularly, the manual process gets unwieldy fast. You end up with browser tabs, copied quotes, and half-finished Notion docs that never cohere into anything actionable.
Niche Sonar is built for exactly this workflow — surfacing validated pain patterns from technical communities so you can move from "something feels like a gap" to "here's the evidence" without spending twenty hours on Algolia. If you're at the research stage right now, the free trial is worth an hour of your time this week.