How to Do Customer Discovery When You Can Read the Complaints

Picture a developer founder at the start of validation. The calendar invites go out, the interviews are scheduled, and twenty conversations later everyone agreed the problem was real. Then the product launched and nobody bought. That gap is usually a reading failure, not a calendar failure: if you are building a developer tool or dev-facing SaaS, your prospective users complain in writing, in public, every single day, on GitHub, Stack Overflow, Hacker News, and Bluesky. Customer discovery for you is less about generating opinions from scratch and more about confirming a pattern you can already see in the data before you book a single call.

This piece is the version of customer discovery I would run as a developer-founder. It puts a reading step in front of the talking step, and it treats interviews as a way to falsify a hypothesis rather than collect encouragement. The whole point is to reach a clear yes-or-no on whether a specific group of people has a specific problem worth paying to solve, and to reach it in weeks, not quarters.

Customer discovery is a filter, not a survey

The classic failure mode is to run discovery as a positive-proof exercise. You already like your idea, so you go looking for people who will agree with it, you ask leading questions, and you come back with a folder of nice quotes and no decision. Real discovery runs the other way. You are trying to disqualify the idea as fast as possible, and the only way to trust a yes is to have given the no every chance to show up.

That framing matters most at the reading stage. When you read complaints in bulk, one loud thread is not a market. The signal is the number of distinct people hitting the same wall independently. In the EchoSift pipeline, that number is the distinct-owner count on a pain cluster: how many separate accounts, not messages, raised the same complaint.

Step 1: read the complaints before you write a single question

Start where the evidence already is. Pull the recurring complaints in your domain and rank them by how many distinct people raised each one. You are not trying to read everything. You are trying to find the two or three clusters where independent demand is obvious, so your interviews start from a real hypothesis instead of a hunch.

As a concrete example, here is what the live EchoSift feed looked like on 5 July 2026, drawn from 25601 total signals and 2482 new signals in the last 7 days across 4 sources. The single broadest complaint by distinct owners was “Lack of Rate Limiting on API Endpoints”, a cluster with a pain score of 81 and a volume of 69 mentions, but the number that matters is 43 owners. Forty-three separate accounts independently raised the same missing capability. That is the shape of a real market, not a personality.

Three other clusters on the same day put that number in context.

Three problems each backed by dozens of independent voices is a much better starting set than any single idea you brought to the table.

Reading first does three things a blank-page interview cannot. It tells you which problems already recur, so you do not waste interviews confirming something the data already proves. It gives you the actual vocabulary people use, so your questions sound native instead of made up. And it separates a broad complaint from a narrow one before you commit, which is the difference between the top and the bottom row of that table.

The 2025 Stack Overflow Developer Survey is a useful backdrop here. It confirms how many developers are shipping side projects and hitting these same infrastructure and tooling walls, which is exactly why the public complaint stream is so dense. Your prospective customers are documenting their own pain in searchable text. Reading it is the cheapest discovery you will ever do.

Step 2: turn each cluster into a falsifiable hypothesis

A cluster is not a hypothesis yet. Before you schedule a call, write down the specific claim you are trying to break, in the form: this group of people has this problem badly enough to change what they use or pay for. For the rate-limiting cluster, the claim might read: solo API builders ship without rate limiting, get burned in production, and would adopt a drop-in library to avoid it. That sentence has three parts you can each test, and each part can return a no.

The value of writing the claim down is that it forces you to name the group. “Developers” is not a group. “Solo founders shipping public APIs on a small budget” is a group you can find and talk to. The 43 owners on the rate-limiting cluster are real accounts, and their public posts usually reveal enough context to tell you which of them fit the group you named. Discovery gets far easier when you already know who you are looking for and where they hang out.

Step 3: run interviews that can return a NO

Now you talk to people, and the only rule that matters is the one from The Mom Test: ask about their past behavior, never about their future opinions. “Would you pay for this?” is worthless, because everyone is polite about hypotheticals. “Walk me through the last time you hit this problem, what did you do, and what did it cost you?” is gold, because it is a fact about a real event.

Paul Graham’s advice in Do Things That Don’t Scale applies directly to this stage: recruit your first users by hand, one conversation at a time, and treat each one as a source of truth about whether the problem is real. You are not running a focus group. You are trying to find out whether the pattern you read in the data survives contact with the people who wrote it.

A few mechanics keep these interviews honest.

1. Recruit from the actual owners in your clusters

   They have already demonstrated the pain in public, which removes the recruiting guesswork.

2. Keep the sample small but specific

   Eight sharp conversations with people in your named group beat thirty scattered ones.

3. Write your no conditions in advance

   If fewer than half of the people you talk to describe a real, recent, costly instance of the problem, the hypothesis failed, and that is a good outcome because you learned it in a week.

For the interview craft itself, the Nielsen Norman Group guide on interviewing users is a solid reference on asking without leading.

Step 4: separate a bug from a business

Discovery does not end when people agree the problem is real. Plenty of real problems are not businesses. The separation you are looking for is between a complaint people will grumble about and a complaint people are already spending time or money to work around. A workaround is the strongest buying signal in customer discovery, because it proves the problem is expensive enough that someone is paying a cost today.

The complaint data helps you tell these apart before the call even happens. A cluster like “Documentation Clarity Issues”, with a pain score of 77.6 across 11 owners, is a genuine frustration, but people mostly cope with bad docs rather than pay to fix them. The rate-limiting cluster, with its 43 owners and production consequences, points at people who have shipped something, felt the pain in a live system, and have a real incentive to switch. When you interview, you are checking whether the workaround is painful enough that a better option would win. If the answer is that people shrug and move on, you have found a bug, not a business.

Step 5: decide, then keep listening

Discovery produces a decision, not a feeling. Either the pattern held, the group is real, and people are paying a cost you can remove, in which case you build the smallest thing that tests the fix, or it did not hold, and you go back to the next cluster on your list. Both outcomes are wins. The only losing move is to keep talking to people forever because you are afraid of the no.

The advantage of grounding discovery in a live complaint stream is that it does not stop when you ship. The same signal that told you 43 owners wanted rate limiting will tell you whether that number is growing or fading, whether new adjacent complaints are forming, and whether a competitor just solved half the problem. Customer discovery, done this way, is a loop you keep running, not a phase you exit.

If reading the complaint stream by hand sounds like a lot of manual work, that is exactly the part EchoSift automates. It ingests complaints from GitHub, Stack Overflow, Hacker News, and Bluesky, clusters them into recurring pain patterns, and ranks them by volume, distinct-owner count, cross-vendor diversity, growth, and recency, so the reading step above takes minutes instead of days. The interviews are still yours to run, but the pattern is already on the table.

For the wider validation workflow this feeds into, see the pillar guide on how to validate a SaaS idea, and for the reading step in more depth, what the developer pain-point data actually says, how to find startup ideas from the same stream, and the broader tips for market research founders use.

This article was drafted with AI assistance and reviewed against EchoSift’s proprietary signal data before publishing.