Chapter 10

The Market Gets a Vote

The Founder Can Explain Anything After the Fact

Give a founder a disappointing result and ten minutes, and we can usually produce a surprisingly respectable explanation for why it does not mean what it appears to mean. I know this because I can do it too.

Suppose I believe independent consultants are a strong market for an application I built. The reasoning is solid. They perform the workflow frequently. Their time has economic value. Many already patch the problem together with spreadsheets, documents, email, and manual effort. They can often make modest purchasing decisions without procurement assembling a committee. The application saves time and produces a better result.

That is not a ridiculous theory. It may be a very good one. So I contact forty consultants who appear to fit the conditions I care about. Two reply. My theory survives immediately. Cold email is difficult. The subject line may have been weak. These people are busy. Perhaps email is not how consultants discover software. Maybe I need a warmer channel.

All plausible. So I find a community where consultants already spend time and put the product in front of them there. Twenty-three people visit the page. Seven create accounts. Four complete the main workflow. One sends me a message saying the product is clever.

Nobody pays. The theory survives again. Of course they did not pay. They entered through a community and were probably browsing casually. The free trial may have attracted the wrong behavior. Maybe the pricing page appears too early. Perhaps they need more time to experience the value.

Also plausible. I let the trial run longer. Several people continue using the application. Still nobody pays. Now I have another explanation available. Perhaps the free version is too good. I have allowed people to receive enough value without upgrading. This is a monetization-design problem, not a demand problem.

So I tighten the free plan and make the paid proposition clearer. Usage falls. Still no purchases. No problem. That proves the free version was important for adoption. Notice what is happening. At every stage, I have a reasonable explanation. I am not necessarily lying to myself. I may be correctly identifying something important about the channel, trial structure, pricing page, trust burden, onboarding, or product. Any one of those explanations could turn out to be right.

The problem is that the original commercial belief appears capable of surviving every possible result. That is where interpretation becomes dangerous. Founders have an unusual amount of explanatory power because we know more about the product than almost anybody else. We know what changed last week. We know which feature is incomplete, which integration is coming, where the onboarding still feels awkward, which audience saw the launch, which traffic source was weak, which buyer seemed distracted during the demo, and which competitor recently changed its pricing.

Give us an outcome and we can usually connect it to something. Sometimes that is exactly what good diagnosis requires. If a checkout bug prevented every purchase for three days, it would be foolish to interpret zero revenue during those three days as a referendum on demand. Context matters. This entire book depends on context.

But context can also become a very sophisticated defense attorney for an idea we do not want to reconsider. The distinction I care about is between explaining an observation and protecting a conclusion. This sounds obvious, but the separation disappears quickly when we are emotionally or financially invested in one particular explanation. The founder who has spent six months building for consultants does not experience “consultants may not be the strongest buyer” as just another line in an analytical notebook. That possibility reaches backward into product decisions, positioning, features, months of work, and perhaps a fairly elaborate spreadsheet describing the size of the consulting market.

You can keep a commercial theory alive for an impressively long time by replacing every failed prediction with a new reason the prediction should not have counted. Engineers would be suspicious of a test that behaved this way.

Imagine running an automated test, seeing it fail, inspecting the output, and then changing the expected result to match what the system just produced. Run it again. Another failure. Update the expected result again. After several iterations, the test suite is beautifully green.

It has also stopped testing anything. Commercial reasoning can fail in the same quieter way. The market produces an outcome, then we decide afterward what that outcome was allowed to mean. Positive behavior counts immediately. Negative behavior receives a footnote.

Any of those explanations may be correct. That is what makes the problem difficult. Bad rationalizations would be easy to reject if they sounded ridiculous. The dangerous ones sound intelligent. When I find myself producing a long explanation for why an inconvenient result should not change my confidence, I want evidence for that explanation too. Otherwise I am not learning from the market. I am editing the market until it agrees with me.

This is also why founder conviction is both useful and dangerous. You need enough conviction to build something, put it in front of people, tolerate indifference, hear several versions of no, make changes, and continue testing. A founder who abandons the thesis after three unanswered emails is not practicing evidence discipline. They are simply being pushed around by tiny samples.

