Two weeks of talking is cheaper than a year of building.
42% of software startups fail due to lack of market need. Most of those founders had talked to customers. They’d just been asking the wrong questions.
Rob Fitzpatrick wrote a book about it: The Mom Test. The core insight: never ask someone whether they like your idea. People are polite. They say yes because they don’t want to let you down — and they mean it, in the moment they say it. But “I would definitely use this” has never saved a startup.
The problem isn’t that you talk too little to customers. It’s that your brain gets in the way. You’re looking for confirmation. You hear what you want to hear. And as long as you don’t ask systematically, everyone will give you exactly that.
Here’s how we approach it.
Finding the right people
Five conversations are enough to see a first pattern. If three out of five people describe the same problem in roughly the same words, you’re onto something. But only if they’re the right five: people in the role you’re building for, at organizations large enough to feel the problem seriously.
Friends don’t count. Existing clients doing you a favor don’t either.
LinkedIn is the fastest route. Search by job title and send a message that’s direct about what you’re doing:
“Hi [Name], I’m doing research into how [target audience] deals with [problem area]. Would you be open for a quick 15-minute coffee chat?”
No product. No features. You’re asking for a conversation, not feedback on an idea. The conversion rate on these messages is higher than you’d expect, especially when the opener feels personal and doesn’t smell like copy-paste. And nobody minds if that 15-minute coffee ends up running for half an hour.
What the conversation looks like
30 minutes, no presentation. Start by taking the pressure off:
“I’m doing research on [topic] and want to understand how you deal with this day to day. Is it okay if I record the call so I don’t miss anything?”
That last sentence matters more than it seems. Record it. With Fireflies.ai or Read.ai you get an automatic transcript and can re-read the conversation objectively afterward. Your own memory selects what you want to hear. A transcript doesn’t.
Then you go into the conversation in three layers.
Their world. What does this person do, what are they measured on, what does success look like for them? Not to be polite, but to understand what the problem means to them in dollars, time, or risk.
The bottleneck. Where do they get stuck most often? What takes disproportionate time or energy? Keep going one layer deeper: why is that hard, what’s the underlying cause, what does it cost if this doesn’t get solved in the next six months?
What they’re doing now. This is the most underrated question in the conversation. If nobody is using anything to work around the problem, the problem is probably smaller than it feels. The strongest signals: spreadsheets that should really be software. External contractors hired for something routine. Processes everyone finds annoying but nobody fixes because there’s “no time for it.”
At the end, only once the pain is clear, you ask the magic wand question. Imagine you have a magic wand and you wave it once and everything is perfectly sorted. What does that look like? What would it be worth to you?
Always close with: “Would it be okay to reach out again in a few weeks once we have a direction?”
Spotting patterns
After each conversation, write a short summary. The most important thing: the JTBD — the Job to be Done. Not what someone asked for, but what they’re actually trying to achieve. People don’t hire a drill, they want a hole in the wall. What’s the hole? Also note: what are the bottlenecks, how urgent is the problem, and are there any signals around willingness to pay?
Use literal quotes. Not your interpretation of what they meant, but exactly what they said. That customer language is what you’ll use later in your product, your marketing, and your pitches.
Upload the transcripts to Dovetail to help you recognize themes across multiple conversations. Or feed them into an LLM like ChatGPT or Claude and ask it to find patterns. Both work well; the point is that you don’t do the analysis in your head, because your head is trying to prove something. After five conversations you’ll know whether you have a pattern or a problem.
If everyone answers differently, your problem framing is too broad. Not the end of the road, but a signal to narrow and start over. Keep having conversations until you stop hearing anything new. In practice that’s somewhere between ten and twenty, depending on how sharp your segmentation is.
Week 2: back to the same people
This is where most how-to guides get it wrong. They recommend building a landing page as proof of interest. For B2B software, that almost never works. Your audience doesn’t click an early access button — they decide in conversations.
In week 2, don’t build a product. Describe a solution.
A mockup, a flow on paper, a few screens in Figma, or just a two-minute story. Go back to the same people and test whether your interpretation of the problem matches their reality: “Based on what you told me, I think the solution would look something like this. Does that resonate?”
What you’re measuring is recognition, not enthusiasm. “Yes, exactly that” is a signal. “Interesting, send me more info” is zero.
The outcome you’re aiming for is a small group of design partners, five at most. These are people who know the problem firsthand, are willing to get involved early in the process, and in return get to use the product at a discount and shape the direction it takes.
If the conversation has gone well and you feel someone is a fit, close like this:
“Based on what you’ve told me, I think you’d be a great design partner. You’ve been working in [industry] for years, you know this problem from the inside, and you understand what a solution would actually need to do in your context. We’re looking for five at most. Would you be interested? And would it be okay if I reached out again once we’re a bit further along, so we can shape the roadmap together?”
They’re not paying yet, but they have skin in the game. And you know you’re building for a real problem, for people who already know you.
What we do with it
This is the first step with every venture we start. We don’t start building until the conversations show there’s something real: an urgent problem, people who are willing to pay for a solution, and an angle sharp enough to build something concrete around.
Sometimes that means a pivot before we’ve designed a single screen. Two weeks that save you months of development.
