Chapter 16

The Skeptical Buyer Test

Become the Buyer’s Attorney

At some point in the commercial life of an app, the founder needs to stop being its advocate.

You have already spent months making the case for the product. You know why the problem matters, why your approach is better, why the awkward onboarding step is temporary, why the price makes sense when compared with the value, and why the missing integration is coming. If a buyer raises an objection, you can usually produce a respectable answer before they finish the sentence. That is useful when you are selling. It is dangerous when you are trying to decide whether the thing you are selling deserves to be scaled.

Before I spend meaningful money or reputation putting an offer in front of more people, I want to know what happens when I stop helping it win. I want the strongest reasonable case for saying no. Not the founder’s preferred version of an objection, conveniently written so it collapses under one paragraph of sales copy. Assume the buyer is intelligent, understands what you are offering, and would happily buy if buying were the best decision available to them. Then argue that it is not.

I think of this as becoming the buyer’s attorney. Your job is no longer to prove why the purchase makes sense. Your job is to represent the other side competently enough that the offer has to earn its way past you.

Builders already understand the basic idea in another context. We stress systems because failure discovered in a controlled environment is cheaper than failure discovered by a customer. If an API is unreliable, we do not improve the architecture by explaining why the API should have behaved. We reproduce the failure, locate the weakness, and change something that matters. Commercially, founders can become much softer. We encounter a reason not to buy and immediately explain why the buyer should not care.

That is not stress testing. It is arguing with the test.

Earlier in the book, I described an application that had received several hundred visitors without producing a paid conversion. The obvious temptation was more traffic. Before buying it, we showed the proposition to five people who closely resembled the intended buyer and asked what they thought the product would actually do for them. We got five different answers.

There were many ways to defend the page. The product really did have broad capabilities. Phrases such as “AI-powered growth” and “smarter customer acquisition” could be connected to things the software actually did. With enough explanation, I could make the proposition sound coherent.

That would have missed the evidence. A prospective buyer should not require the founder standing beside the webpage providing live interpretive services.

The useful question was not, Can I explain why this offer makes sense? Of course I could. I knew too much. The useful question was, Can I explain why a rational buyer might look at exactly what we have placed in front of them and decline?

Imagine an AI application that helps small agencies prepare client proposals. It pulls information from discovery notes, previous proposals, CRM records, pricing templates, and project documents. It creates a structured first draft, identifies missing information, and removes a great deal of repetitive assembly.

As the founder, your case is excellent. Proposal work consumes senior time. The application is more structured than opening a general-purpose AI tool and hoping for the best. The price is small compared with the value of winning a client.

Now switch chairs.

You run a twelve-person agency. You already have templates. Someone copies the relevant sections from the last proposal, updates the scope, runs some material through ChatGPT, checks the numbers, and sends the document. The process is not elegant, but it works. This new product costs money, requires setup, introduces another workflow, and comes from a vendor you have never used. You have three proposals due this week.

You keep doing what you are doing.

That is a strong no because it does not require the product to be useless. The buyer simply compared the proposed change with the whole cost and uncertainty of making that change and concluded that the current situation was good enough.

A serious skeptical-buyer exercise stays with that conclusion long enough to learn from it. Perhaps the agency only produces four proposals a month, which makes the savings smaller than you assumed. Perhaps your claim about time reduction comes from internal testing rather than comparable agencies using the product in real work. Perhaps the buyer could approve a small monthly charge but not the annual commitment you designed. Perhaps the owner agrees the product would be useful and still sees no reason to deal with it this quarter.

The purpose of the Buyer Stress Test is not to build a library of clever rebuttals. I do not want fourteen scripted responses designed to make every reasonable objection surrender. I want the offer to become harder to argue against.

So begin with one rule: give the other side competent representation. Write the best case for rejecting the proposition. Do not mock the buyer. Do not rescue the product halfway through. Do not explain what they have misunderstood. Argue the no until you believe you have made it fairly, then look at what defeated you.

Very often, the first opponent will not be another software company at all. It will be what the buyer is already doing.

Status Quo Is a Competitor

