Twenty Real Conversations Before You Build Anything

Twenty Real Conversations Before You Build Anything

Before you build a new AI offer or product, have twenty real conversations with potential buyers. Cheap build capacity has made polished over-building the default failure mode, while validation remains scarce. A small proof batch reveals whether the premise deserves a rough build, a change in direction, or a clean stop.

THE VERDICT

Why should conversations come before building?

Because a polished build cannot rescue an untested assumption. In peer rooms we run, the recurring live failure is months of polished building on an assumption twenty conversations would have killed in a week. Operators who validate first are not moving slowly. They are choosing the shortest path to a decision that deserves resources.

AI advice often defaults toward coverage. It suggests more features, more options, and more ways to make a concept feel complete, partly because a generic answer cannot bear the cost of your particular mistake. At the same time, inexpensive build capacity makes it easy to confuse a rapid prototype with evidence that the market wants it.

The scarce skill is validation discipline. You must be willing to put the central belief in front of people who may not agree, then treat their behavior as more useful than your own enthusiasm. Twenty conversations are not a ceremonial customer-discovery exercise. They are a deliberately small proof batch before you commit to a larger build.

THE ASSUMPTION

What exactly are you trying to disprove?

Start with one falsifiable sentence, not a broad aspiration. It should state who has the problem, what they currently do about it, and what change you believe they would make. If the sentence cannot be disproved in a conversation, it is not yet an assumption you can validate.

For example, do not begin with “people need a better way to handle this.” That sentence invites agreement without revealing buying behavior. A usable assumption makes a claim about a real potential buyer’s existing workaround, frustration, current commitment, or willingness to change.

A pattern we keep seeing is that both sides of a market debate eventually concede, “we do not actually know.” That is a productive moment. The next move is a small proof batch, not a larger build intended to settle the argument by force.

One sentence creates a cleaner test.

Write it where the team can see it. If a conversation produces new information, ask whether it weakens the sentence, supports it, or reveals that it was too vague. This keeps the sprint from becoming a collection of interesting anecdotes that never change a decision.

Fish-before-fishing rule. Do not go get the fish before you can show the fish. A rough build is for making a validated promise tangible, not for discovering whether the promise exists.

THE PEOPLE

Who counts as one of the twenty conversations?

Count real potential buyers who could recognize the problem and make, influence, or seriously inform a decision about it. Friends, friendly peers, and people who cannot plausibly encounter the problem can be useful sounding boards. They are not validation evidence, because social incentives make encouragement much easier than candor.

Find people on the side of the market you intend to serve, even when that makes the outreach uncomfortable. The aim is not a representative survey or a collection of compliments. It is to expose the premise to enough current reality that a repeated pattern can emerge.

Keep a simple record after each discussion: what the person does today, what that current behavior costs in attention or commitment, what would have to be true for them to switch, and whether they agreed to a next step. Do not turn the record into a scorecard too early. Its first job is to preserve the words and choices that challenge your premise.

THE QUESTIONS

Which three questions expose the truth fastest?

Ask about past behavior first, because a person’s history is more informative than a hypothetical endorsement. Then ask about current spend or commitment, because the existing workaround reveals what the problem is worth today. Finally, ask what they would need to see before changing, because that separates a vague interest from a real decision condition.

Question	What it reveals	What to listen for
“How have you handled this before?”	Past behavior and the current workaround.	Specific actions, failed attempts, and whether the problem recurs.
“What are you spending or committing to now?”	The present value of solving it.	Existing effort, tradeoffs, and whether the issue has priority.
“What would you need to see to change?”	The evidence threshold for a next step.	Concrete proof, conditions, and who else must be involved.

These are not scripts to recite mechanically. Follow the person’s answers with plain questions that clarify the situation. The discipline is in refusing to pitch your solution before you understand the behavior, commitment, and evidence threshold already in the room.

Be especially careful with leading questions. “Would you use something that solved this?” invites a polite yes and tells you almost nothing. “What did you try the last time this happened?” asks for a fact that can either support or challenge the assumption.

THE DECISION

How do you decide whether to kill, build, or adjust?

