How Indie Developers Conduct User Interviews: 5 Questions That Reveal Product Direction

The Cost of Building in the Dark

Every indie developer has that one project sitting abandoned on GitHub. The one you spent 3-6 months building, polished to perfection, launched with a Product Hunt post and a Twitter thread—and nobody cared. No signups. No paying customers. Just crickets.

You didn't fail because your code wasn't good enough. You failed because you solved a problem nobody actually had, or that they solved well enough with a spreadsheet and some grit.

The antidote is user interviews. Done right, 10-15 conversations with target users can tell you everything you need to know before you write a single line of code. YC's data shows that founders who do at least 10 customer interviews in pre-seed are 3.2x more likely to find product-market fit. For solo developers with limited runway, that number is even more critical.

Finding Your First 10 Interviewees

Create a Hyper-Specific User Persona

Before you start finding people, write a paragraph so specific it feels uncomfortable:

"SaaS indie developer earning $50K-$200K ARR, solo or with one contractor, manages code/product/support alone, feels overwhelmed by customer support tickets while trying to ship features."

Not "entrepreneurs." Not "developers." A specific person with a specific job and specific pain.

Where to Find Them

The Cold Outreach Template

"Hi [Name], I'm researching how [industry] people handle [pain point], and I noticed your insights on [topic]. Would you be open to a 15-min chat about your experience? I'll share the research findings with you as a thank-you."

Key principles:

• Give them a reason (research value)
• Set a low time expectation (15 min)
• Offer something in return
• Be direct about what you want

Expect a 10-20% response rate on cold outreach. Start with 50 messages to get 10 conversations.

The 5 Questions That Matter

These questions are ordered deliberately. Each one builds on the last, creating a narrative arc that reveals real behavior—not hypotheticals.

Question 1: "Walk me through the last time you had to [deal with this pain point]."

Why this works: People are bad at describing their general behavior, but they can tell a specific story. Stories contain emotions, timelines, decisions, and numbers—the raw data you need.

Follow-ups:

• "What happened next?" (reveals process pain)
• "What did you try first?" (reveals current solutions)
• "How did it end?" (reveals satisfaction level)

Don't ask: "How do you usually handle this?" — people lie about habitual behavior. Always ask about the last specific instance.

Question 2: "How big of a problem was this for you?"

Why this works: You need to calibrate pain severity. If they say "annoying but manageable," that's a yellow flag. You want to hear "it's killing my productivity" or "I lost money because of this."

Quantification follow-ups:

• "How many hours per month does this cost you?"
• "What's the financial impact?"
• "On a scale of 1-10, how painful is this?"

Threshold: If the average score is below 8, be very careful. People don't pay for "mildly annoying" problems.

Question 3: "What do you currently use to deal with this?"

Why this works: This reveals your competition—including the option of doing nothing. Each response tells you something different:

Question 4: "If a tool could [core value proposition], how much would you pay per month?"

Why this works: Price validation is the most critical interview signal. Get them to name a number before you suggest one.

Set the anchor first:

• "How much are you spending on this problem today?"
• "Include tools, services, and your own time"

If they say $0, ask: "What if I told you it costs $29/month? Would you pay for it or keep your current solution?"

Threshold: Their stated willingness-to-pay should be at least 3x your per-user cost.

Question 5: "Describe your ideal solution."

Why this works: Let the user be the product manager. Their description reveals feature priorities, workflow expectations, and integration needs.

Specific follow-ups:

• "If the product could only do three things, what would they be?" (MVP feature prioritization)
• "What existing tools would you want it to integrate with?" (ecosystem strategy)
• "Browser, desktop, or mobile?" (platform decision)

Analyzing Interview Results

After 10-15 interviews, use this framework:

Signal Strength Matrix

Pattern Detection

Go through your notes and look for:

• Repeated stories: At least 3 people describing the same scenario? That's validation.
• Repeated complaints about competitors: 3+ people hating the same tool? Market gap confirmed.
• Repeated feature requests: 3+ people asking for the same thing? That's your MVP feature.

Red Flag Checklist

• ❌ All feedback is positive (you're interviewing friends or being too leading)
• ❌ Everyone says "I'd use it" but nobody says "I'd pay for it"
• ❌ Pain severity averages below 6/10
• ❌ Willingness-to-pay is under $10/month
• ❌ You can't find people to interview (means you can't find customers to sell to)

Common Interview Mistakes

Mistake 1: Asking the Wrong People

If you interview people who aren't your target segment, every signal is noise. Verify upfront: do they have the pain? Do they have budget? Can you reach more people like them?

Mistake 2: Leading Questions

Wrong: "Do you think this feature would be useful?" Right: "Walk me through your current workflow for [task]."

People are polite. If you present an idea, they'll say "that sounds great" even when they'd never use it.

Mistake 3: Confirmation Bias

You want your idea to be good, so you subconsciously steer conversations toward validation. Combat this by:

• Having someone else conduct 1/3 of your interviews
• Writing down your hypothesis BEFORE the first interview
• Paying extra attention to negative signals

Mistake 4: Interviewing Friends

Friends are supportive. Friends give positive feedback. Friends don't represent a real market. If 30% of your interviews are friends, discount those results by 50%.

Building a Continuous Interview Practice

User interviews aren't a one-time thing. Build them into your workflow:

Tools to Make It Easy

When You Know You're Ready to Build

After 10-15 interviews, you should be able to answer:

1. Pain severity (1-10) — confirmed by real stories
2. Current alternatives — and why they're inadequate
3. Willingness-to-pay — in specific dollar amounts
4. Top 3 MVP features — prioritized by user demand
5. First channel to find customers — validated by where you found interviewees

If all five are clear, start building. If any one is fuzzy, do another round of interviews. One week of talking to users beats three months of coding for nobody.