I analysed 7,484 Reddit discussions. The broad categories were almost useless.

I analysed 7,484 Reddit discussions looking for startup ideas, expecting a few problem categories to clearly dominate. When I averaged the complaint-intensity scores across around 59 categories, almost all of them looked the same.

At first I thought the analysis had failed. It hadn't. I was reading it at the wrong level.

The mistake was treating a broad category as if it were one product opportunity. Something like "lead generation" or "admin" isn't a thing you can build. It's a bag holding several unrelated workflows, each with its own user, process and buyer. Averaged together, they blur into a flat, useless number. The useful signal lived at the workflow level, not the category level.

Here's how I got there.

The dataset

I've been building a tool called Problem Signal that reads public discussions and groups recurring problems and requests. This post is about a mistake I made while interpreting its data.

It covers 7,484 Reddit submissions across roughly 70 business, professional and builder communities, with the comments analysed alongside each post. From those, the system pulled 33,850 complaint statements, each linked back to a verbatim quote from the original discussion.

One caveat up front: this is only where I looked. Business and builder subreddits shape which complaints show up, so none of it speaks for markets I didn't sample.

Why the category view misled me

A single category can hold problems that have nothing to do with each other: different users, different workflows, different buying processes. When that's true, a category average can't point you at a product, because there is no single product to point at.

The scoring made this easy to miss. Each complaint got a model-generated intensity score from 0 to 1 — how strongly the pain was expressed in its source discussion. Averaged by category, almost every category landed between 0.64 and 0.70. That number wasn't market size, purchasing intent or people affected. It was an average of a model's ratings, and averaging is what flattened the differences I cared about.

One category, two different workflows

The clearest example was "lead quality and attribution," one of the largest categories at 1,438 complaint statements. Two of the most recurring requests inside it weren't variations on one idea:

Filtering spam and bot leads out of advertising forms before a salesperson wastes time following them up — 145 distinct post authors.
Auditing the quality of SEO backlink sources — 95 distinct post authors.
These are different users, different workflows and different buyers. The only thing they share is the label. A category-level ranking would have merged two separate problems worth investigating into one misleading signal.

A note on that unit: "authors" means unique usernames who created a post containing the request — not every commenter, and not a count of all Reddit users.

Averages were flat; volume was not

Flat averages don't mean demand was evenly spread — only the averaging was compressed. Raw complaint volume ran from 1,441 statements in the largest category down to 58 in the smallest. At the request level the gap was sharper: among the top-ranked requests, recurrence ran from 80 distinct authors up to 256. The flatness was an artefact of averaging, nothing more.

What I changed

After this, I stopped ranking anything by category — I use categories only for navigation now. The real comparison happens at the request level, where I can line up recurrence, distinct authors, the words people use, and the workaround they describe. The category tells me which shelf to walk to. The request tells me whether there's anything on it worth building.

What I'd tell another founder

Rank workflows, not categories.

A useful product hypothesis is specific enough to name the user, the task, the current process, the point it breaks, and the outcome they want. "Marketing problems" is a category. "Removing bot leads before a salesperson chases them" is a workflow. Only the second one is specific enough to investigate as a product.

Study the workaround, not the named competitor.

The current workaround often tells me more than any rival product. A spreadsheet reveals the fields and steps someone actually needs. A virtual assistant means they already pay for the labour. A manual routine shows the time you could give back. And "we just wing it" means the problem is being tolerated, not bought away, which is its own warning. A workaround is evidence the problem is real. It's not proof anyone will pay for software to replace it.

Another useful clue is when the same workflow appears in unrelated communities. I treat that as a reason to investigate, not proof of a market. Those users may still need different integrations, compliance and buyers.

What the data can't tell me

Recurrence is where I start customer research, not where I finish it. A request repeating across hundreds of posts shows me where the pain is, not where the money is. Before building, I still have to answer four things:

Are people already spending money on this?
How costly is the current workaround?
How often does the problem happen?
Is there a clear buyer with budget and urgency?
The data points me at the door. It doesn't tell me what's behind it.

For founders who found a product through customer complaints: what evidence finally convinced you people would pay, existing spend, an expensive workaround, urgency, pre-orders, or something else?

I built this analysis as part of Problem Signal. You can browse the ranked ideas and the quotes behind them at problemsignal.com.