Should you talk to customers before building an MVP?

Talk to customers first. Then build the smallest possible thing that solves the problem you confirmed is real. Building before talking is the most common way founders waste months solving a problem nobody has—a mistake Paul Graham made himself when he built software for art galleries that didn't want to be online.

Why building first is the riskier bet

The intuition to build feels productive. Code is tangible; conversations feel soft. But this intuition inverts the actual risk profile of an early startup. The costliest mistake you can make at the pre-MVP stage isn't writing bad code—it's writing good code for a problem that doesn't exist or doesn't hurt enough to pay for. Paul Graham's point about working on problems you personally experience is fundamentally about evidence: if you feel the pain yourself, you have at least one confirmed data point before you write a single line.

The failure mode is building a mental model of the world and coding to that model without checking whether it maps to reality. Founders routinely spend three to six months building something, then discover at launch that the people they built it for don't recognize the problem the way the founders framed it, use different workflows entirely, or already have a workaround they're happy enough with. Customer conversations before building compress that feedback loop from months to weeks or even days.

This doesn't mean you need perfect information before starting. It means you need enough signal to confirm: (1) the problem is real and felt, (2) the people who feel it are reachable and represent a coherent market segment, and (3) they currently solve it in a way that leaves them genuinely frustrated. Those three confirmations are the actual job of early customer discovery.

What 'talk to customers' actually means in practice

Talking to customers isn't running a survey, posting a tweet, or asking friends if your idea sounds cool. It's sitting—physically or on video—with people who match your target user profile and watching how they currently handle the problem you think you're solving. The goal is not to pitch; it's to surface the gap between how the problem actually lives in their day and how you imagined it.

Concretely: identify 10–20 people who plausibly have the problem. Reach them through direct outreach, communities, LinkedIn, or mutual introductions—not a signup form you hope they find. Ask them to walk you through the last time they dealt with this problem. Listen for the language they use, the workarounds they've stitched together, and the moments of friction they mention almost in passing. Those offhand comments are often where the real pain lives.

Don't ask hypothetical questions like 'Would you use a tool that did X?' Hypothetical answers are worthless because people are notoriously bad at predicting their own behavior. Ask about past behavior instead: 'How did you handle this last time? How long did it take? What did you try first?' The difference in signal quality is enormous. After 10–15 of these conversations, patterns emerge: either the same language and frustrations keep surfacing (strong signal), or every person describes a different problem in a different context (weak signal, pivot the hypothesis).

When the MVP comes in—and why it should be embarrassingly small

Once you've confirmed a real problem with a reachable group of people who feel it acutely, you build—but you build the minimum surface area required to test your core hypothesis, not a complete product. The MVP is not a prototype of your eventual product; it's an experiment designed to answer one specific question: can you actually deliver meaningful relief from the pain you confirmed?

Paul Graham's observation about Airbnb illustrates this well. The founders didn't automate their way to early traction—they went out and manually engaged users in person during the critical early weeks. The lesson isn't that you should do everything manually forever; it's that doing things that don't scale is often how you learn what eventually needs to scale. Your MVP should be optimized for learning, not efficiency.

In practice this means the MVP might be a manual service disguised as software, a single-feature tool that does one thing unusually well, or even a landing page plus a direct sales process. The question to ask before building any feature is: 'What am I trying to learn, and is this the fastest way to learn it?' If you can answer the question with a spreadsheet and a Zoom call, don't build the feature yet. Save the engineering time for when you have enough evidence to be confident you're solving the right problem in the right way.

The feedback loop: keep talking while you build

Customer discovery doesn't end when the MVP starts. The founders who get the most out of early-stage building treat the first users as collaborators, not just validators. The feedback quality you get from a handful of deeply engaged early users is categorically better than what you'll get from thousands of passive ones later—a point Graham makes directly about the irreplaceable value of watching real users interact with your product when there are only a few of them.

This means setting up direct lines to your first users: their personal email, a shared Slack channel, a standing weekly call. When something breaks or confuses them, you want to hear about it within hours, not discover it in an aggregate churn metric three months later. Many founders resist this level of closeness because it feels unsustainable. It is unsustainable at scale—but that's fine. You're not at scale. The habits of attention and directness you build with early users shape the product instincts that carry you forward.

The practical sequence looks like this: talk to customers to confirm the problem → build the smallest thing that tests your solution → put it in front of those same customers immediately → watch them use it and listen to their reaction → revise → repeat. This loop, run tightly and honestly, is how you avoid the trap of building for months only to find out your assumptions were wrong. The founders who get stuck are usually the ones who treat each phase as discrete: discovery first, then build, then launch. In reality the loop never stops—it just gets faster as you get better at running it.

“The very best startup ideas tend to be something the founders themselves want, that they can build, and that few others realize are worth doing.”

— Paul Graham, source

“I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.”

— Paul Graham, source

The one thing to do

Before writing a line of code, schedule 10 in-person or video conversations with people who have the problem you want to solve, and listen for the friction they describe—then build only what directly addresses what you heard.

Frequently asked questions

How many customer conversations do you need before building?

Aim for 10–15 in-depth interviews with people who genuinely match your target user. You're looking for repeating patterns in language and pain—if you're hearing the same frustration unprompted across different people, that's your signal to start building.

What if my idea is technically complex and hard to prototype quickly?

Separate the technical complexity from the customer discovery. You can confirm that a problem is real and painful—and that people would change their behavior to solve it—without building the actual technology. Use mockups, manual processes, or wizard-of-oz demos to test demand before committing engineering time.

Isn't there a risk that competitors will copy my idea if I talk about it too much?

For early-stage startups, obscurity is a much bigger threat than copying. The founders who protect their idea too fiercely often end up building something nobody wants in secret. Execution, timing, and distribution matter far more than the idea itself.

Can I talk to customers and build at the same time?

Yes, and once you've cleared the initial discovery phase, you should. The key is maintaining a direct feedback loop with real users throughout the build—not just doing discovery once and then disappearing into the product for months.

Sources

More playbook answers · Growth Prophet home