Part V: Let Buyers Teach You the Business

Chapter 21

An Objection Is Data

Overcome or Understand

Most of what has been written about objections treats them as obstacles. The buyer raises one, the seller handles it, and if the handling is skillful the sale proceeds. There are books of scripts for this. Some of them work, in the sense that a prepared answer delivered with confidence will move some percentage of hesitant buyers across the line, and I am not going to pretend that is worthless.

But it is the wrong default for a founder with a handful of customers and an unproven commercial theory, because it assumes the seller is right and the buyer is confused. Sometimes that is true. The buyer has misunderstood the offer, or lacks information, or is repeating something a competitor told them. Often it is not. Often the buyer has just identified, more precisely than the founder ever has, a real weakness in the buyer, the problem, the offer, the price, the trust, the timing, or the path. Treating that as resistance to be defeated throws away the most expensive information the business has yet produced. It took months to get a qualified buyer to a decision. The reason for the decision is the payload, and the objection-handling instinct discards it in favor of a rebuttal.

I learned to see it this way through the integration story from Chapter 4, which I will not retell. The relevant piece is what the original prospect’s request actually was. They wanted an integration. They said, in substance, that the product was almost exactly what they needed and that the integration was the missing piece. A team in objection-handling mode hears that as a blocker and builds it. What we did instead was treat the request as a claim about buying behavior and test the claim, by asking whether they would commit to the agreement if the integration existed by a date. They would not. The objection was real. It was not purchase-critical. Those are different things, and the difference was worth weeks of engineering time and a great deal of false confidence.

That is the distinction this chapter is built on. An objection is a buyer telling you what their decision is made of. It can be handled, and sometimes should be. It should always first be understood, because the same words can mean different things, and what they mean determines which part of the commercial hypothesis needs to change, if any.

There is a second reason to prefer understanding over overcoming, and it has to do with the founder’s own psychology, which this book has returned to often enough that I will keep it short. Handling an objection feels like competence. Understanding one sometimes requires admitting that the buyer is right, and that the thing they are right about is the offer you spent a year on. Builders are not uniquely bad at this. We are, however, unusually well equipped to avoid it, because when a buyer says “it doesn’t do X,” the engineering response is available immediately and feels like the mature, customer-focused thing to do. Build X. Handle the objection with code. It is the same avoidance we discussed in the feature chapter, wearing a slightly more commercial outfit.

The alternative is slower and less satisfying. It means taking each objection as a data point about a specific variable, recording it, comparing it with the others, and only then deciding whether anything should change. Most objections come in a small number of forms. The three most common, “too expensive,” “it’s missing something,” and “not now,” each hide several different diagnoses behind the same sentence, and a founder who cannot tell those diagnoses apart will end up changing the wrong thing with great energy.

So the chapter walks through the three, then through the question of when a pattern is a pattern, then through what to actually change. It ends with the most valuable objection of all, which is the one that does not arrive as an objection: the buyer who paid, and the question of why.

“Too Expensive”

“Too expensive” is the objection founders most often hear and least often understand, because it sounds like a statement about the price and is usually a statement about something else.

Consider what has to be true for a rational buyer to say it. They have compared the number to something. The something might be the value they expect to receive, the budget they control, the cost of what they do today, a competitor’s price, a mental category the product fell into, or the risk that the thing will not work. “Too expensive” is the output of that comparison. Which comparison, and what the buyer put on the other side of it, is the information, and the sentence does not contain it.

So the same two words can mean at least five different things, and each points at a different part of the path.

It can mean the price is genuinely above what the outcome is worth to this buyer. That is a real price problem, and it should be rare if the earlier steps were done properly, because the paid-problem step should have surfaced a cost that the price could be set against. When it does happen, the fix is not automatically to lower the number. It may be that this buyer’s version of the problem is smaller than the version the offer was built for, in which case the buyer is wrong for the offer, and the useful change is to the buyer definition rather than the price.

It can mean the value was never established. The buyer has no clear picture of what changes for them after purchase, so any number looks expensive against a benefit they cannot see. This is an offer problem wearing a price costume. Lowering the price will not fix it and may make it worse, because a cheap unclear thing is still unclear. The tell is that the buyer cannot articulate what they would be getting; ask them to describe the outcome in their own words and listen for whether it matches yours.