The opposite failure is harder to notice. You become so good at preserving the thesis that no amount of buyer behavior can seriously threaten it. Then the market technically has a vote, but you have given yourself permanent veto power.

The solution is not to stop interpreting results. Buyer behavior requires interpretation. A purchase from one person does not prove an entire market, and a rejection from one person does not disprove one. Commercial evidence is contextual, noisy, and incomplete.

The discipline has to happen earlier. Before you know what the result will be, there needs to be some outcome that would make you less confident in what you currently believe. Otherwise you do not really have a commercial test yet.

You have a theory with excellent legal representation.

A Hypothesis Needs a Possible “No”

A useful hypothesis takes a risk. Not a financial risk. Not necessarily a large one. It risks being wrong. That sounds like a trivial requirement until you apply it to the statements founders routinely call hypotheses.

“Small agencies need a better way to create proposals.” “Operations teams would save time with this.” “Developers want an easier way to monitor their AI agents.” “Consultants will pay for software that helps them find more clients.”

Those may be sensible starting beliefs. They may even be true in some broad sense. But they are not yet very useful commercially because it is difficult to imagine what observation would make us reject them.

If those claims are vague enough, almost any disappointing result can be assigned to the feature set, the channel, the price, or the timing while the original belief remains untouched. This is why I prefer commercial hypotheses that contain enough specificity to become vulnerable. Instead of:

Consultants need this.

Try something closer to:

Independent consultants who regularly lose several hours assembling client deliverables will consider that problem important enough to seriously evaluate a product that reduces the work.

That still needs refinement, but it has improved. We have identified a type of buyer, a condition, a consequence, and an expected response. Now something can happen that makes us less confident. If I speak with consultants who really do lose several hours to that work, confirm that the time matters economically, show them a credible product that addresses it, and almost none are willing to spend even thirty minutes evaluating it, my original theory should become less comfortable.

Not necessarily dead. Less comfortable. But the fact that evidence is imperfect does not give us permission to make ourselves unfalsifiable. That is the trap. The founder says, “I believe these buyers have this problem.”

Fine. What would make you believe that less? If the answer is essentially nothing, then we are no longer discussing a hypothesis. We are discussing a conviction. I find it helpful to ask three questions before running a commercial test:

What do I currently believe? What result would increase my confidence? What result would decrease it? Most founders are comfortable with the second question. We are excellent at imagining confirming evidence. The third question is where the real discipline begins.

Suppose ten well-qualified prospects agree that the problem is expensive but none will evaluate the product. Would that weaken the theory? Suppose they evaluate it and consistently say the current workaround is good enough. Would that?

Suppose they like the product, understand the value, encounter the proposed price, and repeatedly decide that the problem is not worth solving at that cost. Would that change anything? If every answer is followed by, “Well, not necessarily, because…,” pay attention.

The qualification may be legitimate. One result rarely deserves unlimited interpretive power. But if the hypothesis survives twenty qualified conversations, repeated refusal to evaluate, multiple price discussions, and no meaningful commitment without losing even a little confidence, you should ask what exactly would be required to change your mind.

There has to be something. Otherwise the founder holds a strange advantage over reality. Positive outcomes count as validation. Negative outcomes are merely inconclusive. That accounting system will produce confidence forever. It will not necessarily produce customers.

This does not mean choosing an arbitrary failure threshold and obeying it mechanically. “If three people say no, kill the company” is not evidence discipline. It is numerology with a startup vocabulary. The threshold has to fit the decision.

A $19 consumer application can generate meaningful behavioral evidence quickly because the purchase is simple and the individual often controls the entire decision. A six-figure enterprise system may require months of evaluation, security review, implementation planning, budgeting, and several people whose calendars appear to have been designed as defensive architecture.

Those experiments cannot reasonably use the same standard. What should remain constant is the willingness to define, in advance, what kinds of outcomes would force another look at the theory. Maybe you decide that if fifteen qualified buyers with the relevant economic problem consistently refuse even a low-friction evaluation, you will revisit the buyer or problem hypothesis.