Founders usually think about competitors as products with logos. We compare feature matrices, integrations, pricing pages, screenshots, reviews, and positioning. Those comparisons matter, but the buyer’s actual alternative may be Excel, ChatGPT, a shared folder, an internal script, a weekly meeting, an employee who knows where everything is, or simply tolerating the problem.

All of those can win.

The reason is simple: the buyer is not comparing your product with the current workflow in a vacuum. They are comparing the entire experience of changing with the entire experience of not changing. The status quo begins with an enormous advantage. It is already happening.

Nobody has to approve the spreadsheet that already exists. Nobody has to train the team to continue using the process they already know. Nobody has to migrate data into the system they are already using or explain why they selected the vendor they never selected. The current process may be inefficient, ugly, and held together by conventions that would not survive independent review. It may still have accumulated years of organizational permission.

That matters more than founders expect.

Consider a consulting firm that prepares recurring client reports manually. Every month, someone pulls information from several systems, updates a spreadsheet and template, writes a summary, sends it to a senior person for review, fixes the inconsistencies, and delivers the result. You build an application that automates most of this. The collection takes minutes. The output is more consistent. The interface is cleaner.

The buyer may agree with every word and use the spreadsheet again next month.

They know where the spreadsheet breaks. They know which cells not to touch. They know who checks the totals and how to handle the unusual client. The workflow is annoying, but its annoyances are familiar. Your product introduces unknown problems, and the buyer does not yet know whether those problems are smaller than the ones you remove.

This is why good enough deserves more respect than founders usually give it. It is not a compliment to the existing system. It is a decision threshold. The buyer is saying that the improvement has not yet created enough reason to absorb the cost, uncertainty, effort, and disturbance of changing.

A workaround can therefore be both evidence of a problem and formidable competition. Earlier we treated spreadsheets, manual checks, internal scripts, and extra meetings as signs that a problem has enough weight to change behavior. That remains true. But the workaround also means the buyer has already solved the problem enough to keep operating.

You are not selling into empty space. You are asking them to replace something they have already funded with time, habit, training, process, political acceptance, or software.

This becomes especially important with AI products because the status quo increasingly includes general-purpose tools the buyer already has. The founder may compare a specialized application with other specialized applications while the customer thinks, I can keep doing this with ChatGPT and a spreadsheet.

Do not insult that alternative. Study it.

What does the buyer like about the current method, even while complaining about it? What flexibility would they lose? Which failures have become predictable enough to tolerate? What knowledge has accumulated around the process? What would have to become meaningfully better before changing is worth the trouble?

Your product does not have to beat the buyer’s ideal solution. It has to beat Tuesday.

Once you take that opponent seriously, the next question becomes unavoidable: is the improvement you are promising actually worth what the buyer must give up to obtain it?

Economic Case

Founders can make almost any software purchase look attractive with sufficiently cooperative arithmetic.

Suppose an application costs $199 a month and saves an agency twelve hours of work. If the employees doing that work cost roughly $100 an hour once salary, benefits, and overhead are included, twelve times one hundred is $1,200. Subtract the subscription and the customer appears to be ahead by $1,001 every month.

You have produced an ROI calculation. You have not necessarily produced the buyer’s economic case.

The distinction matters because founders tend to calculate value from the product outward. We begin with what the application improves, attach a number to the improvement, compare that number with the price, and admire the resulting ratio. The spreadsheet rarely objects. The buyer starts somewhere else: what actually changes financially or operationally if I purchase?

Those twelve saved hours are a good example. If an agency is turning away paid work because senior employees are buried in proposals, recovering the hours may create real capacity. If the owner spends those hours working nights, getting them back may matter even if no revenue line immediately moves. If the firm is considering another hire, the capacity might delay that expense.

But suppose the twelve hours are spread across six employees in fragments. Nobody works less. Nobody produces more billable work. No hiring decision changes. The team simply has twelve slightly less annoying hours.

That can still be valuable. It is not automatically worth $1,200.

The same discipline applies to revenue claims. A proposal application may help an agency respond faster and produce more consistent work. The founder can reasonably argue that this may contribute to winning business. The arithmetic gets adventurous when the average client is worth $20,000 and the product is suddenly credited with “one extra client,” making almost any subscription price look trivial.

