Customer Discovery for Indie Hackers: How to Talk to Users Without Wasting Time

Most indie hackers either skip customer discovery entirely or do it wrong. The ones who skip it build the wrong thing. The ones who do it wrong spend weeks in conversations that produce no useful signal and then use that experience as evidence that “talking to users doesn’t work.” Customer discovery does work — when you’re clear on what you’re actually trying to learn and you run the conversations correctly.

Here’s how to do it as a solo founder with limited time.

Why Solo Founders Skip Customer Discovery (And Why That’s a Mistake)

The rationalizations are familiar: “I’m my own target customer, so I already know what I’d want.” “I don’t want to invalidate my idea before I’ve built it.” “I don’t know how to find people to talk to.” “I’ll do this after I launch.”

The first rationalization is the most dangerous. Being your own target customer means you understand the problem from one angle. It doesn’t mean you understand how other people describe the problem, what solutions they’ve already tried, what price point they’d accept, or what objection would stop them from paying. You are one data point. One data point is not a market.

The “after I launch” approach has a predictable failure mode: you build something for four to six months, launch it, get minimal traction, and then you’re trying to understand why it’s not working while managing the emotional weight of sunk cost. Starting customer discovery before you build is cheap — it costs a few hours. Starting it after six months of development is expensive, because by then you have beliefs built into the product that are hard to challenge honestly.

The real reason most people skip discovery: rejection feels bad, and talking to strangers about your idea feels like inviting rejection. The reframe that actually helps: you’re not pitching, you’re researching. You’re not asking people to validate your idea. You’re asking them to explain how they currently handle a problem. That’s a genuinely easy ask for most people, and it puts you in a listening role rather than a selling role.

Before getting into tactics, make sure you understand what you’re validating — the how to validate your app idea before building piece covers the upstream question of whether you have a real problem worth solving at all.

Finding People to Talk To When You Have No Network

The biggest practical obstacle is finding people. Here are the methods that work without an existing audience:

Reddit and niche communities. Find subreddits where your target customers spend time. Don’t post your idea. Post a question about the problem: “I’m trying to understand how [target users] currently handle [specific task]. Would anyone be willing to spend 20 minutes on a call?” Offer a $20 Amazon gift card if you have the budget. Expect a 5-10% response rate from a good post. Three responses from 40 views is a win.

Twitter/X and LinkedIn. Post an observation or question about the problem space — not your solution — and ask if anyone dealing with it would share their experience. Specific and relatable framing gets responses; generic “would you use a tool for X” posts get ignored. “How do you currently track client invoices when you’re running a solo consulting practice?” outperforms “anyone interested in a new invoicing tool?” by a wide margin.

Personal network extended one degree. You probably know people who know your target customers. “I’m trying to talk to small business owners who do their own bookkeeping — do you know anyone who might spend 20 minutes with me?” Most people will make this kind of referral because it asks nothing of them. It just asks something of the next person in the chain, and that person has opted in by agreeing to the call.

Niche Slack groups and professional communities. Most professional niches have active communities. Join them, be a genuine participant for a couple of weeks, then ask for research conversations. Lurking for two weeks before asking is not a waste of time — it’s relationship credibility that makes your ask succeed.

You need 10 to 15 conversations before patterns start emerging. Do not try to draw conclusions from 3 interviews. Three is noise. Ten is a data set.

The how to get beta testers for your app post goes deeper on recruiting once you have a product to test — discovery interviews are the precursor to that step, and the same audience recruitment methods apply.

The Questions That Surface Real Insights

The structure that works best — adapted from Rob Fitzpatrick’s The Mom Test — prioritizes past behavior over hypothetical future actions.

Never ask “Would you use this?” People say yes to be helpful. It means nothing about whether they’ll actually pay for or use a product.

Always ask “Walk me through the last time you dealt with this problem.” Past behavior is real. What people actually did tells you more than any prediction of what they’d do.

Build every conversation around these five questions:

“Tell me about the last time you [had this problem]. What happened?” This establishes that the problem is real and recurring, in their words. If they can’t think of a recent example, that tells you something important.

“What did you do about it?” This reveals your actual competition — which is almost never another software product. The real competitor is usually a spreadsheet, a manual workaround, or simply ignoring the problem. Knowing the incumbent solution shapes everything about how you build.

“What was frustrating about that?” This surfaces the specific pain points in the existing solution. These become your product’s most defensible differentiators, because they came from the user’s mouth, not your assumptions.

“How often does this come up?” Frequency matters enormously. A painful problem that occurs twice a year is a fundamentally different business than one that happens every day. Daily problems can command subscriptions. Annual problems struggle to justify anything beyond a one-time payment.

“How much is this currently costing you — in time, money, or stress?” This is the question that tells you whether people will pay for a solution and gives you a rough ceiling for pricing. If someone says “it costs me about three hours a week and I bill at $150/hour,” you have a number to work with.

Do not pitch during these conversations. Do not describe your solution until the very end, if at all. The moment you start selling, the person starts reacting to your pitch instead of describing their actual experience. Ask questions, listen, and follow up on specifics rather than moving to the next question. “You said that was frustrating — can you say more about what frustrated you?” is often the most valuable thing you can ask.

The Struggling Entrepreneur newsletter covers the product and customer development side of building solo every week — practical, not academic, from people running real products.

Turning Insights Into Product Decisions You Can Trust

After 10-15 conversations, you have enough to synthesize. Here’s how to turn the raw material into decisions:

Find the recurring language. Pay attention to the specific words people use to describe the problem — not your words, theirs. If eight of your fifteen interviewees say “I lose track of X” or “I never know if X is accurate,” those phrases belong in your landing page headline and your product copy. You don’t have to guess what resonates. They told you.

Map the current solution precisely. What are people actually doing today? “Nothing” or “I just ignore it” is a red flag — it usually means the problem isn’t painful enough to pay for fixing. “A complicated spreadsheet I built myself and maintain every week” or “I pay a contractor $400 a month to handle this” is strong signal that people are already paying in time or money to solve this.

Identify the real job being done. Most products fail because they solve the surface problem rather than the underlying job. Someone who wants to track freelance invoices isn’t really looking for invoice tracking — they’re looking for confidence that they’ll get paid and peace of mind that nothing slipped through. Build for the underlying job, not the surface feature.

Rank your assumptions by risk. Every product rests on a set of assumptions. After your interviews, write down your three most critical ones — people will pay for this / they have this problem frequently enough / existing solutions are inadequate — and assess whether your conversations support or challenge each one. Update your plan based on what the data actually says, not what you hoped it would say.

The output of customer discovery isn’t a feature list. It’s clarity on who exactly has this problem, how much it costs them, and what they’re currently willing to do about it. With that clarity, you build something with a real chance. Without it, you’re building on hope — which is not a product strategy.