The cheapest, highest-return thing you can do before building software is talk to the people who have the problem. Done right, customer discovery interviews save you from building the wrong thing. Done wrong, they give you false confidence. Here is how to do them right.
The short answer
Interview 20 to 30 people who actually have the problem. Do not pitch your idea, ask about how they handle the problem today, what frustrates them, and what they have tried. Listen for a repeating, painful, expensive pattern. That pattern, not enthusiasm for your concept, is the signal.
Who to interview
People who currently live with the problem you want to solve. Be specific: not "small business owners," but "owners of 10 to 50 person logistics firms who process dozens of invoices a week." The sharper your target, the more useful the answers. Find them through your network, communities, LinkedIn, or relevant forums.
What to ask
Ask about their world, not your idea:
- "Walk me through how you handle this today."
- "What is the most frustrating part of that?"
- "How much time or money does it cost you?"
- "Have you looked for a better way? What did you try? Did you pay for anything?"
Notice these are all about the past and present, things that actually happened, not hypotheticals about your product.
What not to do
- Do not pitch. The moment you describe your solution and ask if they like it, you get politeness, not truth.
- Do not ask hypotheticals. "Would you use an app that..." predicts nothing. Past behavior does.
- Do not lead. Open questions, then listen more than you talk.
How to read what you hear
You have a real signal when the same painful, frequent, costly problem shows up again and again, and people are already spending time or money working around it. You have a warning sign when you have to convince people the problem exists, or their current workaround is "fine."
From interviews to a build
Validation tells you whether to build; interviews are how you do it. Once the pattern is clear, the next step is turning what you heard into a concrete product, which is where most founders stumble (see how to turn interviews into requirements). A product simulation picks up there: it turns your validated understanding into a documented, runnable foundation, so the leap from "people want this" to "here is the product" is fast and grounded.
Done validating and ready to build? Start a project.
Frequently asked
How many interviews do I need?
Aim for 20 to 30 with people who genuinely have the problem. You are looking for a repeating pattern, not a single yes. Stop when new conversations stop teaching you anything new.
Won't people just tell me what I want to hear?
They will if you pitch your idea. Avoid that. Ask about their past behavior and current workarounds, not whether they like your concept. What people do is far more reliable than what they say they would do.