The buyer has not agreed that the application will cause another client to sign. Lead quality, price, competition, salesperson skill, relationships, client budgets, and the quality of the underlying proposal all sit between the product and closed revenue. The economic case gets weaker when the founder takes credit for outcomes several causal steps beyond what the product can reasonably influence.

I prefer narrower claims. If the application reduces proposal assembly from three hours to forty-five minutes, we can examine that. If it reduces senior-review time or lets the agency respond a day earlier, we can examine that. Those changes may eventually affect revenue, but the skeptical buyer should not be required to finance the business case with optimism.

The cost side deserves the same honesty. The subscription is only the easiest cost to see. Adoption may consume employee time, setup work, administration, data preparation, and attention. Some of that belongs more directly to the friction case, but economically it still exists. A $200 product can create a purchase larger than $200.

Now compare two agencies using the same proposal software at the same price. Agency A produces forty complex proposals a month, pays for freelance help during busy periods, and regularly consumes senior time in review. Agency B produces four proposals a month from stable templates. The owner dislikes the repetition, but nobody is overloaded and the work gets done.

Identical software. Identical price. Very different economic cases.

That is why the Buyer Stress Test should ask more than, Does the product create value? Almost every useful product creates some value. Ask instead:

What economically meaningful condition becomes different if this buyer purchases, and is that difference large enough to justify the total cost of making the change?

The answer does not always reduce neatly to dollars. Reduced operational risk, greater capacity, faster response, less management attention, better consistency, and fewer unpleasant evenings can all matter. But vague value should not receive infinite weight merely because it is difficult to measure.

If the purchase only makes sense when every assumption is generous, that is a weakness worth finding before scale. Maybe the target buyer needs higher volume. Maybe the use case needs to be narrower. Maybe the problem does not cost this buyer enough. Maybe the scope or commitment asks for more than the outcome can support.

Even a strong economic case only gets you part of the way there. The numbers can work beautifully while one question remains unanswered: why should the buyer believe they will actually get the result?

Confidence Case

A strong economic case contains a hidden assumption: the product works.

Not merely in the technical sense that the application loads, the buttons respond, and the API returns something resembling the expected JSON. The buyer needs to believe that using the product will produce enough of the promised result in their situation to justify the decision.

It is possible for a buyer to trust you and still have a weak confidence case. They can believe you are honest, competent, responsible, and operating a legitimate company. They may even like you. They still may not believe that the result shown in your demo will survive contact with their data, employees, edge cases, and normal operational mess.

That distinction matters because Chapter 15 treated trust as its own commercial constraint. Here the question is narrower. Trust asks whether buying from you feels acceptably safe. Confidence asks whether the promised outcome feels sufficiently likely.

Imagine an AI application that reviews sales calls, identifies recurring objections, and helps managers improve coaching. Those are inspectable capabilities. Now extend the claim to “increase close rates.” Plausible, perhaps. But close rates also depend on lead quality, pricing, competition, salesperson ability, product fit, market conditions, and other variables the software does not control.

The buyer should separate the parts of the promise they can inspect from the parts they are being asked to believe.

Builders sometimes respond to this uncertainty by adding confidence language. Proven. Powerful. Reliable. Built to deliver results. The adjectives become increasingly muscular while the evidence remains exactly where it was. This is not a confidence case. It is confidence-themed typography.

The better question is: what evidence would reduce uncertainty around this particular claim?

If you say the system reduces reporting time, show the before-and-after workflow. If you say it identifies anomalies, let the buyer inspect representative findings and the evidence behind them. If you say it works with their data, test it with data that resembles theirs. If you say a useful result appears in the first week, make enough of that first week visible that the buyer can judge whether the claim is credible.

The form of proof should follow the reason for doubt.

This is particularly important for AI applications because one excellent demonstration can encourage a much larger inference than the evidence supports. A model handles one document beautifully, finds the right information, and generates a sharp analysis. That proves something: the system successfully handled that example.

It does not automatically prove that the product will handle the buyer’s documents, incomplete inputs, terminology, edge cases, unusual requests, and twentieth run with similar quality. The skeptical buyer should ask what happens when the model is uncertain, when the input is poor, when a human disagrees with the output, and when the workflow is repeated under normal conditions. Can the result be inspected? Can it be corrected? Does the product reveal uncertainty or confidently decorate it?