The numbers and commitments will vary. The intellectual rule does not. A commercial hypothesis must give reality some way to disagree. That is why the next step is more precise than asking whether “the market responded.”

You have to decide what behavior would actually count.

Silence Is Unknown

Defining the behavior creates a useful problem. Sometimes the behavior never happens. You send the message. Nothing. The prospect visits the page and leaves. The trial invitation sits unopened. The person who sounded interested after a conversation does not schedule the evaluation.

No purchase. No objection. No explanation. Just absence. We encountered silence earlier in the book when diagnosing where a commercial path can break. Here I want to make a narrower point about what silence does to a hypothesis: usually, much less than founders think.

Suppose my hypothesis says:

Operations managers whose teams spend at least five hours a week reconciling customer data will agree to evaluate a product that automates most of that work.

I identify twenty operations managers who appear to fit the profile and send each one an email describing the problem and asking for a short evaluation. Nineteen do not reply. Did nineteen operations managers reject the hypothesis?

No. Nineteen messages failed to produce a reply. That sentence is less satisfying because it leaves the interesting question unresolved. Unfortunately, unresolved is sometimes the correct answer. I do not know whether each person saw the message. I do not know whether the email reached the inbox or disappeared into a filter. I do not know whether the subject line earned three seconds of attention, whether the recipient recognized the problem, whether I contacted the correct person inside the company, whether the timing was terrible, or whether my unknown company looked like enough of a risk that the person deleted the message before seriously considering the proposition.

I also do not know whether they understood everything perfectly and simply did not care. Silence contains all of those possibilities without distinguishing among them. This is one reason I resist phrases such as “the market said no” when the market mostly did not say anything.

A no is useful because something reached the point of refusal. Silence often tells you that you did not reach that point. That does not make silence meaningless. Nineteen nonresponses out of twenty are still an observation. If I can repeatedly reach apparently qualified prospects through a channel that should be credible, use language drawn directly from their own problem, and receive almost no engagement, I should not spend six months announcing that the sample remains philosophically inconclusive.

Patterns matter. But the conclusion has to match the pattern. A low reply rate can weaken my confidence that this path is capable of generating buyer conversations. It may weaken my confidence that my message makes the problem recognizable. If I have strong reason to believe the recipients saw and understood the proposition, repeated silence may eventually make the buyer or problem hypothesis less attractive too.

What it cannot do automatically is tell me which one failed. Technical people have a useful concept for this: missing telemetry. Imagine an application sends a request to an external service and nothing useful appears in your monitoring. No response code. No timeout event. No trace showing whether the request arrived. No corresponding server log.

You know the expected result did not appear. You do not yet know why. It would be reckless to conclude that the external service rejected the request because the evidence does not establish that the service ever evaluated it. The missing result is itself worth investigating, but you first want better observability around the boundary.

Commercially, silence is often a badly instrumented boundary. Did the buyer receive the proposition? Were they qualified? Did they recognize the problem? Did they trust the sender enough to investigate? Did they ever reach the requested decision? If you cannot answer those questions, the absence of the desired behavior is real, but its meaning is underdetermined. The same discipline applies outside outbound. A landing page can receive 500 visitors and generate no purchases. Before concluding that buyers rejected the price, ask whether they reached the price.

The further the buyer gets into a real decision, the more interpretable their behavior becomes. That gives us a practical way to think about silence. Ask where the silence occurred. Silence before the buyer plausibly encountered the proposition tells you very little about the proposition.

Silence after the proposition was encountered tells you more. Silence after a qualified buyer understood the problem, saw the product, discussed the economics, and was given a clear next step tells you considerably more. Even then, I prefer a direct answer when I can get one.

If a prospect disappears after a serious evaluation, I would rather ask what stopped the process than invent the answer from CRM archaeology. Perhaps the person will not respond. Fine. Unknown remains available as a category.