It can mean the budget does not exist or is not theirs. The buyer sees the value and cannot pay from any line they control. That is an authority problem or a timing problem, and the chapter on conversations should have caught it earlier, but it will still surface here sometimes. The fix is a different person or a different quarter, not a different number, and a discount offered to someone who cannot approve any amount is a discount given to nobody.

It can mean the buyer does not trust the promise enough to risk the price. “Expensive” here is shorthand for “expensive if it doesn’t work,” and the buyer has silently multiplied the price by their doubt. The trust chapter covered why this happens and why lowering the price is the wrong instrument. A pilot structure, a review step, a reference, or a guarantee changes the doubt. A discount only changes the number the doubt is multiplying.

And it can mean the buyer is leaving politely. “Too expensive” is a socially complete sentence that requires no further explanation and offends no one, which makes it the objection of choice for buyers who have decided no for reasons they would rather not discuss. When it comes without any engagement with the actual number, when the buyer never asks what is included or whether there are other options, it is often not a price objection at all. It is an exit. The information in it is that something earlier in the conversation did not land, and the founder’s best move is to ask, without defensiveness, what would have needed to be different.

The way to tell these apart is to ask about the comparison. Compared to what? What are you doing today, and what does that cost? What would it need to do to be worth that? If it were half the price, would you start next month, or is there something else? That last question is the most useful one I know for this objection, because a buyer who says “yes, at half the price I’d start” has given you a real price signal, and a buyer who says “well, I’d still need to check with...” has just told you the price was never the issue.

I want to add one thing about the founder’s own reaction, because it distorts everything above. Founders who are uncertain about their price, and most early founders are, hear “too expensive” as confirmation of a fear they already had. The natural response is relief, in a strange way, because the buyer has named the thing the founder was worried about, and a discount is easy to give. That is how businesses end up with prices set by their most reluctant prospects. The pricing chapter argued that a price is a hypothesis to be tested against behavior. This chapter adds that “too expensive” is not, by itself, a test result. It is a prompt to find out what the buyer was comparing.

“It’s Missing Something”

A feature objection is the one builders are most equipped to answer and least equipped to interpret.

The answer is obvious: build the feature. The capacity to do so is sitting right there, it is the founder’s strongest skill, and AI has made the interval between hearing the request and shipping something remarkably short. What is less obvious is what the request means, and the feature chapter’s rule holds here with particular force. A requested feature earns development priority when there is evidence that building it changes buying behavior. An objection is not that evidence. It is a claim that such evidence might exist, and claims get tested.

“It’s missing X” can mean four different things, and the difference decides whether a sprint should be spent.

It can be a genuine blocker. The buyer cannot use the product at all without X, because X is the connection to the system where their data lives, or the compliance requirement their industry imposes, or the one workflow step without which the outcome is not delivered. Genuine blockers are real and worth building, and the way to identify one is that the buyer will commit conditionally: if X exists by a date, they proceed. The integration story is the model. Two later prospects made exactly that commitment, one in a paid pilot and one in writing, and the feature got built with commercial evidence attached to it.

It can be a preference. The buyer would like X, X would make the product nicer, and the buyer will buy anyway, or will not buy for some other reason that X does not touch. Preferences are worth recording and are not worth building on the strength of one conversation. The tell is that the buyer, asked whether X would change their decision, hesitates or says “not by itself.”

It can be an organizational requirement that the buyer is relaying. The buyer personally does not need X, but the security team, the procurement policy, or the person who signs does. This is closer to a blocker, but it belongs to the trust chapter rather than the product roadmap, and the response is often documentation, a process, or a conversation with the person who actually holds the requirement rather than a feature.

And it can be a courteous reason not to buy. The buyer has decided no, and “if it had X” is a way to end the conversation with something constructive-sounding. This is the one that costs founders the most, because it arrives with specificity and specificity feels like commitment. The original prospect in the integration story may have been in this category, or may not; what we know is that when asked to commit, they declined, and the integration they had described as the missing piece turned out not to be the missing piece for them. The way to detect this version is the same as for a blocker: ask what the buyer would do if X existed. The answer separates the two immediately, and a founder who does not ask cannot tell them apart, no matter how sincere the request sounded.