Those are not anti-AI questions. They are production questions.

This is one reason narrower promises can become commercially stronger even when they sound less exciting. Compare Our AI analyzes your support operation and tells you how to improve it with Upload ninety days of support tickets and receive a ranked list of the issues most often associated with escalation, with the supporting tickets attached for review.

The first reaches toward a larger outcome. The second gives the buyer something inspectable. They can challenge the categorization, examine the supporting evidence, and judge whether the result is useful. A smaller claim can support a stronger buying proposition because a large promise multiplied by low confidence can become commercially smaller than a modest promise the buyer actually believes.

The discipline is not to make timid claims. It is to stop borrowing certainty from the future. Make the strongest claim the current evidence can carry, then increase the evidence.

Honest limitations can help. If an application requires human review for certain decisions, say so. If it works best with three input formats, that may create more confidence than “works with everything” when the buyer knows perfectly well what their everything looks like.

During the Buyer Stress Test, make the strongest rational argument that the promised result may not occur. Ask what evidence supports the expected outcome and where that evidence came from: internal testing, a demonstration, a real deployment, a comparable customer, or an assumption. Ask what differs between those conditions and the buyer’s conditions. Most importantly, ask what the buyer would need to see before their uncertainty changed materially.

Sometimes the answer is a case study, their own data, a pilot, a reference, or one technically difficult demonstration. Sometimes the answer is that you are making a claim you cannot yet support.

Good. That is exactly what the stress test is for.

The buyer now believes the result is valuable and reasonably likely. There is still another way to lose: they may not want to go through what is required to make it work.

Friction Case

A product can be cheap and still be expensive to adopt.

The subscription might be $99 a month. The buyer may spend more than that in the first meeting required to decide who is going to set it up. This is where founders underestimate what they are asking someone to purchase. We see the application. The buyer sees the application plus everything that has to happen before the application becomes useful.

That surrounding work is friction.

Consider an AI application that produces recurring client reports. Once configured, it can collect information from project systems, identify exceptions, generate a first draft, and give an experienced employee something useful to review instead of asking them to assemble the report manually. The economic case may be excellent and the buyer may believe the result.

Now become their attorney again.

Someone has to determine which data sources are authoritative. Access must be approved. Historical records may need cleanup. The reporting template contains exceptions nobody documented because one employee simply knows which clients need the extra table. A senior person has to review the first outputs. Someone must decide whether the new process replaces the old one or sits beside it until everyone is comfortable.

The founder sees implementation. The buyer sees work.

That vocabulary difference matters. “Implementation required” sounds like a normal property of software. “We will need three people involved for the next two weeks before we know whether this helps” sounds like a decision.

Trace the path from purchase to first credible value without skipping steps merely because they happen outside your application. Who creates the account? What information must be gathered? What access is needed? What has to be connected, learned, migrated, reviewed, or changed? Can the old process remain in place temporarily? How much judgment still belongs to the customer before the system behaves correctly?

Founders make these steps disappear mentally because we know the product. A five-minute configuration task for us can be a thirty-minute uncertainty problem for a new customer. An elegant workflow may still ask users to remember a new place to work, enter information at a different point, review output differently, or trust automation where they previously performed the step manually.

Commercial friction is not measured in technical sophistication. It is measured in what the buyer has to do differently.

There is also a particular form of friction that appears when the product requires the customer to become your project manager. The founder describes onboarding as simple, but the buyer schedules the kickoff, chases access, gathers files, coordinates employees, tests the setup, reports problems, and remembers what has to happen next. Nothing sharpens skepticism quite like beginning a time-saving purchase with a sixteen-item customer homework list.

The answer is not to pretend every product should be instant. Some systems genuinely require integration, security controls, careful configuration, or human review. The stress test asks whether the friction is justified by the result, visible to the buyer, and reduced where it does not need to exist.

