← Writing

Ten Conversations and One Decision

The gap between you and a founder is not knowledge, not tools, not a better idea. It's ten conversations with people who can tell you the truth, and one honest decision about what the answers mean.

I used to think the thing standing between me and a real product was technical. A better stack. A cleaner architecture. A more reliable prompt chain. If I could just get the system right, the product would follow.

I was wrong about what was missing. It wasn't technical skill. I had plenty of that. What was missing was ten conversations.

Not hypothetical conversations. Not surveys. Not "I asked my friend and he said it was cool." Ten real conversations with people who have the problem you think you're solving, conducted in a way that lets them tell you the truth instead of what you want to hear.

That's it. That's the gap.

Why ten

One conversation is an anecdote. You'll hear what you want to hear. You'll leave convinced your idea is right because one person nodded.

Three conversations start to show you the variance. The first person's problem isn't the same as the third person's problem, and now you're not sure which one you're solving. This is uncomfortable. It's supposed to be.

By five, a pattern starts to form. Not the pattern you expected. A different one. The problem you thought was the problem is actually a symptom of something deeper, or something adjacent, or something you hadn't considered. This is where most builders stop, because the pattern contradicts the product they already started building.

By ten, you know something. Not everything. But enough to make a decision that isn't based on your own assumptions echoing back at you. Ten conversations won't give you certainty. Nothing will. But they'll replace the story in your head with something closer to the world outside it.

What counts as a conversation

Not a pitch. The moment you start explaining your solution, you've stopped learning. The other person shifts from describing their reality to reacting to yours, and reactions are polite. Politeness is useless.

A real conversation starts with their life, not your idea. What does their day look like? Where does the problem you're interested in actually show up? What have they already tried? What did they spend money on? What did they try and abandon? What do they do right now, manually, that they wish were easier?

The answers to these questions are worth more than any market research you can buy, because they come with texture. "I've rebuilt my landing page four times because I don't know which of three audiences I'm talking to" tells you something a survey never will. It tells you the person is stuck, has tried, and knows they're stuck. That specificity is the raw material of a real product.

The discipline is asking and then shutting up. Not steering toward confirmation. Not jumping in with "oh, that's exactly what my product does." Just listening until you understand what they're living through well enough that you could say it back to them and they'd go: yes, exactly that.

If you can't describe someone's problem in their own words, you don't understand it yet. And if you don't understand it yet, building a solution is just guessing with extra steps.

The conversation nobody wants to have

Before you talk to strangers about their problems, there's a conversation you need to have with yourself. It's the one I avoided for years and paid for in a graveyard of beautiful unlaunched projects.

The question is: do I actually want this to be a product, or do I just want it to exist?

This sounds simple. It isn't. I built an AI product management tool with 170 frameworks in its knowledge base. I told myself it was a product. If I'm honest, I never wanted the responsibility of users. I wanted the satisfaction of building something impressive. And there's nothing wrong with that. Building for the craft is legitimate. But I was measuring myself against a goal I hadn't actually committed to, and the gap between "I should launch this" and "I want to launch this" was where all the avoidance lived.

Self-honesty about the goal comes before user discovery. You can't validate against a goal you've never admitted you don't have.

If the answer is "I just want it to exist," you're a craftsperson. Enjoy the work. There's no trap to escape.

If the answer is "I want people to use this," then the next step isn't more building. It's the first conversation.

What the conversations will do to your product

They'll break it. That's the point.

I talked to a founder who had spent four months building an AI-powered content calendar. Sophisticated prompt chains. Multi-platform scheduling. Smart repurposing across formats. After her first five conversations with creators, she realized none of them wanted a calendar. They wanted help figuring out what to say. The calendar was the easy, downstream problem. The hard problem was upstream: "I have expertise but I can't turn it into content that sounds like me."

She could have kept building the calendar. It was good. It worked. But it solved a problem that came after the problem her users were actually stuck on. Five conversations told her that. Four months of building hadn't.

Another founder built a beautiful AI analytics dashboard. Clean design, smart summarization, automated insights. After talking to seven potential users, he learned that the people he was building for didn't trust AI-generated insights. Not because the insights were wrong. Because they couldn't see the reasoning. They wanted to understand why the AI said what it said, not just what it said. His entire product was built on an assumption, "people want AI to tell them what to do," that seven conversations revealed was backwards. People wanted AI to show them what was happening so they could decide what to do themselves.

In both cases, the conversations didn't tell the founders they were wrong. The conversations told them they were pointed at the wrong part of the problem. That's a more useful and more common finding than "your idea is bad." Most ideas aren't bad. They're just aimed at the wrong layer.

The one decision

After ten conversations, you have to decide. Not "keep researching." Not "talk to ten more people." Decide.

Three outcomes. Pick one.

Go. The problem is real, people are feeling it, and what you're building is pointed at the right layer. Ship the ugly version. Charge money. See what happens.

Pivot. The problem is real, but you're aimed at the wrong part of it. The conversations showed you where the actual pain is. Rebuild toward that. Then talk to five more people to check your aim.

Kill. The problem isn't what you thought, or the people you talked to don't care enough to change their behavior, or you realized halfway through that you don't actually want to serve this audience. That's not failure. That's ten conversations saving you six months of building something nobody would have used.

The decision has to be real. Written down. With a date on it. "I'll decide when I have more data" is not a decision. It's the build trap in a research costume.

The gap between you and a founder is not knowledge. It's ten conversations and one decision.

Why this is so hard

Because building is safe and conversations are not.

When you're building, you're in control. The code does what you tell it. The interface looks how you want it. The world inside the editor is orderly and responsive and rewards your skill. None of that is true in a conversation with a stranger about whether they care about your work.

In a conversation, you might learn that the thing you spent three months building doesn't matter to anyone. You might learn that the problem you're passionate about isn't a problem other people will pay to solve. You might learn that someone already built the thing and you didn't know. These are all useful things to learn. They're also painful. And building is the painkiller.

I know because I took the painkiller for years. Thirty projects. Thirty times I chose the build over the conversation. Thirty polished, beautiful headstones. Each one proof that I could make things. None of them proof that anyone needed what I made.

I'm not above this. I'm in recovery from it. For years I had a comfortable job, a busy family, and a perfectly reasonable story about why none of these projects needed to launch. Then the job went away, and with it went every excuse I'd been leaning on. No conflicts, no competing priorities, no reason not to. Just me, a full projects folder, and the question I'd been avoiding: was I ever actually going to show this to anyone?

Start today

You don't need a framework for this. You don't need a script. You don't need to read a book about customer discovery, although The Mom Test by Rob Fitzpatrick is short and good and you should probably read it.

You need one person. Someone who has the problem you think you're solving. Someone who isn't your friend, your spouse, or your cofounder. Someone who has no reason to make you feel good about your idea.

Ask them about their life. Ask them where the problem shows up. Ask them what they've tried. Shut up and listen. Write down what they said in their words, not yours.

Then do it nine more times.

Then decide.

That's the whole thing. It sounds small because it is small. The reason it works is the same reason it's hard: it replaces the story in your head with reality. And reality, however uncomfortable, is the only foundation you can build on that doesn't shift.

Related: Where to Find Your Ten — the operational playbook for actually finding these people, week by week. Also: The Build Trap Got Cheaper — why AI made this problem worse. And I Keep Meeting the Same Eight Builders — the eight ways builders avoid this conversation.

Builder's Path is a public lab from Sellhausen AI Systems focused on AI-native building, validation, and product judgment.

Built by Frank Sellhausen · Thinking · Privacy