So the practical rule is to run the request through Build Permission before it becomes a ticket. Who is asking? Are they the payer, or someone adjacent to the payer? What do they do today without X? What consequence does its absence create? What decision is blocked, specifically? And what will they commit to if it exists? A feature objection that survives those questions with concrete answers is a product gap and should be treated as one. A feature objection that does not survive them is a data point about preferences, useful in aggregate and dangerous alone.

I will add the counterweight, because the book has been accused before now, at least in my own head, of being anti-feature. Sometimes the buyer is right and the product is missing the thing. Sometimes several buyers in the same segment name the same gap, and each of them would commit if it were closed, and at that point building it is not avoidance but the correct commercial move. When the same objection repeats across comparable buyers, the pattern deserves more weight. The point here is narrower. One buyer’s missing feature is a hypothesis about the product, and the way to test a hypothesis about the product is not to build it. It is to ask what building it would unlock.

“Not Now”

“Not now” is the objection founders take most literally and should take least literally, because it is the one that most often means something other than timing.

Sometimes it means exactly what it says. The buyer has the problem, sees the value, accepts the price, and cannot act this quarter because of something real: a migration in progress, a hiring freeze, a budget cycle that closed in March, a larger project consuming the only person who could run the evaluation. Real timing objections come with a date or an event attached. “After the audit in June.” “Once the new ops lead starts.” “When the current contract ends in November.” A founder who hears one of those has learned something specific and should record it with the date, because the buyer has told you when to return and what trigger to watch for. The previous chapters on timing and triggers apply directly; this is what a trigger looks like from the other side.

More often, “not now” is a statement about urgency, and the information in it is that the problem, as the buyer experiences it, does not currently outrank the other things competing for their attention. That is not the same as “the problem is not real.” The buyer may agree that it is real, expensive, and worth solving, and still, honestly, not be going to solve it this quarter, because it has been tolerable for two years and nothing has changed. A founder who hears “not now” and mentally files the buyer under “will convert later” is misreading the objection. What the buyer has said is that, absent a trigger, the status quo is winning. The paid-problem chapter made the point that the strongest problems already cause behavior. “Not now” from a qualified buyer is evidence that this problem, for this buyer, does not.

That reading has an uncomfortable implication when it repeats. If most qualified buyers say some version of “not now,” the founder does not have a pipeline of future customers. They have a problem that is real but not urgent, and the commercial hypothesis needs to change at the problem step, not the timing step. Either the offer has to attach to something that is urgent, the buyer definition has to narrow to the people for whom the problem is live, or the founder has to accept that the category is one where sales happen only when a trigger fires and build the acquisition motion around finding triggers. All three are legitimate. Waiting is not, and neither is the fourth option founders reach for, which is inventing the urgency the market declined to supply. The purchase-moment chapter dealt with why manufactured deadlines are a poor idea; here the point is that they also destroy the information. A buyer who acts because of a fake countdown has told you nothing about whether the problem was ever urgent.

There is a third meaning, and it is the most useful to detect early. “Not now” can be a polite refusal, the timing cousin of “too expensive” as an exit. The buyer has decided no and has chosen the objection that requires the least justification. The tell is the absence of a date or an event. “Let’s revisit this later” with no later specified is rarely a timing objection. It is a closed door with good manners, and the founder should treat it as a no and ask what would have needed to be different, rather than scheduling a follow-up that both people know will be ignored.

The practical discipline is simple to state. When a buyer says “not now,” ask what “now” would look like. What would need to be true for this to become the priority? Is there a date, an event, a person, or a budget attached to that? If the answer names something, record it and return when it happens. If the answer is vague, the objection was not about time, and the founder has just learned something about urgency or about the buyer that a calendar reminder would have hidden for months.

That is signal-driven follow-up. Instead of checking in on a calendar, watch for the event that would make the problem live: a contract renewal, a budget window, a missed deadline, a new volume threshold, a staffing change, an audit, or whatever condition the buyer actually named. Reappear when that condition changes. If the buyer cannot name any condition that would make the problem more urgent, treat “not now” as weak commitment evidence rather than a dated opportunity in the pipeline.