Sometimes the product needs three integrations eventually but only one before the first useful result. Sometimes historical data can be migrated later. Sometimes the founder can assist with configuration instead of building an elaborate self-service setup system before demand is proven. Sometimes the first sale should be narrower because the broad implementation creates more risk than the first commercial decision needs to contain.

Earlier I called the useful target fast credible value. The objective is not merely fast onboarding. It is to shorten the distance between the buyer saying yes and the buyer encountering enough real value to believe continuing was a good decision.

Write every meaningful step across that distance, then assume each one is slightly more annoying than you think. The data is messier. The administrator is busy. Someone prefers the old process. The integration behaves differently in their environment. Another project is competing for attention.

If you were the buyer, would the result at the other end still be worth crossing the path?

If not, objection handling will not rescue you. The problem may be scope, onboarding, product design, or simply an outcome that is not valuable enough to carry the disruption.

A buyer who survives the economic, confidence, and friction cases has come a long way. They believe the improvement matters, believe you can produce it, and can tolerate what is required to get there.

They still may have a perfectly good reason to do it later.

Timing Case

A buyer can agree with you about everything except the calendar.

The problem is real. The economics make sense. They believe the product can produce the result. Implementation looks manageable. If you ask whether the company should eventually solve the problem, the answer is yes.

Then they say, “Maybe next quarter.”

Sometimes that is a polite no. Sometimes not now means exactly what it says. The timing case asks a narrower question than the urgency discussion earlier in the book:

Why should this purchase happen now rather than sixty or ninety days from now?

If you cannot answer without inventing something, the buyer may have a reasonable case for waiting.

Return to the agency evaluating proposal software. The owner agrees that proposal preparation consumes too much senior time, believes your application can reduce it, accepts the price, and can adopt it without replacing the current templates immediately.

It is also August. Proposal volume is low. Two senior people are taking vacations. The agency is replacing its accounting system in September. Its major new-business push begins in January.

Why should they buy today?

“Because you are wasting time” is not enough. They will still be wasting time in November. If I were representing that buyer, I might advise waiting until the accounting project is finished and the team has enough time to adopt the new workflow before proposal volume rises.

The Buyer Stress Test has to permit that answer.

Take your current offer and move the purchase three months into the future. What gets worse? Does the buyer incur substantial additional cost? Does a contract renew? Does a compliance deadline arrive? Does volume cross a threshold? Does another project make implementation harder? Does an opportunity disappear?

Those are timing arguments because waiting changes the decision.

Now imagine that nothing meaningful changes. The buyer spends another fifteen minutes each week on something mildly annoying. No deadline is approaching. No budget disappears. The current process continues to function. The product can be purchased in September, December, or April with essentially the same benefit.

There may be no strong reason to act now.

That does not mean the product has no value. It means time is not applying much pressure to this decision.

Chapter 14 dealt with the temptation to manufacture urgency when reality fails to provide it. The stress-test version is simpler: keep the founder’s clock separate from the buyer’s. Your runway, sales target, disappointing launch, and desire to know whether a prospect is serious can all create urgency for you. None changes the buyer’s operating environment.

A product can also be aimed at the right type of buyer and arrive at the wrong moment in that buyer’s life. A five-person firm may like your workflow automation but not have enough volume yet. The same firm at twenty employees may be hiring because the manual process no longer holds together. A company six months into a contract may ignore alternatives. Ninety days before renewal, evaluation can become rational.

The product did not change. The purchase environment did.

This is why “circle back later” and a real timing trigger are not equivalent. “Our current agreement renews November 30 and we evaluate alternatives in October” describes a condition. “Maybe later this year” describes considerably less.

A useful timing statement is plain:

This is worth acting on now because ________. If the buyer waits, ________ becomes materially worse, more expensive, harder, or unavailable.

Sometimes you can fill those blanks easily. Sometimes the buyer can fill them better than you can. Sometimes they remain empty. An empty blank is not permission to invent a deadline. It is evidence about the proposition.

Even when the timing case survives, one more assumption may be hiding inside your analysis. So far we have often spoken as though “the buyer” were one person making a private decision. Frequently, they are not.

Internal-Purchase Case

“The buyer” is a useful phrase right up until it causes you to imagine one person.