At the end of twenty conversations, do not average vague sentiment. Return to the falsifiable sentence and look for repeated behavior. Did real potential buyers describe the problem in a way that matches the premise? Do they already commit attention or resources to it? Did their evidence threshold point toward a rough test you can actually run?

Kill the idea when the premise repeatedly fails. That is not wasted effort. It is the result the conversations were designed to earn, and it is cheaper than a polished product no one needs. Write down what failed so that the next idea begins from a more grounded observation.

Build rough when the pattern is clear enough to make a small, testable promise. Vista’s Good-Enough-For-You framework applies here: make the smallest version that is good enough for this specific buyer, decision, and proof point. Do not optimize for a general audience before you have evidence that a defined one will engage.

Adjust when the problem is real but the buyer, wording, condition, or proposed outcome is wrong. This is often the most useful result. It turns an appealing but weak assumption into a sharper statement that deserves another proof batch before any broad build begins.

THE BUILD

What does “build rough” mean after validation?

Build only enough to let a potential buyer evaluate the promise you just validated. The rough version can expose an experience, demonstrate the key output, or support a small live use case. Its job is to answer the next unknown, not to prove that you can produce a finished system.

This is where builders commonly lose the discipline they had in conversations. They add features to anticipate every objection, polish flows before anyone needs them, and treat a small positive signal as permission to serve every possible buyer. Those additions expand the test before they improve its evidence.

The readiness rule that keeps surfacing is simple: do not go get the fish before you can show the fish. A buyer should be able to see the specific outcome you claim, and you should be able to connect that outcome to what the twenty conversations revealed. If you cannot, return to the assumption rather than expanding the build.

For a useful companion on keeping the prototype proportionate, see build the rough AI tool that is good enough for you. The same discipline helps avoid demand-generation theater, as explored in when paid advertising is premature.

THE GUARDRAIL

When does this rule become paralysis?

This is a validation rule for new offers and products, not a ban on small experiments. If a small internal test has a bounded cost and can generate evidence quickly, run it. The problem is not action. The problem is treating a substantial build as the first method of discovering whether the central assumption was true.

You also do not need to wait for every conversation to sound identical. Markets are messy, and useful ideas may surface through disagreement. The question is whether the differences reveal a coherent segment and testable promise, or simply show that you have not identified a buyer and problem clearly enough.

When an owner needs help separating an attractive idea from the real constraint, Vista’s matchmaking process offers a structured starting point. The work is not about adding procedural friction. It is about earning the right to spend build capacity on something that real people have helped define.

FREQUENTLY ASKED QUESTIONS

Frequently asked questions

Why twenty conversations instead of a larger research project?

Twenty is a small proof batch, not a claim of statistical certainty. It is enough to put a new assumption in front of repeated real-world conditions before a substantial build begins. The purpose is to identify a clear pattern, a failed premise, or a sharper question quickly enough to change the next move.

Can conversations with current customers count?

They can count when those customers are genuine potential buyers for the new offer and can speak to the problem independently. Do not count them merely because they know you or want to be supportive. The conversation needs to test current behavior, commitment, and decision conditions relevant to the proposed product.

What if people say they like the idea?

Treat interest as a prompt for a better question, not evidence by itself. Ask what they have done about the problem before, what they commit to now, and what they would need to see before changing. Specific past behavior and a concrete next step carry more weight than a friendly endorsement.

When should I kill an idea?

Kill it when real potential buyers repeatedly fail to recognize the problem, lack any meaningful current commitment, or cannot identify a condition under which they would change. Record what you learned before moving on. Ending an unsupported premise is a successful validation result, not evidence that the conversations were wasted.

What does Good-Enough-For-You mean in this process?

It means building the smallest version that is sufficient for the buyer, decision, and proof point you have validated. It does not mean shipping careless work. It means resisting the urge to generalize, polish, or add features before the specific promise has earned a larger investment.

Does this prevent us from running small experiments?

No. Small, bounded experiments can be excellent ways to generate evidence. The guardrail is against using a substantial polished build as the first test of a new offer or product. Run experiments that reveal a decision, then let the result determine whether to build, adjust, or stop.