TL;DR: The fastest way to validate a startup idea isn’t coffee chats or landing pages — it’s finding existing conversations where real people already talk about the problem. Here’s the 3-step framework, with real examples from CrossMind’s own validation process.
You’ve got an idea. It feels solid. You’re thinking about spending 3 months building it.
Before you do, you want to validate it. So you follow the standard advice: grab 5 coffee chats with “potential users,” build a landing page, maybe run an MVP. You’ll know if it’s worth building, right?
This approach fails almost every time. Not because validation is bad, but because it’s testing the wrong thing.
Why standard validation advice doesn’t work
When you ask someone “Would you use this?” they say yes. When you show them a landing page, they click. When you build an MVP, maybe even some free users show up. All signals look green.
Then you launch and hit silence.
Here’s what’s actually happening:
Coffee chats lie. People are polite. They don’t want to tell you your idea is bad, so they say it sounds interesting. A few months later, they still haven’t signed up. You validated politeness, not demand.
Landing pages test copy, not need. Clicks mean your headline is compelling. They don’t mean people actually have the problem you’re solving, or that they’ll pay for it.
MVPs come too late. By the time you’ve built something functional, you’ve already sunk weeks of time and belief into the direction. Confirmation bias takes over. You stop looking for evidence that it won’t work.
The real validation question isn’t “Do people like this idea in conversation?” It’s “Are people already talking about this problem in places where you’re not involved?”
You can run that test before you write a single line of code.
How community signals predict demand
People validate ideas in communities constantly. They just don’t call it validation.
On Reddit, someone posts about their tool workflow and gets 200 replies about the pain. On Twitter, a thread about “I wish there was X” gets 50 retweets and dozens of “same” replies. On indie forums, people ask for recommendations on a specific problem, and the thread runs 10 pages. On Hacker News, “how do you solve Y?” makes the front page.
Those are demand signals. Real people, real problems, real frustration — with no politeness filter.
You don’t have to build anything to find them. You just have to look in the right places.
The community validation framework (70 minutes total)
Step 1: Find where the pain lives (20 minutes)
Your job isn’t to guess where your users hang out. It’s to find where they’re already gathering to talk about the problem.
Building for productivity? People are in r/productivity and r/timemanagement. Building for indie hackers? They’re on Indie Hackers, Twitter, and specific Discord servers. Building for designers? r/design, Designer Hangout, niche Slack groups.
Start specific. “Where would someone go if they had this exact problem and wanted to talk about it?”
Search that space and look for threads from the last 2 weeks. Recency matters. A 2-year-old thread about a pain point doesn’t tell you if it’s still a priority.
Step 2: Count the demand signals (30 minutes)
For each community where you found activity, count three things:
Volume. How many recent threads mention this problem? Finding 0-1 posts per week is weak. Finding 5-10 is real. Finding 20+ is loud.
Engagement. Are people just posting and leaving, or are others replying, asking follow-ups, sharing their own versions of the problem? Deep engagement — 10+ replies per thread — means it’s top-of-mind.
Specificity. Are people describing a vague problem, or getting into details? “I need better project management” is vague. “I need better project management for client work that doesn’t force me to add every client to my workspace” is specific. Specificity means real constraint, not theoretical annoyance.
If your idea hits all three — 10+ threads per week, full reply sections, detailed problem descriptions — you’ve got a real signal.
Step 3: Validate your angle (20 minutes)
Now you know the problem is real. Your next question: are you solving it the way they’d actually want?
Read the language people use. What words do they use to describe the problem? What solutions do they already mention trying? What do they complain about with those solutions?
If you’re looking at threads about “marketing automation” and everyone’s complaint is “tools are too expensive for small businesses,” your angle is affordable. Not faster, not more features — affordable.
If the complaint is “too complicated,” your angle is simplicity. If it’s “can’t integrate with X,” your angle is integrations.
The community tells you your positioning before you build it. Use their exact language in your copy later — it already resonates with them.
What this validation actually proves
After running these steps, you’ve validated something specific:
People have the problem and talk about it openly. They’re frustrated enough to discuss it repeatedly. You understand what language and angles already land with them.
You haven’t validated that they’ll pay. You haven’t validated that your specific solution will work. But you’ve validated that you’re not chasing a phantom problem.
That’s worth 3 months of build time.
What CrossMind’s own validation looked like
When CrossMind was figuring out whether builders actually struggled with “launched to crickets,” we didn’t survey anyone. We went to Reddit, Twitter, and Indie Hackers and looked for the actual pattern.
We found hundreds of posts. r/Entrepreneur threads from people who’d shipped and hit zero users. Indie Hackers posts asking “where did you get your first users?” with 50+ replies. Twitter threads hitting 100+ likes on “building is easy, distribution is impossible.”
The pattern wasn’t a hypothesis. It was visible. Real frustration, real volume, real specificity.
That’s how we knew the problem was worth solving.
Later, we’d run 69 cold DMs to who we thought was our ICP and hit 0% reply rate. Turns out we were wrong about where they actually gathered. When we scanned communities properly, we found them in different places entirely — and conversion went from 0% to 33%. Community research wasn’t just validation; it corrected our assumptions about the audience.
The validation worked because we looked where the problem actually lived, not where we assumed it would be.
When community validation isn’t enough
Community signals tell you demand is real. They don’t tell you everything.
If you want to validate willingness to pay, you still need direct conversation — but now you’re talking to people who’ve already shown they care (they posted about it). That’s a different conversation than cold coffee chats with someone doing you a favor.
If you want to validate a specific solution, feedback from community members is worth more than general feedback because they understand the problem deeply. They live in these communities.
Community validation doesn’t replace talking to users. It just makes those conversations 10x more valuable because you’re talking to the right people.
The real validation question
Before you build anything, ask: “Can I find 20 recent, detailed posts where real people describe this problem?”
If yes, you’ve got a signal worth acting on.
If no, you might be solving a phantom problem — or looking in the wrong communities.
Most founders skip this step and build first. The information is sitting in public communities right now, free to access, before you commit a single day to building.
Related reading: Once you’ve validated demand, the next problem is turning it into real users. See the early adopters channel map for a breakdown of which platforms to target first. If you’re in pre-launch mode, how to find beta users before you launch covers the pipeline in detail. Already shipped and wondering what happened? This distribution checklist covers the post-launch diagnosis. And if you want the full picture on what it took to find the first 100 users after all of this, here’s that breakdown.
If Reddit is your top channel, the Reddit startup guide covers what actually works without risking your account.
Want to skip the manual scanning? CrossMind’s Onboarding research loop maps where your users are in 30-40 minutes. See how it works.