June 8, 2026
The Problem with 'Build Something People Want' (And What to Do Instead)
Paul Graham wrote it. Y Combinator stamped it on everything. A generation of founders memorized it.
"Build something people want."
It's good advice. It's also incomplete in a way that quietly kills most products before they ever ship.
The founders who follow it literally — who ask "what do people want?" and then build that thing — often end up with a product nobody uses. Not because the advice is wrong. Because the question is wrong.
People rarely know what they want. But they know, in vivid detail, what's breaking them.
The word that's doing the damage: "want"
"Want" implies articulation. A person who wants something can describe it. They can fill out your survey, answer your interview questions, upvote your feature request.
But most real problems don't live in that space. They live in the space of endurance — things people are putting up with because no solution exists, or because they don't know one does, or because they've normalized the pain.
Nobody writes a tweet saying "I want a tool that reconciles my crypto cost basis across defunct exchanges so the IRS doesn't assume my entire sale was pure profit." But someone absolutely posts a Reddit thread at midnight, exhausted, saying:
"I lost sleep, spent hours reconstructing things, considered hiring these super expensive crypto accountants. And now the IRS is treating my entire $200K sale as $200K in profit because they show $0 cost basis."
That person doesn't know what they want. They just know what's happening to them. And what's happening to them is the product brief.
Wants are aspirational. Suffering is specific.
The gap matters because specificity is what makes a product real.
"I want better financial tools" is not a product. It's a direction. You can build a thousand things in that direction and most of them will miss.
"I missed the 0% interest deadline by one day and they're now charging me interest from day one on the full original amount" — that's a product. That sentence tells you the user, the trigger, the stakes, and the exact moment the pain lands.
"Miss the 0% deadline by even one day and they charge you interest from day one on the full original amount."
The upvotes are the signal. 180 people saw that post and felt something — recognition, dread, the specific memory of their own version of this moment. That's not a survey. That's a validated problem.
Where suffering actually lives
People don't go to survey forms when they're suffering. They go to places where venting is socially acceptable — where they can be heard by other people who understand.
Reddit is the most obvious one. Not the front page. The subreddits. r/personalfinance. r/CryptoTax. r/smallbusiness. r/ADHD. r/legaladvice. The places where someone posts at 11pm because they can't sleep and they need to know if anyone else has dealt with this.
App Store reviews are the other goldmine — specifically 1-star and 2-star reviews of software that's close to solving a problem but doesn't quite get there. Someone who leaves a 1-star review isn't just complaining. They're telling you exactly what the existing solution got wrong and what they still need.
Forum threads. Facebook groups. Discord servers. The common thread: unfiltered, high-stakes emotional disclosure about a specific problem. These are the places where people say things they'd never say in a formal interview because they're not performing — they're just frustrated.
Why traditional validation methods miss this
Customer interviews are useful. Surveys are useful. But both have a structural problem: they ask people to introspect on demand about things they might not have fully processed.
When you ask someone in an interview "what's your biggest challenge with X?", they give you a considered, professional answer. They'll mention the things they've thought about. They'll filter out the things that feel too specific, too personal, too embarrassing to say out loud to a stranger.
But on Reddit, at midnight, anonymous? The filters come off.
"When the agent says the call is being recorded, that's their notice. Continuing the call counts as your consent. There is absolutely nothing you can do about this legally and most people have no idea."
5,300 upvotes. That's not a feature request. That's 5,300 people saying "yes, this has happened to me and I had no recourse." The product brief writes itself.
The mental shift: from "what do people want?" to "what are people enduring?"
This reframe changes how you research.
Instead of starting with a hypothesis and validating it, you start by listening for patterns. You're not looking for people who say "I wish someone would build X." You're looking for the same complaint appearing across different people, different times, different phrasings — a signal that the problem is real and recurring and unresolved.
The three things to look for:
High engagement, no solution in the replies. If a post about a problem has 800 upvotes and every reply is "yeah that happened to me too" with no one linking to a tool that fixes it — that's a gap.
Recurring frustration. If you find the same complaint in 10 different threads across 6 months, the problem isn't a one-off. It's structural. Someone will build this eventually. It might as well be you.
Stakes. The best problems have real consequences — financial, legal, professional, health. "My app is slightly slow" is annoying. "I might owe $40,000 in taxes I don't actually owe because my exchange reported $0 cost basis" is terrifying. The higher the stakes, the more motivated the buyer, the more they'll pay.
Why most founders skip this step
Spending a week reading Reddit threads before writing a line of code feels wrong. It doesn't feel like building. It feels like research, and research is something you did in school, not something you associate with shipping products.
So founders shortcut it. They brainstorm ideas. They ask their friends. They look at Product Hunt for inspiration. They come up with something that sounds reasonable and start building.
Three months later they have a product and no users, and they're confused because they followed the advice. They built something. They thought people wanted it. Why isn't it working?
It isn't working because "sounds reasonable" is not the same as "real pain." Real pain has evidence. It's documented. It's public. It's been upvoted by thousands of people who wished someone had already solved it.
The research isn't the slow part. Skipping the research and rebuilding after you've launched is the slow part.
What this looks like in practice
You don't need a methodology. You need a filter and some patience.
Pick a category you care about — finance, health, productivity, legal, whatever. Find the relevant subreddits and App Store categories. Read 50 posts. Note the ones where people are upset, specific, and getting no good answers.
Then ask: is the same complaint showing up multiple times? Do the replies say "same" more than they say "try X"? Are the stakes high enough that someone would pay to fix this?
If yes: you have a real problem. The product is what solves it.
That's a different question than "what do people want?" It's harder to answer, because it requires you to go find the evidence instead of asking someone for it. But the evidence is already out there — public, searchable, sorted by upvotes, freely available to anyone who bothers to look.
Most founders don't look. That's the gap.
This is the research behind every idea in Nicheloom. We read the threads, track the upvote counts, source the exact quotes, and identify the gaps where the complaints are loud and the solutions don't exist yet. If you'd rather skip to the building part, browse the ideas →