Customer discovery without interviews: using community posts instead

Customer interviews are the gold standard of early-stage research. They're also slow, biased toward people willing to talk, and contaminated by social desirability, the tendency for interviewees to tell you what they think you want to hear.

There's a faster, less biased alternative: reading what people write in communities when they have no idea you're watching.

This isn't a replacement for interviews. It's a front-end filter that lets you go into interviews knowing what you already know, so you spend the interview confirming hypotheses rather than building them from scratch.

Why unprompted community posts beat interview responses

When someone interviews with you, they know it's research. They construct a coherent narrative. They're polite. They understate frustration to avoid seeming unreasonable. They overstate interest in your idea to be encouraging.

When someone posts on Reddit or in a community forum, they're talking to peers. They're not aware of being studied. They're fully authentic about how annoying their problem is, how much they've spent trying to fix it, and whether existing tools helped or failed.

This authenticity is exactly what you need at the earliest stage of validation, and it's available without scheduling a single 30-minute call.

What to look for in community posts

The bing.ly Ideas tool surfaces four types of signals that map directly to the questions you'd ask in a customer interview:

Pain points → "What problem are you trying to solve?", the interview's opening question, answered publicly at scale

Buying signals → "How are you currently solving this? What do you pay for it?", the budget and alternatives question

Feature requests → "What would make your current solution better?", the gap identification question

Solution requests → "What would a perfect solution look like?", the ideal product question

Running these filters over a broad community search gives you the equivalent of a hundred preliminary interviews in the time it takes to read for an hour.

How to build a hypothesis document from community research

Before you start interviews, spend two to three hours reading community posts in your problem space. As you read, document:

1. The top three pain points, phrased in the exact language community members use
2. The jobs people are hiring existing solutions for, what they're using now and why
3. The recurring complaints about existing solutions, where current tools fall short
4. The ideal-state descriptions, what people say they wish existed

This document is your interview guide. You've already answered the background questions. The interviews become confirmation sessions and depth dives, you ask "I noticed a lot of people online describe this frustration, does that match your experience?" instead of starting from zero.

The cold start problem

Early in a market, community discussion may be sparse. This is itself a signal: if there are very few posts about a problem, it's either niche (few people have it), solved (people aren't struggling anymore), or prematurely framed (you're using the wrong search terms).

Try searching the problem from multiple angles, the symptom, the context, the tools people use around it. The bing.ly feed pulls from multiple platforms, so a problem invisible on Reddit might appear clearly on Hacker News or in App Store reviews for related tools.

When to do interviews anyway

Community research is excellent for breadth. Interviews are better for depth. After your community research phase, you'll have a clear picture of who your target user is and what they need. That's the moment to do interviews, not to discover the problem, but to understand the nuance.

Specifically, you want interviews to answer questions community posts can't: the exact workflow context, the team dynamics, the budget approval process, the switching costs. These are organizational details that rarely appear in public posts but matter enormously to whether your product fits.

Use community research to build the hypothesis. Use interviews to stress-test it.