Sometimes there really is one. A solo founder finds an application, likes it, enters a credit card, and begins using it minutes later. The person experiencing the problem, evaluating the solution, spending the money, implementing the product, and living with the result is the same human being.

In many businesses, those roles separate.

The person who wants the outcome may not control the budget. The person controlling the budget may never use the product. Someone else owns the systems it connects to. Another person is accountable if customer data is mishandled. A manager receives the productivity benefit while an administrator receives most of the implementation work.

Now the purchase has several audiences.

Suppose an operations director wants an AI application that reviews service requests, categorizes them, identifies recurring problems, and automates part of the reporting workflow. The director has a strong economic case. Their team spends too much time doing this manually. They have seen the product work on representative data and believe the result. The first implementation can be narrow enough that the disruption appears manageable.

If the director could buy alone, you might have a sale.

But the director sees hours returned to the team. Information security sees a new application receiving operational data. IT sees another integration and another vendor someone may have to support. Finance sees recurring expense attached to savings that may not show up as reduced headcount. Employees see a new process they must learn.

None of these people has to be irrational for the deal to become harder. The difficulty often comes from each person behaving rationally according to a different responsibility.

Organizations do not experience value evenly. One person receives the benefit, another the work, a third the risk, and a fourth the bill. If the offer makes sense only from the perspective of the person receiving the benefit, it has not survived the internal-purchase case.

This appears even in small companies. Imagine a twelve-person agency with two partners. One discovers your proposal application and loves it because she spends several hours every week reviewing proposals. The other partner does not review proposals. He sees another $300 subscription. The account manager learns that existing templates need to be organized for setup. Employees want to know whether client-specific exceptions still work.

The first partner entered asking, “How much time could this save me?” Everyone else enters with a different question.

This is where the word champion can become too flattering. A champion is not simply someone who liked the demo. They are someone willing and able to advance the purchase through whatever decision structure surrounds them. That usually requires a case they can repeat when you are not in the room.

Can they explain what changes, why it matters, what it costs, what implementation requires, and why the organization should accept the risk? Can they answer the obvious question from the department that has to participate?

If the proposition only works while you personally provide twenty minutes of context, its internal version may collapse as soon as you leave.

The internal-purchase case also exposes imbalances between benefit and burden. Suppose software saves the sales team hundreds of hours but requires significant IT work. From the company’s perspective the project may still be worthwhile. From IT’s perspective, the proposal has arrived with new responsibilities and no reduction in existing workload.

Sellers often call this “IT blocking the deal.” Sometimes bureaucracy really is excessive. But a stress test should begin with the less convenient assumption that the other participants have legitimate reasons for their position. Security’s job is not to improve your conversion rate. Finance is not obligated to use your preferred value calculation. An administrator is not resistant to innovation merely because your “simple setup” gives them Thursday afternoon’s work.

For each participant who matters, ask what changes for them. What do they gain? What do they have to do? What can go wrong? What are they responsible for afterward? What evidence would they reasonably require? Most importantly, can they say no even if the original buyer says yes?

That last question reveals veto power.

Earlier chapters examined trust and procurement distance. The stress-test version is different. You are not merely mapping the process. You are arguing each participant’s no. Pretend you are finance and explain why the expense should not be approved. Pretend you administer the system and explain why implementation is a poor use of your time. Pretend you are the employee whose workflow changes. Pretend you are the executive who owns the outcome if the promised improvement never appears.

Do not immediately answer them. Stay with the no long enough to learn from it.

By this point, the Buyer Stress Test has accumulated a serious case against the proposition. The next job is not to become better at arguing with that case. It is to decide what the case should change.

Do not fix every objection the skeptical case produced. Fix the one most likely to prevent a rational buyer from proceeding, then run the test again.

If the economic case fails, more distribution will produce more people who should say no. If the confidence case fails, a lower price may not make the product more believable. If the friction case fails, narrow the first commitment or remove work from the buyer. If the internal-purchase case fails, give the champion what they need to carry the decision through the organization instead of hoping enthusiasm survives the handoff.

A proposition that survives a serious skeptical review has not proved the business. It has earned the right to meet more buyers. That is where the problem changes from what should we sell to how do the right people reliably encounter it.