Founders sometimes dislike that category because it feels passive. I like it. Unknown protects you from pretending to know something you do not. It also tells you what information to seek next. If your first twenty attempts produce silence, do not immediately rewrite the entire commercial thesis. Improve the experiment until enough buyers actually encounter the question you are trying to test.

Then let them answer it. Because once a qualified buyer has genuinely reached the decision and says no, we have something silence could not give us. We have a rejection. And rejection is much more useful, provided we know what was actually rejected.

The Market Gets a Vote, Not a Monopoly

There is an easy way to misunderstand this chapter. If buyer behavior matters more than founder explanations, then perhaps the solution is simply to do whatever buyers tell you. It is not. The market gets a vote.

It does not get a monopoly. Customers can be wrong about what should be built. Prospects can ask for features they will never purchase. One buyer can reject a product for reasons that say almost nothing about another buyer. People can prefer the familiar option even when something better exists. They can underestimate a problem before circumstances make it urgent, overestimate what they will use, misdiagnose their own workflow, or confidently request a solution to the wrong part of the problem.

Evidence still requires judgment. That is why I deliberately use the word vote rather than verdict. The founder has information the buyer does not. You know what is technically possible. You may understand where the underlying technology is moving. You know which feature would create three years of maintenance burden despite sounding simple in a meeting. You can see similarities across conversations that an individual buyer cannot. You know whether a requested workflow fits the architecture or turns the product into custom consulting disguised as SaaS.

You also have to decide what business you are willing to build. That last part matters. Suppose buyers repeatedly tell you they would happily pay for a highly customized version of your product if you personally configure it, integrate six systems, migrate their data, attend weekly meetings, and provide a phone number they can call whenever anything behaves strangely.

That may be excellent demand. It may also describe a services business you have no desire or economic ability to operate. The market has given you useful information. It has not issued a command. Or suppose one large customer offers substantial money for a feature that would pull the product away from the problem you are trying to solve for everyone else. Saying yes might be the correct decision. Saying no might also be correct.

Revenue is evidence. It is not the only objective. This is where simplistic versions of “listen to the customer” stop being useful. Listening is mandatory. Obedience is not. Good commercial judgment lives between two bad extremes.

At one extreme, the founder decides what the market should want and protects that belief from every inconvenient result. At the other, the founder treats every customer comment, objection, requested feature, lost deal, competitor move, and conversion fluctuation as an instruction to change direction.

The first founder does not learn. The second never develops a thesis long enough to test one. You need enough conviction to run a coherent experiment and enough humility to let the experiment matter. That balance is uncomfortable because there is no formula that tells you exactly how much evidence should outweigh how much judgment.

Numbers do not interpret themselves. Neither do anecdotes. The discipline is to keep asking what the behavior permits you to conclude. I am much more interested in a founder who can say, “This result lowered my confidence in the buyer hypothesis, but it did not yet tell me whether the product is wrong,” than one who announces either “the market validated us” or “the idea is dead” after a handful of reactions.

Commercial maturity tends to sound less dramatic. The founder’s job is not to win an argument against the market. It is also not to surrender the company to whichever prospect spoke most recently. The job is to form a commercial thesis, expose it to conditions capable of producing meaningful behavior, interpret the behavior honestly, and revise the thesis when the evidence earns a revision.

Then do it again. That is what I mean when I say the market gets a vote. A useful commercial process leaves fingerprints on the theory: the buyer becomes more specific, the costly problem becomes clearer, the assumptions become fewer, and the unknowns become more visible. And ideally, the next experiment becomes harder for the founder to explain away.

There is one major piece we have not examined closely enough yet. Throughout this part of the book, we have talked about whether the right buyer has a meaningful problem, whether that buyer can be reached, and what behavior follows when the product is placed in front of them.

But a buyer does not purchase a product in the abstract. They encounter a proposition. Something is being promised. Something is included. Something is excluded. There is a price, a level of effort, an implementation burden, a perceived risk, a reason to act or a reason to postpone.

Two founders can sell identical software and give the market two very different things to vote on. So before we interpret the next no, yes, trial, pilot, or payment, we need to become much more precise about the object of the decision.

What, exactly, is the buyer being asked to buy?