All three objections so far share a property that makes them dangerous individually. Each one, from a single buyer, can be explained in several ways, and a founder who has heard it once cannot know which explanation is correct. That changes when the same objection arrives from the fifth buyer.

Decide What Changes

A pattern of objections points at a variable. The founder’s decision is which variable to change, and the choice is harder than it looks, because most objections could be answered by changing any of several things and founders gravitate toward the one they find least painful.

Take a recurring trust pattern: larger buyers in the segment decline because they do not believe a small vendor can be trusted with the workflow. That could be addressed by changing the buyer, narrowing to smaller firms for whom the vendor’s size is not disqualifying. It could be addressed by changing the offer, adding a pilot structure, a review step, or documentation that reduces the perceived risk. It could be addressed by changing the path, entering larger firms through a partner whose trust the buyer can borrow. It could, in principle, be addressed by changing the product, adding controls and audit features that make the trust claim more credible. Any of those is a legitimate response to the same pattern. They are not equally cheap, equally fast, or equally likely to work, and the founder should choose deliberately rather than by reflex.

The builder’s reflex is the product because it is the variable the founder controls most completely and understands best. That is exactly why it is the variable most likely to be changed when something else was the problem. When the pattern is tagged trust, a product change may be the slowest and least certain fix. When it is tagged offer, the product may be irrelevant because the buyer never understood what was being sold. When it is tagged buyer, changing the product to satisfy the wrong buyers can spend months making an excellent fit for people who were never going to pay.

So the rule I use is to change the cheapest variable that plausibly explains the pattern first, and to change one at a time. Cheapest usually means message, buyer, or offer, all of which can be revised in a day and tested in a week. Price is next; it takes a conversation to test. Path and trust take longer. Product takes longest and should generally be reached only when the cheaper explanations have been tried and failed, or when the feature objection has survived Build Permission with committed buyers attached.

Changing one variable at a time is the part founders skip when they are anxious, and it matters for the same reason it matters in any experiment. If the response to a pattern of “too expensive” is to lower the price, rewrite the page, and add a feature in the same week, and conversion improves, nobody knows why, and the founder has learned that flailing works, which is not a repeatable lesson.

A hypothetical brings the pieces together. Suppose five qualified buyers in a segment have each said the product needs an integration with the same system, and the founder is preparing to build it. The objection table shows five rows tagged product, all from the right kind of buyer. That looks like a pattern, and it is. But before the sprint starts, the founder goes back to each of the five and asks the question from the integration story: if this existed by the end of next month, would you proceed at the proposed price? Two say yes and will put it in writing. Two say they would need to see it first, which is a maybe. One says they have since chosen another tool. The pattern was real. The evidence for building is now two conditional commitments rather than five requests, which is enough to justify the build and is also a much more honest picture of what the integration will unlock. It is also a smaller picture, and the founder should notice that three of the five requests were not, in the end, purchase-critical, which says something about how much weight future feature objections should carry from this segment.

That is the loop closing. The pattern produced a hypothesis; the hypothesis was tested against commitment before resources were spent; the result changed what got built and adjusted the founder’s model of the buyer. The next round of conversations starts with the integration in hand and with a better calibrated sense of what “we need X” means from these buyers. Objections that never change anything are conversations being collected. Objections that change one variable, deliberately, with a test attached, are the market teaching the founder what the business is.

I will end where the chapter started, with a caution against the opposite excess. Not every objection reveals the real reason, and not every buyer knows their real reason. People are not always accurate narrators of their own decisions, and a founder who treats every stated objection as ground truth will be led in circles by buyers who were leaving politely. The table, the tags, the commitment test, and the one-variable-at-a-time rule exist to keep the founder from acting on any single story, including a true one told by one person. What they cannot do is substitute for judgment about what the count means. The market gets a vote. It does not get to write the roadmap unsupervised.

Negative evidence, gathered this way, tells you where the theory may be wrong. It cannot tell you where the theory is right. For that you need the other kind of buyer, the one who did not object, or objected and bought anyway. Somebody paid. The interesting question is why that person, and not the others who looked just like them.